CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-49000 – iommu/vt-d: Fix PCI device refcount leak in has_external_pci()
https://notcve.org/view.php?id=CVE-2022-49000
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in has_external_pci() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() before 'return true' to avoid reference count leak. • https://git.kernel.org/stable/c/89a6079df791aeace2044ea93be1b397195824ec https://git.kernel.org/stable/c/10ed7655a17f6a3eaecd1293830488259ccd5723 https://git.kernel.org/stable/c/b6eea8b2e858a20ad58ac62dc2de90fea2413f94 https://git.kernel.org/stable/c/17f67414718e6aba123335a33b7d15aa594fff34 https://git.kernel.org/stable/c/afca9e19cc720bfafc75dc5ce429c185ca93f31d •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48999 – ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference
https://notcve.org/view.php?id=CVE-2022-48999
In the Linux kernel, the following vulnerability has been resolved: ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference Gwangun Jung reported a slab-out-of-bounds access in fib_nh_match: fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961 fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753 inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874 Separate nexthop objects are mutually exclusive with the legacy multipath spec. Fix fib_nh_match to return if the config for the to be deleted route contains a multipath spec while the fib_info is using a nexthop object. • https://git.kernel.org/stable/c/493ced1ac47c48bb86d9d4e8e87df8592be85a0e https://git.kernel.org/stable/c/cc3cd130ecfb8b0ae52e235e487bae3f16a24a32 https://git.kernel.org/stable/c/0b5394229ebae09afc07aabccb5ffd705ffd250e https://git.kernel.org/stable/c/25174d91e4a32a24204060d283bd5fa6d0ddf133 https://git.kernel.org/stable/c/bb20a2ae241be846bc3c11ea4b3a3c69e41d51f2 https://git.kernel.org/stable/c/61b91eb33a69c3be11b259c5ea484505cd79f883 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48998 – powerpc/bpf/32: Fix Oops on tail call tests
https://notcve.org/view.php?id=CVE-2022-48998
In the Linux kernel, the following vulnerability has been resolved: powerpc/bpf/32: Fix Oops on tail call tests test_bpf tail call tests end up as: test_bpf: #0 Tail call leaf jited:1 85 PASS test_bpf: #1 Tail call 2 jited:1 111 PASS test_bpf: #2 Tail call 3 jited:1 145 PASS test_bpf: #3 Tail call 4 jited:1 170 PASS test_bpf: #4 Tail call load/store leaf jited:1 190 PASS test_bpf: #5 Tail call load/store jited:1 BUG: Unable to handle kernel data access on write at 0xf1b4e000 Faulting instruction address: 0xbe86b710 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K MMU=Hash PowerMac Modules linked in: test_bpf(+) CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195 Hardware name: PowerMac3,1 750CL 0x87210 PowerMac NIP: be86b710 LR: be857e88 CTR: be86b704 REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28008242 XER: 00000000 DAR: f1b4e000 DSISR: 42000000 GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000 GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8 GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000 GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00 NIP [be86b710] 0xbe86b710 LR [be857e88] __run_one+0xec/0x264 [test_bpf] Call Trace: [f1b4dfe0] [00000002] 0x2 (unreliable) Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]--- This is a tentative to write above the stack. The problem is encoutered with tests added by commit 38608ee7b690 ("bpf, tests: Add load store test case for tail call") This happens because tail call is done to a BPF prog with a different stack_depth. At the time being, the stack is kept as is when the caller tail calls its callee. But at exit, the callee restores the stack based on its own properties. Therefore here, at each run, r1 is erroneously increased by 32 - 16 = 16 bytes. This was done that way in order to pass the tail call count from caller to callee through the stack. • https://git.kernel.org/stable/c/51c66ad849a703d9bbfd7704c941827aed0fd9fd https://git.kernel.org/stable/c/747a6e547240baaaf41874d27333b87b87cfd24c https://git.kernel.org/stable/c/89d21e259a94f7d5582ec675aa445f5a79f347e4 •
CVSS: 4.7EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48997 – char: tpm: Protect tpm_pm_suspend with locks
https://notcve.org/view.php?id=CVE-2022-48997
In the Linux kernel, the following vulnerability has been resolved: char: tpm: Protect tpm_pm_suspend with locks Currently tpm transactions are executed unconditionally in tpm_pm_suspend() function, which may lead to races with other tpm accessors in the system. Specifically, the hw_random tpm driver makes use of tpm_get_random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Call Trace: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350 Fix this by calling tpm_try_get_ops(), which itself is a wrapper around tpm_chip_start(), but takes the appropriate mutex. [Jason: reworked commit message, added metadata] • https://git.kernel.org/stable/c/e891db1a18bf11e02533ec2386b796cfd8d60666 https://git.kernel.org/stable/c/d699373ac5f3545243d3c73a1ccab77fdef8cec6 https://git.kernel.org/stable/c/4e0d6c687c925e27fd4bc78a2721d10acf5614d6 https://git.kernel.org/stable/c/571b6bbbf54d835ea6120f65575cb55cd767e603 https://git.kernel.org/stable/c/25b78bf98b07ff5aceb9b1e24f72ec0236c5c053 https://git.kernel.org/stable/c/23393c6461422df5bf8084a086ada9a7e17dc2ba https://access.redhat.com/security/cve/CVE-2022-48997 https://bugzilla.redhat.com/show_bug.cgi?id=2320774 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48996 – mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes()
https://notcve.org/view.php?id=CVE-2022-48996
In the Linux kernel, the following vulnerability has been resolved: mm/damon/sysfs: fix wrong empty schemes assumption under online tuning in damon_sysfs_set_schemes() Commit da87878010e5 ("mm/damon/sysfs: support online inputs update") made 'damon_sysfs_set_schemes()' to be called for running DAMON context, which could have schemes. In the case, DAMON sysfs interface is supposed to update, remove, or add schemes to reflect the sysfs files. However, the code is assuming the DAMON context wouldn't have schemes at all, and therefore creates and adds new schemes. As a result, the code doesn't work as intended for online schemes tuning and could have more than expected memory footprint. The schemes are all in the DAMON context, so it doesn't leak the memory, though. Remove the wrong asssumption (the DAMON context wouldn't have schemes) in 'damon_sysfs_set_schemes()' to fix the bug. • https://git.kernel.org/stable/c/da87878010e59869d4d27b3c01ecc8ec06ff4a20 https://git.kernel.org/stable/c/f98d1f2a36ad7ab48fb4cf73ca14e7b19482fd4d https://git.kernel.org/stable/c/95bc35f9bee5220dad4e8567654ab3288a181639 •