CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-44936 – power: supply: rt5033: Bring back i2c_set_clientdata
https://notcve.org/view.php?id=CVE-2024-44936
In the Linux kernel, the following vulnerability has been resolved: power: supply: rt5033: Bring back i2c_set_clientdata Commit 3a93da231c12 ("power: supply: rt5033: Use devm_power_supply_register() helper") reworked the driver to use devm. While at it, the i2c_set_clientdata was dropped along with the remove callback. Unfortunately other parts of the driver also rely on i2c clientdata so this causes kernel oops. Bring the call back to fix the driver. • https://git.kernel.org/stable/c/3a93da231c12bb153224bbbdd3d9a83da9e0ba33 https://git.kernel.org/stable/c/3c5d0871b0af0184abc6f7f52f8705b39a6251ae https://git.kernel.org/stable/c/d3911f1639e67fc7b12aae0efa5a540976d7443b •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-44935 – sctp: Fix null-ptr-deref in reuseport_add_sock().
https://notcve.org/view.php?id=CVE-2024-44935
In the Linux kernel, the following vulnerability has been resolved: sctp: Fix null-ptr-deref in reuseport_add_sock(). syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in reuseport_add_sock(). [0] The repro first creates a listener with SO_REUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener. The second listen() calls reuseport_add_sock() with the first listener as sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently, but the close() does clear it by reuseport_detach_sock(). The problem is SCTP does not properly synchronise reuseport_alloc(), reuseport_add_sock(), and reuseport_detach_sock(). The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must provide synchronisation for sockets that are classified into the same reuseport group. Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead. 1. Two sockets call listen() concurrently 2. No socket in the same group found in sctp_ep_hashtable[] 3. Two sockets call reuseport_alloc() and form two reuseport groups 4. • https://git.kernel.org/stable/c/6ba84574026792ce33a40c7da721dea36d0f3973 https://git.kernel.org/stable/c/c9b3fc4f157867e858734e31022ebee8a24f0de7 https://git.kernel.org/stable/c/52319d9d2f522ed939af31af70f8c3a0f0f67e6c https://git.kernel.org/stable/c/54b303d8f9702b8ab618c5032fae886b16356928 https://git.kernel.org/stable/c/05e4a0fa248240efd99a539853e844f0f0a9e6a5 https://git.kernel.org/stable/c/1407be30fc17eff918a98e0a990c0e988f11dc84 https://git.kernel.org/stable/c/e809a84c802377ef61525a298a1ec1728759b913 https://git.kernel.org/stable/c/9ab0faa7f9ffe31296dbb9bbe6f76c72c •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-44934 – net: bridge: mcast: wait for previous gc cycles when removing port
https://notcve.org/view.php?id=CVE-2024-44934
In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: wait for previous gc cycles when removing port syzbot hit a use-after-free[1] which is caused because the bridge doesn't make sure that all previous garbage has been collected when removing a port. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still running Make sure all previous gc cycles have finished by using flush_work before freeing the port. [1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699 CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437 • https://git.kernel.org/stable/c/e12cec65b5546f19217e26aafb8add6e2fadca18 https://git.kernel.org/stable/c/1e16828020c674b3be85f52685e8b80f9008f50f https://git.kernel.org/stable/c/0d8b26e10e680c01522d7cc14abe04c3265a928f https://git.kernel.org/stable/c/e3145ca904fa8dbfd1a5bf0187905bc117b0efce https://git.kernel.org/stable/c/b2f794b168cf560682ff976b255aa6d29d14a658 https://git.kernel.org/stable/c/92c4ee25208d0f35dafc3213cdf355fbe449e078 •
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 •