Vulnerabilities

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()<br /> <br /> hci_abort_conn() read hci_skb_event(hdev-&gt;sent_cmd) when a connection<br /> was pending, but hdev-&gt;sent_cmd can be NULL while req_status is still<br /> HCI_REQ_PEND, leading to a NULL pointer dereference and a general<br /> protection fault from the hci_rx_work() receive path.<br /> <br /> Instead of inspecting hdev-&gt;sent_cmd, track the in-flight create<br /> connection command with a new per-connection HCI_CONN_CREATE flag and<br /> route all cancellation through hci_cancel_connect_sync(), which<br /> dispatches to a dedicated per-type cancel function. The create command<br /> is in exactly one of two states: still queued, or in flight. The cancel<br /> function holds cmd_sync_work_lock across the whole decision: the worker<br /> takes this lock to dequeue every entry, so while it is held a queued<br /> command cannot start running and an in-flight command cannot complete<br /> and let the next command become pending. This keeps the flag test and<br /> hci_cmd_sync_cancel() atomic with respect to the worker, so a queued<br /> command is simply dequeued, and an in-flight command owned by this<br /> connection is cancelled without the risk of cancelling an unrelated<br /> command that became pending in the meantime. CIS uses the same flag<br /> mechanism via HCI_CONN_CREATE_CIS but cannot be dequeued per-connection.<br /> <br /> hci_acl_create_conn_sync() and hci_le_create_conn_sync() clear<br /> HCI_CONN_CREATE after the create command completes, but the command<br /> status handler can free conn via hci_conn_del() (for example when the<br /> controller rejects the connection) while the worker is still blocked on<br /> the connection complete event. Hold a reference on conn across the<br /> create command so the flag can be cleared without a use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: fix UAF in bt_accept_dequeue()<br /> <br /> bt_accept_get() takes a temporary reference before dropping the accept<br /> queue lock. bt_accept_dequeue() currently drops that reference before<br /> bt_accept_unlink(), leaving only the queue reference.<br /> <br /> bt_accept_unlink() drops the queue reference. The subsequent<br /> sock_hold() therefore accesses freed memory if it was the final<br /> reference, as observed by KASAN during listening L2CAP socket cleanup.<br /> <br /> Retain the temporary queue-walk reference through unlink and hand it to<br /> the caller on success. Drop it explicitly on the closed and<br /> not-yet-connected paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxp_recv_fw_req_v3()<br /> <br /> During the v3 firmware download the controller sends a v3_data_req with a<br /> 32 bit offset and a 16 bit len. nxp_recv_fw_req_v3() checks only the lower<br /> bound of the offset and then sends firmware from that offset.<br /> <br /> nxpdev-&gt;fw_dnld_v3_offset = offset - nxpdev-&gt;fw_v3_offset_correction;<br /> serdev_device_write_buf(nxpdev-&gt;serdev, nxpdev-&gt;fw-&gt;data +<br /> nxpdev-&gt;fw_dnld_v3_offset, len);<br /> <br /> Nothing checks that fw_dnld_v3_offset + len stays within nxpdev-&gt;fw-&gt;size,<br /> so a controller that asks for an offset or length past the firmware image<br /> makes the driver read past the end of nxpdev-&gt;fw-&gt;data and send that<br /> memory back over UART.<br /> <br /> nxp_recv_fw_req_v1() already bounds the same write. Add the equivalent<br /> check to the v3 path, reject the request when it falls outside the firmware<br /> image, and zero len on the error path so the fw_v3_prev_sent bookkeeping at<br /> free_skb stays consistent.