CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-53191 – wifi: ath12k: fix warning when unbinding
https://notcve.org/view.php?id=CVE-2024-53191
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix warning when unbinding If there is an error during some initialization related to firmware, the buffers dp->tx_ring[i].tx_status are released. However this is released again when the device is unbinded (ath12k_pci), and we get: WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80 Call Trace: free_large_kmalloc ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set the buffers to NULL after releasing in order to avoid the double free. • https://git.kernel.org/stable/c/d889913205cf7ebda905b1e62c5867ed4e39f6c2 https://git.kernel.org/stable/c/223b546c6222d42147eff034433002ca5e2e7e09 https://git.kernel.org/stable/c/90556b96338aa6037cd26dac857327fda7c19732 https://git.kernel.org/stable/c/94c9100b600f05a36b33f9ed76dbd6fb0eb25386 https://git.kernel.org/stable/c/ca68ce0d9f4bcd032fd1334441175ae399642a06 •
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: 4EXPL: 0CVE-2024-53188 – wifi: ath12k: fix crash when unbinding
https://notcve.org/view.php?id=CVE-2024-53188
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix crash when unbinding If there is an error during some initialization related to firmware, the function ath12k_dp_cc_cleanup is called to release resources. However this is released again when the device is unbinded (ath12k_pci), and we get: BUG: kernel NULL pointer dereference, address: 0000000000000020 at RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k] Call Trace: ath12k_dp_cc_cleanup ath12k_dp_free ath12k_core_deinit ath12k_pci_remove ... The issue is always reproducible from a VM because the MSI addressing initialization is failing. In order to fix the issue, just set to NULL the released structure in ath12k_dp_cc_cleanup at the end. • https://git.kernel.org/stable/c/d889913205cf7ebda905b1e62c5867ed4e39f6c2 https://git.kernel.org/stable/c/81da9c0854545c3188ca2a09afe7cb65f9c012b5 https://git.kernel.org/stable/c/2eec88c0fa63f8ad35704a8c9df0b5bd8694fcda https://git.kernel.org/stable/c/488d2959c28621e52b3cce118a813a4bc18bb3d1 https://git.kernel.org/stable/c/1304446f67863385dc4c914b6e0194f6664ee764 •
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: 5EXPL: 0CVE-2024-53186 – ksmbd: fix use-after-free in SMB request handling
https://notcve.org/view.php?id=CVE-2024-53186
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in SMB request handling A race condition exists between SMB request handling in `ksmbd_conn_handler_loop()` and the freeing of `ksmbd_conn` in the workqueue handler `handle_ksmbd_work()`. This leads to a UAF. - KASAN: slab-use-after-free Read in handle_ksmbd_work - KASAN: slab-use-after-free in rtlock_slowlock_locked This race condition arises as follows: - `ksmbd_conn_handler_loop()` waits for `conn->r_count` to reach zero: `wait_event(conn->r_count_q, atomic_read(&conn->r_count) == 0);` - Meanwhile, `handle_ksmbd_work()` decrements `conn->r_count` using `atomic_dec_return(&conn->r_count)`, and if it reaches zero, calls `ksmbd_conn_free()`, which frees `conn`. - However, after `handle_ksmbd_work()` decrements `conn->r_count`, it may still access `conn->r_count_q` in the following line: `waitqueue_active(&conn->r_count_q)` or `wake_up(&conn->r_count_q)` This results in a UAF, as `conn` has already been freed. The discovery of this UAF can be referenced in the following PR for syzkaller's support for SMB requests. • https://git.kernel.org/stable/c/18f06bacc197d4ac9b518ad1c69999bc3d83e7aa https://git.kernel.org/stable/c/e9dac92f4482a382e8c0fe1bc243da5fc3526b0c https://git.kernel.org/stable/c/ee426bfb9d09b29987369b897fe9b6485ac2be27 https://git.kernel.org/stable/c/9fd3cde4628bcd3549ab95061f2bab74d2ed4f3b https://git.kernel.org/stable/c/a96f9eb7add30ba0fafcfe7b7aca090978196800 https://git.kernel.org/stable/c/f20b77f7897e6aab9ce5527e6016ad2be5d70a33 https://git.kernel.org/stable/c/96261adb998a3b513468b6ce17dbec76be5507d4 https://git.kernel.org/stable/c/9a8c5d89d327ff58e9b2517f8a6afb418 •