CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53194 – PCI: Fix use-after-free of slot->bus on hot remove
https://notcve.org/view.php?id=CVE-2024-53194
In the Linux kernel, the following vulnerability has been resolved: PCI: Fix use-after-free of slot->bus on hot remove Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired. The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot->bus. In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device(). However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device(). There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device(). In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices(). • https://git.kernel.org/stable/c/50473dd3b2a08601a078f852ea05572de9b1f86c https://git.kernel.org/stable/c/d0ddd2c92b75a19a37c887154223372b600fed37 https://git.kernel.org/stable/c/da6e6ff1f6c57f16e07af955e0e997fc90dd1e75 https://git.kernel.org/stable/c/41bbb1eb996be1435815aa1fbcc9ffc45b84cc12 https://git.kernel.org/stable/c/20502f0b3f3acd6bee300257556c27a867f80c8b https://git.kernel.org/stable/c/e5d5c04aac71bf1476dc44b56f2206a4c2facca8 https://git.kernel.org/stable/c/c8266ab8e7ccd1d1f5a9c8b29eb2020175048134 https://git.kernel.org/stable/c/69d2ceac11acf8579d58d55c9c5b65fb6 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-53190 – wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures
https://notcve.org/view.php?id=CVE-2024-53190
In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures Syzkaller reported a hung task with uevent_show() on stack trace. That specific issue was addressed by another commit [0], but even with that fix applied (for example, running v6.12-rc5) we face another type of hung task that comes from the same reproducer [1]. By investigating that, we could narrow it to the following path: (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and dummy_hcd infrastructure. (b) During the probe of rtl8192cu, the driver ends-up performing an efuse read procedure (which is related to EEPROM load IIUC), and here lies the issue: the function read_efuse() calls read_efuse_byte() many times, as loop iterations depending on the efuse size (in our example, 512 in total). This procedure for reading efuse bytes relies in a loop that performs an I/O read up to *10k* times in case of failures. We measured the time of the loop inside read_efuse_byte() alone, and in this reproducer (which involves the dummy_hcd emulation layer), it takes 15 seconds each. As a consequence, we have the driver stuck in its probe routine for big time, exposing a stack trace like below if we attempt to reboot the system, for example: task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000 Workqueue: usb_hub_wq hub_event Call Trace: __schedule+0xe22/0xeb6 schedule_timeout+0xe7/0x132 __wait_for_common+0xb5/0x12e usb_start_wait_urb+0xc5/0x1ef ? • https://git.kernel.org/stable/c/c386fb76f01794f1023d01a6ec5f5c93d00acd3b https://git.kernel.org/stable/c/8f3551f67991652c83469c7dd51d7b9b187b265f https://git.kernel.org/stable/c/eeb0b9b9e66b0b54cdad8e1c1cf0f55e8ba4211c https://git.kernel.org/stable/c/ac064c656f105b9122bc43991a170f95f72b7a43 https://git.kernel.org/stable/c/5c1b544563005a00591a3aa86ecff62ed4d11be3 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-53187 – io_uring: check for overflows in io_pin_pages
https://notcve.org/view.php?id=CVE-2024-53187
In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: <TASK> __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... </TASK> io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow. • https://git.kernel.org/stable/c/29eac3eca72d4c2a71122050c37cd7d8f73ac4f3 https://git.kernel.org/stable/c/aaa90844afd499c9142d0199dfda74439314c013 https://git.kernel.org/stable/c/0c0a4eae26ac78379d0c1db053de168a8febc6c9 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53184 – um: ubd: Do not use drvdata in release
https://notcve.org/view.php?id=CVE-2024-53184
In the Linux kernel, the following vulnerability has been resolved: um: ubd: Do not use drvdata in release The drvdata is not available in release. Let's just use container_of() to get the ubd instance. Otherwise, removing a ubd device will result in a crash: RIP: 0033:blk_mq_free_tag_set+0x1f/0xba RSP: 00000000e2083bf0 EFLAGS: 00010246 RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00 RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348 RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7 R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000 R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0 Kernel panic - not syncing: Segfault with no mm CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1 Workqueue: events mc_work_proc Stack: 00000000 604f7ef0 62c5d000 62405d20 e2083c30 6002c776 6002c755 600e47ff e2083c60 6025ffe3 04208060 603d36e0 Call Trace: [<6002c776>] ubd_device_release+0x21/0x55 [<6002c755>] ? ubd_device_release+0x0/0x55 [<600e47ff>] ? kfree+0x0/0x100 [<6025ffe3>] device_release+0x70/0xba [<60381d6a>] kobject_put+0xb5/0xe2 [<6026027b>] put_device+0x19/0x1c [<6026a036>] platform_device_put+0x26/0x29 [<6026ac5a>] platform_device_unregister+0x2c/0x2e [<6002c52e>] ubd_remove+0xb8/0xd6 [<6002bb74>] ? • https://git.kernel.org/stable/c/23d742a3fcd4781eed015a3a93e6a0e3ab1ef2a8 https://git.kernel.org/stable/c/300e277e463e6326938dd55ea560eafa0f5c88a5 https://git.kernel.org/stable/c/509ba8746f812e45a05034ba18b73db574693d11 https://git.kernel.org/stable/c/5727343348f34e11a7c5a2a944d5aa505731d876 https://git.kernel.org/stable/c/a5a75207efae4b558aaa34c288de7d6f2e926b4b https://git.kernel.org/stable/c/2d194d951895df214e066d08146e77cb6e02c1d4 https://git.kernel.org/stable/c/e6e5a4cded9bef3a1b0a4fac815b7176eb9a18ec https://git.kernel.org/stable/c/16cf8511680809a9f20b3dd224c06d482 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-53183 – um: net: Do not use drvdata in release
https://notcve.org/view.php?id=CVE-2024-53183
In the Linux kernel, the following vulnerability has been resolved: um: net: Do not use drvdata in release The drvdata is not available in release. Let's just use container_of() to get the uml_net instance. Otherwise, removing a network device will result in a crash: RIP: 0033:net_device_release+0x10/0x6f RSP: 00000000e20c7c40 EFLAGS: 00010206 RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0 RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028 RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70 R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000 R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mc_work_proc Stack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010 Call Trace: [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<6002ec9c>] net_remove+0x63/0x69 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<60087d40>] ? __remove_hrtimer+0x38/0x74 [<60087ff8>] ? • https://git.kernel.org/stable/c/b174ab33aaafd556a1ead72fa8e35d70b6fb1e39 https://git.kernel.org/stable/c/8d9d174d3f55daaf5e7b48e9d7f53c723adbed86 https://git.kernel.org/stable/c/6be99d4c117b9642a44d9f54f034b67615be2b2b https://git.kernel.org/stable/c/1635d9a0ff1b8bd7aa4767d4ea7b3de72cd36f28 https://git.kernel.org/stable/c/160cd5f956d191eb97664afd31ca59284c08d876 https://git.kernel.org/stable/c/cdbd5a1dcdc2c27ac076f91b03b9add3fefa1a82 https://git.kernel.org/stable/c/468c2e5394afc848efb1eae6e1961a3c855cf35e https://git.kernel.org/stable/c/f04cd022ee1fde219e0db1086c27a0a5b •