CVSS: -EPSS: 0%CPEs: 1EXPL: 0CVE-2024-44933 – bnxt_en : Fix memory out-of-bounds in bnxt_fill_hw_rss_tbl()
https://notcve.org/view.php?id=CVE-2024-44933
In the Linux kernel, the following vulnerability has been resolved: bnxt_en : Fix memory out-of-bounds in bnxt_fill_hw_rss_tbl() A recent commit has modified the code in __bnxt_reserve_rings() to set the default RSS indirection table to default only when the number of RX rings is changing. While this works for newer firmware that requires RX ring reservations, it causes the regression on older firmware not requiring RX ring resrvations (BNXT_NEW_RM() returns false). With older firmware, RX ring reservations are not required and so hw_resc->resv_rx_rings is not always set to the proper value. The comparison: if (old_rx_rings != bp->hw_resc.resv_rx_rings) in __bnxt_reserve_rings() may be false even when the RX rings are changing. This will cause __bnxt_reserve_rings() to skip setting the default RSS indirection table to default to match the current number of RX rings. • https://git.kernel.org/stable/c/bc57f879a420d19bb5ecdb480f858371554f2258 https://git.kernel.org/stable/c/abd573e9ad2ba64eaa6418a5f4eec819de28f205 https://git.kernel.org/stable/c/da03f5d1b2c319a2b74fe76edeadcd8fa5f44376 •
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: 8EXPL: 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/18504710442671b02d00e6db9804a0ad26c5a479 https://git.kernel.org/stable/c/9ae2d8e75b741dbcb0da374753f972410e83b5f3 https://git.kernel.org/stable/c/9d682e89c44bd5819b01f3fbb45a8e3681a4b6d0 https://git.kernel.org/stable/c/c65ab97efcd438cb4e9f299400f2ea55251f3a67 https://git.kernel.org/stable/c/672c19165fc96dfad531a5458e0b3cdab414aae4 https://git.kernel.org/stable/c/1b955f786a4bcde8c0ccb2b7d519def2acb6f3cc https://git.kernel.org/stable/c/d776c0486b03a5c4afca65b8ff44573592bf93bb https://git.kernel.org/stable/c/d795848ecce24a75dfd46481aee066ae6 •
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: 3EXPL: 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/f7d9a18572fcd7130459b7691bd19ee2a2e951ad https://git.kernel.org/stable/c/d59c4d0eb6adc24c2201f153ccb7fd0a335b0d3d https://git.kernel.org/stable/c/b9ecbfa45516182cd062fecd286db7907ba84210 •