Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: avoid calling post_write_mst_fixup() for invalid index_block<br /> <br /> ntfs_icx_ib_sync_write() calls post_write_mst_fixup() when ntfs_ib_write()<br /> returns an error, intending to restore the buffer after a failed write.<br /> <br /> However, ntfs_ib_write() returns an error immediately if<br /> pre_write_mst_fixup() validation fails. The caller,<br /> ntfs_icx_ib_sync_write(), interprets any error as a write failure<br /> requiring rollback. It does not differentiate between I/O errors and<br /> validation failures, and calls post_write_mst_fixup() anyway.<br /> <br /> Since post_write_mst_fixup() assumes that the index_block contents is<br /> correct, it doesn&amp;#39;t perform the boundary checks, which results in<br /> out-of-bounds memory access.<br /> <br /> An attacker can craft a malicious NTFS image with:<br /> - large index_block.usa_ofs offset, pointing outside the ntfs_record<br /> - index_block.usa_count = 0, causing integer underflow<br /> - or index_block.usa_count larger than actual number of sectors in the<br /> ntfs_record, causing out-of-bounds access<br /> <br /> KASAN reports describing the memory corruption:<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in post_write_mst_fixup+0x19c/0x1d0<br /> Read of size 2 at addr ffff8881586c9018 by task p/9428<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x100/0x190<br /> print_report+0x139/0x4ad<br /> ? post_write_mst_fixup+0x19c/0x1d0<br /> ? __virt_addr_valid+0x262/0x500<br /> ? post_write_mst_fixup+0x19c/0x1d0<br /> kasan_report+0xe4/0x1d0<br /> ? post_write_mst_fixup+0x19c/0x1d0<br /> post_write_mst_fixup+0x19c/0x1d0<br /> ntfs_icx_ib_sync_write+0x179/0x220<br /> ntfs_inode_sync_filename+0x83d/0x1080<br /> __ntfs_write_inode+0x1049/0x1480<br /> ntfs_file_fsync+0x131/0x9b0<br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in post_write_mst_fixup+0x1aa/0x1d0<br /> Write of size 2 at addr ffff8881586c91fe by task p/9428<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x100/0x190<br /> print_report+0x139/0x4ad<br /> ? post_write_mst_fixup+0x1aa/0x1d0<br /> ? __virt_addr_valid+0x262/0x500<br /> ? post_write_mst_fixup+0x1aa/0x1d0<br /> kasan_report+0xe4/0x1d0<br /> ? post_write_mst_fixup+0x1aa/0x1d0<br /> post_write_mst_fixup+0x1aa/0x1d0<br /> ntfs_icx_ib_sync_write+0x179/0x220<br /> ntfs_inode_sync_filename+0x83d/0x1080<br /> __ntfs_write_inode+0x1049/0x1480<br /> ntfs_file_fsync+0x131/0x9b0<br /> ==================================================================<br /> <br /> Let&amp;#39;s move the post_write_mst_fixup() call to ntfs_ib_write().<br /> The ntfs_ib_write() function calls pre_write_mst_fixup() at the beginning.<br /> If the index_block contents is invalid, pre_write_mst_fixup() fails and<br /> ntfs_ib_write() returns early without calling post_write_mst_fixup() on<br /> bad index_block.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: validate Dirty Page Table capacity in log_replay copy_lcns<br /> <br /> In the analysis pass of $LogFile journal replay, log_replay() copies<br /> LCNs from each action log record into an existing Dirty Page Table<br /> (DPT) entry without bounding the destination index. A crafted NTFS<br /> image with DPT entry lcns_follow=1 and an action log record with<br /> lcns_follow=2 produces a kernel slab out-of-bounds write at mount<br /> time:<br /> <br /> BUG: KASAN: slab-out-of-bounds in log_replay+0x654c/0xdb60<br /> Write of size 8 at addr ffff8880095e1040 by task mount<br /> <br /> Two attacker-controlled fields can drive j+i past the allocated<br /> page_lcns[] array:<br /> <br /> 1. dp-&gt;lcns_follow (capacity) can be smaller than lrh-&gt;lcns_follow.<br /> 2. lrh-&gt;target_vcn may be smaller than dp-&gt;vcn, making the u64<br /> subtraction wrap to a huge size_t.<br /> <br /> Validate target VCN delta and per-record LCN count against the<br /> DPT entry capacity, bail via the existing out: cleanup label with<br /> -EINVAL.<br /> <br /> This mirrors the bounds-check pattern added in commit b2bc7c44ed17<br /> ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot")<br /> and commit 0ca0485e4b2e ("fs/ntfs3: validate rec-&gt;used in<br /> journal-replay file record check").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref<br /> <br /> l2cap_chan_timeout() runs asynchronously and accesses chan-&gt;conn. If<br /> the connection is torn down while the timer is running or pending,<br /> chan-&gt;conn can be freed, leading to a use-after-free when the timer<br /> worker attempts to lock conn-&gt;lock:<br /> <br /> | BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:112 [inline]<br /> | BUG: KASAN: slab-use-after-free in atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]<br /> | BUG: KASAN: slab-use-after-free in __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]<br /> | BUG: KASAN: slab-use-after-free in mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318<br /> | Write of size 8 at addr ffff8881298d9550 by task kworker/2:1/83<br /> |<br /> | CPU: 2 UID: 0 PID: 83 Comm: kworker/2:1 Not tainted 7.1.0-rc6-next-20260601-dirty #6 PREEMPT(full)<br /> | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014<br /> | Workqueue: events l2cap_chan_timeout<br /> | Call Trace:<br /> | <br /> | instrument_atomic_read_write include/linux/instrumented.h:112 [inline]<br /> | atomic_long_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:4456 [inline]<br /> | __mutex_trylock_fast kernel/locking/mutex.c:161 [inline]<br /> | mutex_lock+0x4f/0xa0 kernel/locking/mutex.c:318<br /> | l2cap_chan_timeout+0x5d/0x1b0 net/bluetooth/l2cap_core.c:422<br /> | process_one_work kernel/workqueue.c:3326 [inline]<br /> | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409<br /> | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490<br /> | kthread+0x346/0x430 kernel/kthread.c:436<br /> | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158<br /> | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> | <br /> |<br /> | Allocated by task 320:<br /> | l2cap_conn_add+0xa7/0x820 net/bluetooth/l2cap_core.c:7075<br /> | l2cap_connect_cfm+0xdb/0xd70 net/bluetooth/l2cap_core.c:7452<br /> | hci_connect_cfm include/net/bluetooth/hci_core.h:2139 [inline]<br /> | hci_remote_features_evt+0x52f/0x9f0 net/bluetooth/hci_event.c:3760<br /> | hci_event_func net/bluetooth/hci_event.c:7796 [inline]<br /> | hci_event_packet+0x561/0xa70 net/bluetooth/hci_event.c:7847<br /> | hci_rx_work+0x370/0x890 net/bluetooth/hci_core.c:4040<br /> | process_one_work kernel/workqueue.c:3326 [inline]<br /> | process_scheduled_works+0x7c8/0xfb0 kernel/workqueue.c:3409<br /> | worker_thread+0x8a9/0xcf0 kernel/workqueue.c:3490<br /> | kthread+0x346/0x430 kernel/kthread.c:436<br /> | ret_from_fork+0x1a3/0x470 arch/x86/kernel/process.c:158<br /> | ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> |<br /> | Freed by task 322:<br /> | hci_disconn_cfm include/net/bluetooth/hci_core.h:2154 [inline]<br /> | hci_conn_hash_flush+0x101/0x1f0 net/bluetooth/hci_conn.c:2736<br /> | hci_dev_close_sync+0x889/0xde0 net/bluetooth/hci_sync.c:5405<br /> | hci_dev_do_close net/bluetooth/hci_core.c:502 [inline]<br /> | hci_unregister_dev+0x1f7/0x370 net/bluetooth/hci_core.c:2679<br /> | vhci_release+0x12a/0x180 drivers/bluetooth/hci_vhci.c:690<br /> | __fput+0x369/0x890 fs/file_table.c:510<br /> | task_work_run+0x160/0x1d0 kernel/task_work.c:233<br /> | get_signal+0xf5b/0x1120 kernel/signal.c:2810<br /> | arch_do_signal_or_restart+0x4d/0x600 arch/x86/kernel/signal.c:337<br /> | __exit_to_user_mode_loop kernel/entry/common.c:64 [inline]<br /> | exit_to_user_mode_loop+0x85/0x510 kernel/entry/common.c:98<br /> | do_syscall_64+0x263/0x3d0 arch/x86/entry/syscall_64.c:100<br /> | entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> |<br /> | The buggy address belongs to the object at ffff8881298d9400<br /> | which belongs to the cache kmalloc-512 of size 512<br /> | The buggy address is located 336 bytes inside of<br /> | freed 512-byte region [ffff8881298d9400, ffff8881298d9600)<br /> <br /> Fix it by having chan-&gt;conn hold a reference to l2cap_conn (via<br /> l2cap_conn_get) when the channel is added to the connection, and<br /> releasing it in the channel destructor. This ensures the l2cap_conn<br /> remains alive as long as the channel exists.<br /> <br /> A new FLAG_DEL channel flag is introduced to indicate that the ch<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: Fix data races of skb_queue_len() readers on audit_queue<br /> <br /> Multiple readers access audit_queue.qlen via skb_queue_len() without<br /> holding the queue lock or using READ_ONCE(), while kauditd writes to<br /> this field via the skb_dequeue() → __skb_unlink() path with WRITE_ONCE()<br /> protected by a spinlock. This constitutes data races.<br /> <br /> All affected skb_queue_len(&amp;audit_queue) call sites:<br /> - kauditd_thread() wait_event_freezable() condition<br /> - audit_receive_msg() AUDIT_GET handler (s.backlog assignment)<br /> - audit_receive() backlog check<br /> - audit_log_start() backlog check and pr_warn()<br /> <br /> KCSAN reports the following conflicting access pattern (one example):<br /> ==================================================================<br /> BUG: KCSAN: data-race in audit_log_start / skb_dequeue<br /> <br /> write (marked) to 0xffffffff8512ee20 of 4 bytes by task 661 on cpu 57:<br /> skb_dequeue+0x70/0xf0<br /> kauditd_send_queue+0x71/0x220<br /> kauditd_thread+0x1cb/0x430<br /> kthread+0x1c2/0x210<br /> ret_from_fork+0x162/0x1a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> read to 0xffffffff8512ee20 of 4 bytes by task 36586 on cpu 1:<br /> audit_log_start+0x2a0/0x6b0<br /> audit_core_dumps+0x64/0xa0<br /> do_coredump+0x14b/0x1260<br /> get_signal+0xeb2/0xf70<br /> arch_do_signal_or_restart+0x41/0x170<br /> exit_to_user_mode_loop+0xa2/0x1c0<br /> do_syscall_64+0x1a3/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0xe0<br /> <br /> value changed: 0x00000001 -&gt; 0x00000000<br /> ==================================================================<br /> <br /> Resolve the race by switching to lockless helper skb_queue_len_lockless(),<br /> which internally uses READ_ONCE() and properly pairs with the WRITE_ONCE()<br /> write accesses already present on the writer side.<br /> <br /> [PM: line length tweak]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: nxp: imx8-isi: Fix use-after-free on remove<br /> <br /> KASAN reports a slab-use-after-free in __media_entity_remove_link()<br /> during rmmod of imx8_isi:<br /> <br /> BUG: KASAN: slab-use-after-free in __media_entity_remove_link+0x608/0x650<br /> Read of size 2 at addr ffff0000d47cb02a by task rmmod/724<br /> <br /> Call trace:<br /> __media_entity_remove_link+0x608/0x650<br /> __media_entity_remove_links+0x78/0x144<br /> __media_device_unregister_entity+0x150/0x280<br /> media_device_unregister_entity+0x48/0x68<br /> v4l2_device_unregister_subdev+0x158/0x300<br /> v4l2_async_unbind_subdev_one+0x22c/0x358<br /> v4l2_async_nf_unbind_all_subdevs+0xfc/0x1c0<br /> v4l2_async_nf_unregister+0x5c/0x14c<br /> mxc_isi_remove+0x124/0x2a0 [imx8_isi]<br /> <br /> Allocated by task 249:<br /> __kmalloc_noprof+0x27c/0x690<br /> mxc_isi_crossbar_init+0x22c/0x560 [imx8_isi]<br /> <br /> Freed by task 724:<br /> kfree+0x1e4/0x5b0<br /> mxc_isi_crossbar_cleanup+0x34/0x80 [imx8_isi]<br /> mxc_isi_remove+0x11c/0x2a0 [imx8_isi]<br /> <br /> The problem is that mxc_isi_remove() calls mxc_isi_crossbar_cleanup()<br /> before mxc_isi_v4l2_cleanup(). The crossbar cleanup frees the media<br /> entity pads, but the subsequent v4l2 cleanup still tries to remove<br /> media links that reference those pads.<br /> <br /> Fix this by calling mxc_isi_v4l2_cleanup() before<br /> mxc_isi_crossbar_cleanup() to ensure all media entities are properly<br /> unregistered while the pads are still valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netpoll: fix a use-after-free on shutdown path<br /> <br /> There is a use-after-free error on netpoll, which is clearly detected by<br /> KASAN.<br /> <br /> BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80<br /> Read of size 1 at addr ... by task kworker/9:1<br /> Workqueue: events queue_process<br /> Call Trace:<br /> skb_dequeue+0x1e/0xb0<br /> queue_process+0x2c/0x600<br /> process_scheduled_works+0x4b6/0x850<br /> worker_thread+0x414/0x5a0<br /> Allocated by task 242:<br /> __netpoll_setup+0x201/0x4a0<br /> netpoll_setup+0x249/0x550<br /> enabled_store+0x32f/0x380<br /> Freed by task 0:<br /> kfree+0x1b7/0x540<br /> rcu_core+0x3f8/0x7a0<br /> <br /> The problem happens when there is a pending TX worker running in<br /> parallel with the cleanup path.<br /> <br /> This is what happens on netpoll shutdown path:<br /> <br /> 1) __netpoll_cleanup() is called<br /> 2) set dev-&gt;npinfo to NULL<br /> 3) call_rcu() with rcu_cleanup_netpoll_info()<br /> 3.1) rcu_cleanup_netpoll_info() tries to cancel all workers with<br /> cancel_delayed_work(), but doesn&amp;#39;t wait for the worker to finish<br /> 4) and kfree(npinfo);<br /> <br /> Because 3.1) doesn&amp;#39;t really cancel the work, as the comment says "we<br /> can&amp;#39;t call cancel_delayed_work_sync here, as we are in softirq", the TX<br /> worker can run after 4).<br /> <br /> Tl;DR: queue_process() is not an RCU reader, it reaches npinfo through<br /> the work item via container_of().<br /> <br /> Use disable_delayed_work_sync() to ensure the worker is completely<br /> stopped and prevent any future re-arming attempts. Once npinfo is set<br /> to NULL, senders will bail out and not queue new work. The disable flag<br /> ensures any in-flight re-arming attempts also fail silently.<br /> <br /> In the future, we can do the cleanup inline here without needing the<br /> npinfo-&gt;rcu rcu_head, but that is net-next material.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/io-wq: re-check IO_WQ_BIT_EXIT for each linked work item<br /> <br /> commit 10dc95939817 ("io_uring/io-wq: check IO_WQ_BIT_EXIT inside work<br /> run loop") fixed the obvious case where io_worker_handle_work() took one<br /> exit-bit snapshot before draining pending work, but the fix stops one<br /> level too early.<br /> <br /> io_worker_handle_work() now re-checks IO_WQ_BIT_EXIT in its outer work<br /> run loop, yet it still snapshots that bit once before processing a whole<br /> dependent linked-work chain. If io_wq_exit_start() sets IO_WQ_BIT_EXIT<br /> after the first linked item has started, the remaining linked items can<br /> still reuse stale do_kill = false, skip IO_WQ_WORK_CANCEL, and continue<br /> running after exit has begun.<br /> <br /> Move the check further inside, so it covers linked items too. Note: this<br /> is a syzbot special as it loves setting up tons of slow linked work on<br /> weird devices like msr that take forever to read, and immediately close<br /> the ring. Exit then takes a long time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/nop: fix file reference leak with IOSQE_FIXED_FILE<br /> <br /> NOP file-acquisition support choses between a fixed (registered) file and<br /> a normal fget()&amp;#39;d file based on its own IORING_NOP_FIXED_FILE flag in<br /> sqe-&gt;nop_flags. However, a request&amp;#39;s REQ_F_FIXED_FILE is set<br /> independently from the generic IOSQE_FIXED_FILE sqe flag during request<br /> init, before the issue handler runs.<br /> <br /> If a NOP is submitted with IOSQE_FIXED_FILE set (so REQ_F_FIXED_FILE is<br /> set) but without IORING_NOP_FIXED_FILE, io_nop() takes the normal path<br /> and grabs a real reference via io_file_get_normal(). On completion,<br /> io_put_file() only drops the reference when REQ_F_FIXED_FILE is clear,<br /> so the fget()&amp;#39;d file is never released and leaks:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88800f42c240 (size 176):<br /> kmem_cache_alloc_noprof+0x358/0x440<br /> alloc_empty_file+0x57/0x180<br /> path_openat+0x44/0x1e50<br /> do_file_open+0x121/0x200<br /> do_sys_openat2+0xa7/0x150<br /> __x64_sys_openat+0x82/0xf0<br /> <br /> Decide between fixed and normal file acquisition from REQ_F_FIXED_FILE,<br /> the same way io_assign_file() does for every other opcode, and fold<br /> IORING_NOP_FIXED_FILE into REQ_F_FIXED_FILE at prep time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: logitech-dj: Fix maxfield check in DJ short report validation<br /> <br /> Commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT<br /> related user initiated OOB write") added validation for the DJ short<br /> output report, but the error path dereferences rep-&gt;field[0] even when<br /> rep-&gt;maxfield is zero.<br /> <br /> Commit 8b9a097eb2fc ("HID: logitech-dj: fix wrong detection of bad<br /> DJ_SHORT output report") made the check conditional on rep being present,<br /> but a crafted descriptor can still create report ID 0x20 with only padding<br /> output items. hid-core registers the report, ignores the padding field,<br /> and leaves rep-&gt;maxfield as zero.<br /> <br /> In that case the validation enters the rep-&gt;maxfield field[0]-&gt;report_count while printing the error message,<br /> causing a NULL pointer dereference during probe. This is reproducible with<br /> uhid by emulating a Logitech receiver with a padding-only DJ short output<br /> report:<br /> <br /> BUG: KASAN: null-ptr-deref in logi_dj_probe+0xb1/0x754 [hid_logitech_dj]<br /> Read of size 4 at addr 0000000000000028 by task kworker/4:1/129<br /> ...<br /> Call Trace:<br /> logi_dj_probe+0xb1/0x754 [hid_logitech_dj]<br /> hid_device_probe+0x329/0x3f0 [hid]<br /> really_probe+0x162/0x570<br /> __device_attach+0x137/0x2c0<br /> bus_probe_device+0x38/0xc0<br /> device_add+0xa56/0xce0<br /> hid_add_device+0x19c/0x280 [hid]<br /> uhid_device_add_worker+0x2c/0xb0 [uhid]<br /> <br /> Reject the zero-field report before printing the field report_count.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: sch: use raw_spinlock_t in the irq startup path<br /> <br /> sch_irq_unmask() enables the GPIO IRQ and then updates the controller<br /> state through sch_irq_mask_unmask(), which takes sch-&gt;lock with<br /> spin_lock_irqsave(). The callback can be reached from irq_startup()<br /> while setting up a requested IRQ. That path is not sleepable, but on<br /> PREEMPT_RT a regular spinlock_t becomes a sleeping lock.<br /> <br /> This issue was found by our static analysis tool and then manually<br /> reviewed against the current tree.<br /> <br /> The grounded PoC kept the request_threaded_irq() -&gt; __setup_irq() -&gt;<br /> irq_startup() -&gt; sch_irq_unmask() -&gt; sch_irq_mask_unmask() carrier and<br /> used the original spin_lock_irqsave(&amp;sch-&gt;lock) edge. Lockdep reported:<br /> <br /> BUG: sleeping function called from invalid context<br /> hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]<br /> sch_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]<br /> sch_irq_mask_unmask.constprop.0+0x31/0x70 [vuln_msv]<br /> __setup_irq.constprop.0+0xd/0x30 [vuln_msv]<br /> <br /> Convert the SCH controller lock to raw_spinlock_t. The same lock is<br /> also used by the GPIO direction and value callbacks, but those critical<br /> sections only update MMIO-backed GPIO registers and do not contain<br /> sleepable operations. Keeping this register lock non-sleeping is<br /> therefore appropriate for the irqchip callbacks and does not change the<br /> GPIO-side locking contract.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes<br /> <br /> Reject invalid `net.ipv4.tcp_reordering` values before they reach TCP<br /> socket state. The sysctl is stored as an `int` but copied into the<br /> `u32` `tp-&gt;reordering` field for new sockets, so negative writes wrap<br /> to large values.<br /> <br /> With `tcp_mtu_probing=2`, the wrapped value can overflow the<br /> `tcp_mtu_probe()` size calculation and drive the MTU probing path into<br /> an out-of-bounds read. Route `tcp_reordering` writes through<br /> `proc_dointvec_minmax()` and require it to be at least 1. Also require<br /> `tcp_max_reordering` to be at least 1 so the configured maximum cannot<br /> become negative either.<br /> <br /> When registering the table for a non-init network namespace, relocate<br /> `extra2` pointers that refer into `init_net.ipv4` so the<br /> `tcp_reordering` upper bound follows that namespace&amp;#39;s<br /> `tcp_max_reordering`.<br /> <br /> Harden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`.<br /> This keeps the send queue and window checks from being bypassed through<br /> signed integer overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: igmp: remove multicast group from hash table on device destruction<br /> <br /> When a device is destroyed under RTNL, ip_mc_destroy_dev() iterates through<br /> the multicast list and calls ip_ma_put() on each membership, scheduling<br /> them for RCU reclamation. However, they are not unlinked from the device&amp;#39;s<br /> multicast hash table (mc_hash).<br /> <br /> Since the device remains published in dev-&gt;ip_ptr until after<br /> ip_mc_destroy_dev() completes, concurrent RCU readers traversing mc_hash<br /> can still locate and access the multicast group after its refcount is<br /> decremented. If the RCU callback runs and frees the group while a reader is<br /> accessing it, a use-after-free occurs.<br /> <br /> Fix this by unlinking the multicast group from mc_hash using<br /> ip_mc_hash_remove() before scheduling it for reclamation.<br /> <br /> BUG: KASAN: slab-use-after-free in ip_check_mc_rcu+0x149/0x3f0<br /> Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x67/0x90<br /> print_report+0x175/0x7c0<br /> kasan_report+0x147/0x180<br /> ip_check_mc_rcu+0x149/0x3f0<br /> udp_v4_early_demux+0x36d/0x12d0<br /> ip_rcv_finish_core+0xb8b/0x1390<br /> ip_rcv_finish+0x54/0x120<br /> NF_HOOK+0x213/0x2b0<br /> __netif_receive_skb+0x126/0x340<br /> process_backlog+0x4f2/0xf00<br /> __napi_poll+0x92/0x2c0<br /> net_rx_action+0x583/0xc60<br /> handle_softirqs+0x236/0x7f0<br /> do_softirq+0x57/0x80<br /> <br /> <br /> Allocated by task 2239:<br /> kasan_save_track+0x3e/0x80<br /> __kasan_kmalloc+0x72/0x90<br /> ____ip_mc_inc_group+0x31a/0xa40<br /> __ip_mc_join_group+0x334/0x3f0<br /> do_ip_setsockopt+0x16fa/0x2010<br /> ip_setsockopt+0x3f/0x90<br /> do_sock_setsockopt+0x1ad/0x300<br /> <br /> Freed by task 0:<br /> kasan_save_track+0x3e/0x80<br /> kasan_save_free_info+0x40/0x50<br /> __kasan_slab_free+0x3a/0x60<br /> __rcu_free_sheaf_prepare+0xd4/0x220<br /> rcu_free_sheaf+0x36/0x190<br /> rcu_core+0x8d9/0x12f0<br /> handle_softirqs+0x236/0x7f0