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: 4EXPL: 0CVE-2022-48995 – Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send()
https://notcve.org/view.php?id=CVE-2022-48995
In the Linux kernel, the following vulnerability has been resolved: Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send() There is a kmemleak when test the raydium_i2c_ts with bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff88812d3675c8 (size 8): comm "python3", pid 349, jiffies 4294741070 (age 95.692s) hex dump (first 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 After BANK_SWITCH command from i2c BUS, no matter success or error happened, the tx_buf should be freed. • https://git.kernel.org/stable/c/3b384bd6c3f2d6d3526c77bfb264dfbaf737bc2a https://git.kernel.org/stable/c/a82869ac52f3d9db4b2cf8fd41edc2dee7a75a61 https://git.kernel.org/stable/c/53b9b1201e34ccc895971218559123625c56fbcd https://git.kernel.org/stable/c/097c1c7a28e3da8f2811ba532be6e81faab15aab https://git.kernel.org/stable/c/8c9a59939deb4bfafdc451100c03d1e848b4169b •