CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44932 – idpf: fix UAFs when destroying the queues
https://notcve.org/view.php?id=CVE-2024-44932
In the Linux kernel, the following vulnerability has been resolved: idpf: fix UAFs when destroying the queues The second tagged commit started sometimes (very rarely, but possible) throwing WARNs from net/core/page_pool.c:page_pool_disable_direct_recycling(). Turned out idpf frees interrupt vectors with embedded NAPIs *before* freeing the queues making page_pools' NAPI pointers lead to freed memory before these pools are destroyed by libeth. It's not clear whether there are other accesses to the freed vectors when destroying the queues, but anyway, we usually free queue/interrupt vectors only when the queues are destroyed and the NAPIs are guaranteed to not be referenced anywhere. Invert the allocation and freeing logic making queue/interrupt vectors be allocated first and freed last. Vectors don't require queues to be present, so this is safe. Additionally, this change allows to remove that useless queue->q_vector pointer cleanup, as vectors are still valid when freeing the queues (+ both are freed within one function, so it's not clear why nullify the pointers at all). • https://git.kernel.org/stable/c/1c325aac10a82f11410da8a2bf35e3e410a42751 https://git.kernel.org/stable/c/3cde714b0e77206ed1b5cf31f28c18ba9ae946fd https://git.kernel.org/stable/c/290f1c033281c1a502a3cd1c53c3a549259c491f •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-44931 – gpio: prevent potential speculation leaks in gpio_device_get_desc()
https://notcve.org/view.php?id=CVE-2024-44931
In the Linux kernel, the following vulnerability has been resolved: gpio: prevent potential speculation leaks in gpio_device_get_desc() Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpio_ioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpio_device_get_desc(). This change ensures that the offset is sanitized by using array_index_nospec() to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. • https://git.kernel.org/stable/c/1b955f786a4bcde8c0ccb2b7d519def2acb6f3cc https://git.kernel.org/stable/c/d776c0486b03a5c4afca65b8ff44573592bf93bb https://git.kernel.org/stable/c/d795848ecce24a75dfd46481aee066ae6fe39775 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43914 – md/raid5: avoid BUG_ON() while continue reshape after reassembling
https://notcve.org/view.php?id=CVE-2024-43914
In the Linux kernel, the following vulnerability has been resolved: md/raid5: avoid BUG_ON() while continue reshape after reassembling Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test: kernel BUG at drivers/md/raid5.c:6278! invalid opcode: 0000 [#1] PREEMPT SMP PTI irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Call Trace: <TASK> raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail. Fix this panic the easy way first, by converting the BUG_ON() to WARN_ON(), and stop the reshape if checkings fail. Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata. • https://git.kernel.org/stable/c/2c92f8c1c456d556f15cbf51667b385026b2e6a0 https://git.kernel.org/stable/c/6b33c468d543f6a83de2d61f09fec74b27e19fd2 https://git.kernel.org/stable/c/c384dd4f1fb3b14a2fd199360701cc163ea88705 https://git.kernel.org/stable/c/bf0ff69a42a3d2d46876d0514ecf13dffc516666 https://git.kernel.org/stable/c/3b33740c1750a39e046339ff9240e954f0156707 https://git.kernel.org/stable/c/775a9ba16c9ffe98fe54ebf14e55d5660f2bf600 https://git.kernel.org/stable/c/4811d6e5d9f4090c3e0ff9890eb24077108046ab https://git.kernel.org/stable/c/305a5170dc5cf3d395bb4c4e9239bca6d •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43913 – nvme: apple: fix device reference counting
https://notcve.org/view.php?id=CVE-2024-43913
In the Linux kernel, the following vulnerability has been resolved: nvme: apple: fix device reference counting Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl. Split the allocation side out to make the error handling boundary easier to navigate. The apple driver had been doing this wrong, leaking the controller device memory on a tagset failure. • https://git.kernel.org/stable/c/d59c4d0eb6adc24c2201f153ccb7fd0a335b0d3d https://git.kernel.org/stable/c/b9ecbfa45516182cd062fecd286db7907ba84210 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43912 – wifi: nl80211: disallow setting special AP channel widths
https://notcve.org/view.php?id=CVE-2024-43912
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: disallow setting special AP channel widths Setting the AP channel width is meant for use with the normal 20/40/... MHz channel width progression, and switching around in S1G or narrow channels isn't supported. Disallow that. • https://git.kernel.org/stable/c/3d42f2125f6c89e1e71c87b9f23412afddbba45e https://git.kernel.org/stable/c/c6ea738e3feb407a3283197d9a25d0788f4f3cee https://git.kernel.org/stable/c/ac3bf6e47fd8da9bfe8027e1acfe0282a91584fc https://git.kernel.org/stable/c/23daf1b4c91db9b26f8425cc7039cf96d22ccbfe •