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: 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 •