Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB reads in IE loops in issue_assocreq() and join_cmd_hdl()<br /> <br /> Two IE parsing loops are missing the header bounds checks before they<br /> dereference pIE-&gt;length:<br /> <br /> - issue_assocreq() walks pmlmeinfo-&gt;network.ies to build the<br /> association request. If the stored IE data ends with only an<br /> element_id byte and no length byte, pIE-&gt;length is read one byte<br /> past the end of the buffer.<br /> <br /> - join_cmd_hdl() walks pnetwork-&gt;ies during station join and has<br /> the same problem under the same conditions.<br /> <br /> Both buffers are filled from AP beacon and probe-response frames, so a<br /> malicious AP that sends a truncated final IE can trigger the issue.<br /> <br /> Apply the two-guard pattern established in update_beacon_info():<br /> 1. Break if fewer than sizeof(*pIE) bytes remain.<br /> 2. Break if the IE&amp;#39;s declared data extends past the buffer end.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix OOB read in update_beacon_info() IE loop<br /> <br /> The IE parsing loop in update_beacon_info() advances by<br /> (pIE-&gt;length + 2) each iteration but only guards on i length from one byte past the allocated receive buffer.<br /> <br /> Additionally, even when the header bytes are in bounds, pIE-&gt;length<br /> itself can extend the data window beyond len, passing a truncated IE<br /> to the handler functions.<br /> <br /> Add two guards at the top of the loop body:<br /> 1. Break if fewer than sizeof(*pIE) bytes remain (can&amp;#39;t read header).<br /> 2. Break if the IE&amp;#39;s declared data extends past len.<br /> <br /> Also replace i += (pIE-&gt;length + 2) with i += sizeof(*pIE) + pIE-&gt;length<br /> for consistency with the sizeof(*pIE) guards added above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: eic-sprd: use raw_spinlock_t in the irq startup path<br /> <br /> sprd_eic_irq_unmask() enables the GPIO IRQ and then updates controller<br /> state through sprd_eic_update(), which takes sprd_eic-&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; sprd_eic_irq_unmask() -&gt; sprd_eic_update() carrier and<br /> used the original spin_lock_irqsave(&amp;sprd_eic-&gt;lock) edge. Lockdep<br /> <br /> BUG: sleeping function called from invalid context<br /> hardirqs last disabled at ... __setup_irq.constprop.0 ... [vuln_msv]<br /> sprd_rt_spin_lock_irqsave+0x1c/0x30 [vuln_msv]<br /> sprd_eic_update.constprop.0+0x48/0x90 [vuln_msv]<br /> sprd_eic_irq_unmask.constprop.0+0x35/0x50 [vuln_msv]<br /> __setup_irq.constprop.0+0xd/0x30 [vuln_msv]<br /> <br /> Convert the Spreadtrum EIC controller lock to raw_spinlock_t. The<br /> locked section only serializes MMIO register updates and does not contain<br /> sleepable operations, so keeping it non-sleeping is appropriate for the<br /> irqchip callbacks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix UAF of hci_conn_params in add_device_complete<br /> <br /> add_device_complete() runs from the hci_cmd_sync_work kworker, which<br /> holds only hci_req_sync_lock and *not* hci_dev_lock. It calls<br /> hci_conn_params_lookup() and then dereferences the returned object<br /> (params-&gt;flags) without taking hci_dev_lock:<br /> <br /> params = hci_conn_params_lookup(hdev, &amp;cp-&gt;addr.bdaddr,<br /> le_addr_type(cp-&gt;addr.type));<br /> ...<br /> device_flags_changed(NULL, hdev, &amp;cp-&gt;addr.bdaddr,<br /> cp-&gt;addr.type, hdev-&gt;conn_flags,<br /> params ? params-&gt;flags : 0);<br /> <br /> hci_conn_params_lookup() walks hdev-&gt;le_conn_params and is documented to<br /> require hdev-&gt;lock. A concurrent MGMT_OP_REMOVE_DEVICE<br /> (remove_device()), which does run under hci_dev_lock, can call<br /> hci_conn_params_free() to list_del() and kfree() the very object the<br /> lookup returned, so the subsequent params-&gt;flags read touches freed<br /> memory [0].<br /> <br /> Hold hci_dev_lock() across the hci_conn_params_lookup() and the read of<br /> params-&gt;flags (and the matching event emission) so the lookup result<br /> cannot be freed by a concurrent remove_device() before it is used,<br /> honouring the locking contract of hci_conn_params_lookup().<br /> <br /> [0]: (trailing page/memory-state dump trimmed)<br /> BUG: KASAN: slab-use-after-free in add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671<br /> Read of size 1 at addr ffff000017ab26c1 by task kworker/u9:8/388<br /> <br /> CPU: 1 UID: 0 PID: 388 Comm: kworker/u9:8 Not tainted 7.0.11 #20 PREEMPT<br /> Hardware name: linux,dummy-virt (DT)<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call trace:<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:499 (C)<br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0xb4/0xd4 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x118/0x5d8 mm/kasan/report.c:482<br /> kasan_report+0xb0/0xf4 mm/kasan/report.c:595<br /> __asan_report_load1_noabort+0x20/0x2c mm/kasan/report_generic.c:378<br /> add_device_complete+0x358/0x3d8 net/bluetooth/mgmt.c:7671<br /> hci_cmd_sync_work+0x14c/0x240 net/bluetooth/hci_sync.c:334<br /> process_one_work+0x628/0xd38 kernel/workqueue.c:3289<br /> process_scheduled_works kernel/workqueue.c:3372 [inline]<br /> worker_thread+0x7a8/0xac0 kernel/workqueue.c:3453<br /> kthread+0x39c/0x444 kernel/kthread.c:436<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860<br /> <br /> Allocated by task 3401:<br /> kasan_save_stack+0x3c/0x64 mm/kasan/common.c:57<br /> kasan_save_track+0x20/0x3c mm/kasan/common.c:78<br /> kasan_save_alloc_info+0x40/0x54 mm/kasan/generic.c:570<br /> poison_kmalloc_redzone mm/kasan/common.c:398 [inline]<br /> __kasan_kmalloc+0xd4/0xd8 mm/kasan/common.c:415<br /> kasan_kmalloc include/linux/kasan.h:263 [inline]<br /> __kmalloc_cache_noprof+0x1b0/0x458 mm/slub.c:5385<br /> kmalloc_noprof include/linux/slab.h:950 [inline]<br /> kzalloc_noprof include/linux/slab.h:1188 [inline]<br /> hci_conn_params_add+0x10c/0x4b0 net/bluetooth/hci_core.c:2279<br /> hci_conn_params_set net/bluetooth/mgmt.c:5162 [inline]<br /> add_device+0x5b4/0xa54 net/bluetooth/mgmt.c:7755<br /> hci_mgmt_cmd net/bluetooth/hci_sock.c:1721 [inline]<br /> hci_sock_sendmsg+0x10b4/0x1dd0 net/bluetooth/hci_sock.c:1841<br /> sock_sendmsg_nosec net/socket.c:727 [inline]<br /> __sock_sendmsg+0xe0/0x128 net/socket.c:742<br /> sock_write_iter+0x250/0x390 net/socket.c:1195<br /> new_sync_write fs/read_write.c:595 [inline]<br /> vfs_write+0x66c/0xab0 fs/read_write.c:688<br /> ksys_write+0x1fc/0x24c fs/read_write.c:740<br /> __do_sys_write fs/read_write.c:751 [inline]<br /> __se_sys_write fs/read_write.c:748 [inline]<br /> __arm64_sys_write+0x70/0xa4 fs/read_write.c:748<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x84/0x2a8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common.constprop.0+0xe4/0x294 arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x44/0x5c arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x38/0xac arch/arm64/kernel/entry-common.c:724<br /> el0t_64_sync_handler+0xa0/0xe4 arch/arm64/kernel/entry-common.c:743<br /> el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:596<br /> <br /> Freed by task 3740:<br /> kasan_save_stack+0x3c/0x64 <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NTB: epf: Avoid calling pci_irq_vector() from hardirq context<br /> <br /> ntb_epf_vec_isr() calls pci_irq_vector() in hardirq context to derive<br /> the vector number. pci_irq_vector() calls msi_get_virq() that takes a<br /> mutex and can therefore trigger "scheduling while atomic" splats:<br /> <br /> BUG: scheduling while atomic: kworker/u33:0/55/0x00010001<br /> ...<br /> Call trace:<br /> ...<br /> schedule+0x38/0x110<br /> schedule_preempt_disabled+0x28/0x50<br /> __mutex_lock.constprop.0+0x848/0x908<br /> __mutex_lock_slowpath+0x18/0x30<br /> mutex_lock+0x4c/0x60<br /> msi_domain_get_virq+0xe8/0x138<br /> pci_irq_vector+0x2c/0x60<br /> ntb_epf_vec_isr+0x28/0x120 [ntb_hw_epf]<br /> __handle_irq_event_percpu+0x70/0x3a8<br /> handle_irq_event+0x48/0x100<br /> handle_edge_irq+0x100/0x1c8<br /> ...<br /> <br /> Cache the Linux IRQ number for vector 0 when vectors are allocated and<br /> use it as a base in the ISR. Running the ISR in a threaded IRQ handler<br /> would also avoid the problem, but that would be unnecessary here.

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.