Vulnerabilities

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 /> 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

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 /> netfilter: ebtables: zero chainstack array<br /> <br /> sashiko reports:<br /> looking at ebtables table<br /> translation, could a sparse cpu_possible_mask lead to an uninitialized pointer<br /> free?<br /> <br /> If cpu_possible_mask is sparse (for example, CPU 0 and CPU 2 are possible,<br /> but CPU 1 is not), the allocation loop skips CPU 1. If vmalloc_node() fails at<br /> CPU 2, the cleanup loop will blindly decrement and call vfree() on<br /> newinfo-&gt;chainstack[1].<br /> <br /> Not a real-world bug, such allocation isn&amp;#39;t expected to fail<br /> in the first place.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: handle unreadable frags<br /> <br /> sashiko reports:<br /> When an skb with unreadable fragments (such as from devmem TCP, where<br /> skb_frags_readable(skb) returns false) is processed by the u32 module,<br /> skb_copy_bits() will safely return a negative error code [..]<br /> <br /> xt_u32: bail out with hotdrop in this case.<br /> gather_frags: return -1, just as if we had no fragment header.<br /> nfnetlink_queue: restrict to the linear part.<br /> nfnetlink_log: restrict to the linear part.<br /> <br /> v2:<br /> - skb_zerocopy helpers don&amp;#39;t copy readable flag, i.e. nfnetlink_queue<br /> is broken too<br /> xt_u32 shouldn&amp;#39;t return true if hotdrop was set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/swap: add cond_resched() in swap_reclaim_full_clusters to prevent softlockup<br /> <br /> We hit a real softlockup in an internal stress test environment. The<br /> workload was LTP memory/swap stress on a large arm64 machine, with 320<br /> CPUs, about 1TB memory and an 8.6GB swap device. The system was under<br /> heavy load and the swap device had a large number of full clusters. The<br /> softlockup was triggered during a stress test after about 3 days.<br /> <br /> So, add periodic cond_resched() calls during large full_clusters<br /> reclaim operations to prevent softlockup issues.<br /> <br /> Detailed call trace as follow:<br /> <br /> PID: 3817773 TASK: ffff0883bb28b780 CPU: 48 COMMAND: "kworker/48:7"<br /> #0 [ffff800080183d10] __crash_kexec at ffffa4c1361e5de4<br /> #1 [ffff800080183d90] panic at ffffa4c1360d5e9c<br /> #2 [ffff800080183e20] watchdog_timer_fn at ffffa4c136231fa8<br /> ...<br /> #16 [ffff8000c4ad3cb0] swap_cache_del_folio at ffffa4c1363e1614<br /> #17 [ffff8000c4ad3ce0] __try_to_reclaim_swap at ffffa4c1363e4bfc<br /> #18 [ffff8000c4ad3d40] swap_reclaim_full_clusters at ffffa4c1363e5474<br /> #19 [ffff8000c4ad3da0] swap_reclaim_work at ffffa4c1363e550c<br /> #20 [ffff8000c4ad3dc0] process_one_work at ffffa4c136102edc<br /> #21 [ffff8000c4ad3e10] worker_thread at ffffa4c136103398<br /> #22 [ffff8000c4ad3e70] kthread at ffffa4c13610d95c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: swap_cgroup: fix NULL deref in lookup_swap_cgroup_id on swapless host<br /> <br /> lookup_swap_cgroup_id() passes swap_cgroup_ctrl[type].map to<br /> __swap_cgroup_id_lookup() without checking that the type was ever<br /> registered via swap_cgroup_swapon(). On a swapless host every ctrl-&gt;map<br /> is NULL, so __swap_cgroup_id_lookup() dereferences NULL + a scaled<br /> swp_offset().<br /> <br /> Since commit bea67dcc5eea ("mm: attempt to batch free swap entries for<br /> zap_pte_range()"), zap_pte_range() -&gt; swap_pte_batch() calls<br /> lookup_swap_cgroup_id() on any non-present, non-none PTE that decodes as a<br /> real swap entry, without first validating it against swap_info[]. A<br /> single PTE corrupted into a type-0 swap entry takes the host down at<br /> process exit.<br /> <br /> We hit this in production on a swapless 6.12.58 host: ~1s of<br /> "get_swap_device: Bad swap file entry 3f800204222bb" (do_swap_page() being<br /> correctly defensive about the same entry) followed by<br /> <br /> BUG: unable to handle page fault for address: 000003f800204220<br /> RIP: 0010:lookup_swap_cgroup_id+0x2b/0x60<br /> Call Trace:<br /> swap_pte_batch+0xbf/0x230<br /> zap_pte_range+0x4c8/0x780<br /> unmap_page_range+0x190/0x3e0<br /> exit_mmap+0xd9/0x3c0<br /> do_exit+0x20c/0x4b0<br /> <br /> syzbot has reported the identical stack.<br /> <br /> The source of the PTE corruption is a separate bug; this change makes the<br /> teardown path as robust as the fault path already is. Every other caller<br /> of lookup_swap_cgroup_id() is downstream of a get_swap_device() that has<br /> already validated the entry, so the new branch is cold.