Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: shrinker: fix NULL pointer dereference in debugfs<br /> <br /> shrinker_debugfs_add() creates both "count" and "scan" debugfs files<br /> unconditionally.<br /> <br /> That assumes every shrinker implements both count_objects() and<br /> scan_objects(), which is not guaranteed. For example, the xen-backend<br /> shrinker sets count_objects() but leaves scan_objects() NULL, so writing<br /> to its scan file calls through a NULL function pointer and panics the<br /> kernel:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> Call Trace:<br /> <br /> shrinker_debugfs_scan_write+0x12e/0x270<br /> full_proxy_write+0x5f/0x90<br /> vfs_write+0xde/0x420<br /> ? filp_flush+0x75/0x90<br /> ? filp_close+0x1d/0x30<br /> ? do_dup2+0xb8/0x120<br /> ksys_write+0x68/0xf0<br /> ? filp_flush+0x75/0x90<br /> do_syscall_64+0xb3/0x5b0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The count path has the same issue in principle if a shrinker omits<br /> count_objects().<br /> <br /> To fix it, only create "count" and "scan" debugfs files when the<br /> corresponding callbacks are present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: shrinker: fix shrinker_info teardown race with expansion<br /> <br /> expand_shrinker_info() iterates all visible memcgs under shrinker_mutex,<br /> including memcgs that have not finished -&gt;css_online() yet.<br /> <br /> Once pn-&gt;shrinker_info has been published, teardown must stay serialized<br /> with expand_shrinker_info() until that memcg is either fully online or no<br /> longer visible to iteration. Today alloc_shrinker_info() breaks that rule<br /> by dropping shrinker_mutex before freeing a partially initialized<br /> shrinker_info array, which may cause the following race:<br /> <br /> CPU0 CPU1<br /> ==== ====<br /> <br /> css_create<br /> --&gt; list_add_tail_rcu(&amp;css-&gt;sibling, &amp;parent_css-&gt;children);<br /> online_css<br /> --&gt; mem_cgroup_css_online<br /> --&gt; alloc_shrinker_info<br /> --&gt; alloc node0 info<br /> rcu_assign_pointer(C-&gt;node0-&gt;shrinker_info, old0)<br /> alloc node1 info -&gt; FAIL -&gt; goto err<br /> mutex_unlock(shrinker_mutex)<br /> <br /> shrinker_alloc()<br /> --&gt; shrinker_memcg_alloc<br /> --&gt; mutex_lock(shrinker_mutex)<br /> expand_shrinker_info<br /> --&gt; mem_cgroup_iter see the memcg<br /> expand_one_shrinker_info<br /> --&gt; old0 = C-&gt;node0-&gt;shrinker_info<br /> memcpy(new-&gt;unit, old0-&gt;unit, ...);<br /> <br /> free_shrinker_info<br /> --&gt; kvfree(old0);<br /> <br /> /* double free !! */<br /> kvfree_rcu(old0, rcu);<br /> <br /> The same problem exists later in mem_cgroup_css_online(). If<br /> alloc_shrinker_info() succeeds but a subsequent objcg allocation fails,<br /> the free_objcg -&gt; free_shrinker_info() unwind path tears down the already<br /> published pn-&gt;shrinker_info arrays without shrinker_mutex. The<br /> expand_one_shrinker_info() can race with that teardown in the same way,<br /> leading to use-after-free or double-free of the old shrinker_info.<br /> <br /> Fix this by serializing shrinker_info teardown with shrinker_mutex, and by<br /> keeping alloc_shrinker_info() error cleanup inside the locked section.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/shrinker: do not hold RCU lock in shrinker_debugfs_count_show()<br /> <br /> Reading the debugfs "count" file of a memcg-aware shrinker can sleep<br /> inside an RCU read-side critical section:<br /> <br /> BUG: sleeping function called from invalid context at kernel/cgroup/rstat.c:421<br /> RCU nest depth: 1, expected: 0<br /> css_rstat_flush<br /> mem_cgroup_flush_stats<br /> zswap_shrinker_count<br /> shrinker_debugfs_count_show<br /> <br /> shrinker_debugfs_count_show() invokes the -&gt;count_objects() callback under<br /> rcu_read_lock(). The zswap callback flushes memcg stats via<br /> css_rstat_flush(), which may sleep, so it must not run under RCU.<br /> <br /> The RCU lock is not needed here. mem_cgroup_iter() takes RCU internally<br /> and returns a memcg holding a css reference (dropped on the next iteration<br /> or by mem_cgroup_iter_break()), so the memcg stays alive without it. The<br /> shrinker is kept alive by the open debugfs file: shrinker_free() removes<br /> the debugfs entries via debugfs_remove_recursive(), which waits for<br /> in-flight readers to drain, before call_rcu(..., shrinker_free_rcu_cb). <br /> The sibling "scan" handler already invokes the sleeping -&gt;scan_objects()<br /> callback with no RCU section.<br /> <br /> Drop the rcu_read_lock()/rcu_read_unlock().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: cros_ec: Delay dev_set_drvdata() until probe success<br /> <br /> If ec_device_probe() fails, cros_ec_class_release releases memory for the<br /> cros_ec_dev structure. However, because the drvdata was already set,<br /> sub-drivers like cros_ec_typec can still retrieve the stale pointer via the<br /> platform device. This leads to a use-after-free when cros_ec_typec attempts<br /> to access &amp;typec-&gt;ec-&gt;ec-&gt;dev on a device that has already been released.<br /> Move dev_set_drvdata() to ensure that the pointer is only made available<br /> once all initialization steps have succeeded.<br /> <br /> sysfs: cannot create duplicate filename &amp;#39;/class/chromeos/cros_ec&amp;#39;<br /> Call trace:<br /> sysfs_do_create_link_sd+0x94/0xdc<br /> sysfs_create_link+0x30/0x44<br /> device_add_class_symlinks+0x90/0x13c<br /> device_add+0xf0/0x50c<br /> ec_device_probe+0x150/0x4f0<br /> platform_probe+0xa0/0xe0<br /> ...<br /> BUG: KASAN: invalid-access in __memcpy+0x44/0x230<br /> Write at addr f5ffff809e2d33ac by task kworker/u32:5/125<br /> Pointer tag: [f5], memory tag: [fe]<br /> Tainted : [W]=WARN, [O]=OOT_MODULE<br /> Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3<br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> __memcpy+0x44/0x230<br /> cros_ec_check_features+0x60/0xcc [cros_ec_proto]<br /> cros_typec_probe+0xe8/0x6e0 [cros_ec_typec]<br /> platform_probe+0xa0/0xe0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: avoid NULL deref of conn in iso_conn_big_sync()<br /> <br /> iso_conn_big_sync() drops the socket lock to call hci_get_route() and<br /> then re-acquires it, but dereferences iso_pi(sk)-&gt;conn-&gt;hcon afterwards<br /> without re-checking that conn is still valid.<br /> <br /> While the lock is dropped, the connection can be torn down under the<br /> same socket lock: iso_disconn_cfm() -&gt; iso_conn_del() -&gt; iso_chan_del()<br /> sets iso_pi(sk)-&gt;conn to NULL (and the broadcast teardown path can also<br /> clear conn-&gt;hcon on its own). When iso_conn_big_sync() re-acquires the<br /> lock and reads conn-&gt;hcon, conn may be NULL, causing a NULL pointer<br /> dereference (hcon is the first member of struct iso_conn).<br /> <br /> This path is reached from iso_sock_recvmsg() for a PA-sync broadcast<br /> sink socket (BT_SK_DEFER_SETUP | BT_SK_PA_SYNC), so the dropped-lock<br /> window can race with connection teardown driven by controller events.<br /> <br /> Re-validate iso_pi(sk)-&gt;conn and its hcon after re-acquiring the socket<br /> lock and bail out if the connection went away, as already done in the<br /> sibling iso_sock_rebind_bc().