CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49002 – iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()
https://notcve.org/view.php?id=CVE-2022-49002
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() 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() for the error path to avoid reference count leak. • https://git.kernel.org/stable/c/2e45528930388658603ea24d49cf52867b928d3e https://git.kernel.org/stable/c/d47bc9d7bcdbb9adc9703513d964b514fee5b0bf https://git.kernel.org/stable/c/71c4a621985fc051ab86d3a86c749069a993fcb2 https://git.kernel.org/stable/c/876d7bfb89273997056220029ff12b1c2cc4691d https://git.kernel.org/stable/c/cbdd83bd2fd67142b03ce9dbdd1eab322ff7321f https://git.kernel.org/stable/c/a5c65cd56aed027f8a97fda8b691caaeb66d115e https://git.kernel.org/stable/c/bdb613ef179ad4bb9d56a2533e9b30e434f1dfb7 https://git.kernel.org/stable/c/2a8f7b90681472948de172dbbf5a54cd3 •
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: 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: 8EXPL: 0CVE-2022-48994 – ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event
https://notcve.org/view.php?id=CVE-2022-48994
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches. • https://git.kernel.org/stable/c/b38486e82ecb9f3046e0184205f6b61408fc40c9 https://git.kernel.org/stable/c/e385360705a0b346bdb57ce938249175d0613b8a https://git.kernel.org/stable/c/2f46e95bf344abc4e74f8158901d32a869e0adb6 https://git.kernel.org/stable/c/63badfed200219ca656968725f1a43df293ac936 https://git.kernel.org/stable/c/15c42ab8d43acb73e2eba361ad05822c0af0ecfa https://git.kernel.org/stable/c/fccd454129f6a0739651f7f58307cdb631fd6e89 https://git.kernel.org/stable/c/13ee8fb5410b740c8dd2867d3557c7662f7dda2d https://git.kernel.org/stable/c/05530ef7cf7c7d700f6753f058999b1b5 •