Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wlcore: Return -ENOMEM instead of -EAGAIN if there is not enough headroom<br /> <br /> Since upstream commit e75665dd0968 ("wifi: wlcore: ensure skb headroom<br /> before skb_push"), wl1271_tx_allocate() and with it<br /> wl1271_prepare_tx_frame() returns -EAGAIN if pskb_expand_head() fails.<br /> However, in wlcore_tx_work_locked(), a return value of -EAGAIN from<br /> wl1271_prepare_tx_frame() is interpreted as the aggregation buffer being<br /> full. This causes the code to flush the buffer, put the skb back at the<br /> head of the queue, and immediately retry the same skb in a tight while<br /> loop.<br /> <br /> Because wlcore_tx_work_locked() holds wl-&gt;mutex, and the retry happens<br /> immediately with GFP_ATOMIC, this will result in an infinite loop and a<br /> CPU soft lockup. Return -ENOMEM instead so the packet is dropped and<br /> the loop terminates.<br /> <br /> The problem was found by an experimental code review agent based on<br /> gemini-3.1-pro while reviewing backports into v6.18.y.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: Fix static_branch_dec() underflow for aql_disable.<br /> <br /> syzbot reported static_branch_dec() underflow in aql_enable_write(). [0]<br /> <br /> The problem is that aql_enable_write() does not serialise concurrent<br /> write()s to the debugfs.<br /> <br /> aql_enable_write() checks static_key_false(&amp;aql_disable.key) and<br /> later calls static_branch_inc() or static_branch_dec(), but the<br /> state may change between the two calls.<br /> <br /> aql_disable does not need to track inc/dec.<br /> <br /> Let&amp;#39;s use static_branch_enable() and static_branch_disable().<br /> <br /> [0]:<br /> val == 0<br /> WARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G U L syzkaller #0 PREEMPT(full)<br /> Tainted: [U]=USER, [L]=SOFTLOCKUP<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026<br /> RIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311<br /> Code: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00<br /> RSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4<br /> RDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000<br /> RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a<br /> R13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98<br /> FS: 00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline]<br /> __static_key_slow_dec kernel/jump_label.c:321 [inline]<br /> static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336<br /> aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343<br /> short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383<br /> vfs_write+0x2aa/0x1070 fs/read_write.c:684<br /> ksys_pwrite64 fs/read_write.c:793 [inline]<br /> __do_sys_pwrite64 fs/read_write.c:801 [inline]<br /> __se_sys_pwrite64 fs/read_write.c:798 [inline]<br /> __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f530cf9aeb9<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012<br /> RAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9<br /> RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010<br /> RBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000<br /> R10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: bcm: bcm2835-power: Increase ASB control timeout<br /> <br /> The bcm2835_asb_control() function uses a tight polling loop to wait<br /> for the ASB bridge to acknowledge a request. During intensive workloads,<br /> this handshake intermittently fails for V3D&amp;#39;s master ASB on BCM2711,<br /> resulting in "Failed to disable ASB master for v3d" errors during<br /> runtime PM suspend. As a consequence, the failed power-off leaves V3D in<br /> a broken state, leading to bus faults or system hangs on later accesses.<br /> <br /> As the timeout is insufficient in some scenarios, increase the polling<br /> timeout from 1us to 5us, which is still negligible in the context of a<br /> power domain transition. Also, replace the open-coded ktime_get_ns()/<br /> cpu_relax() polling loop with readl_poll_timeout_atomic().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: cp2615: fix serial string NULL-deref at probe<br /> <br /> The cp2615 driver uses the USB device serial string as the i2c adapter<br /> name but does not make sure that the string exists.<br /> <br /> Verify that the device has a serial number before accessing it to avoid<br /> triggering a NULL-pointer dereference (e.g. with malicious devices).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: cancel pmsr_free_wk in cfg80211_pmsr_wdev_down<br /> <br /> When the nl80211 socket that originated a PMSR request is<br /> closed, cfg80211_release_pmsr() sets the request&amp;#39;s nl_portid<br /> to zero and schedules pmsr_free_wk to process the abort<br /> asynchronously. If the interface is concurrently torn down<br /> before that work runs, cfg80211_pmsr_wdev_down() calls<br /> cfg80211_pmsr_process_abort() directly. However, the already-<br /> scheduled pmsr_free_wk work item remains pending and may run<br /> after the interface has been removed from the driver. This<br /> could cause the driver&amp;#39;s abort_pmsr callback to operate on a<br /> torn-down interface, leading to undefined behavior and<br /> potential crashes.<br /> <br /> Cancel pmsr_free_wk synchronously in cfg80211_pmsr_wdev_down()<br /> before calling cfg80211_pmsr_process_abort(). This ensures any<br /> pending or in-progress work is drained before interface teardown<br /> proceeds, preventing the work from invoking the driver abort<br /> callback after the interface is gone.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix missing runtime PM reference in ccs_mode_store<br /> <br /> ccs_mode_store() calls xe_gt_reset() which internally invokes<br /> xe_pm_runtime_get_noresume(). That function requires the caller<br /> to already hold an outer runtime PM reference and warns if none<br /> is held:<br /> <br /> [46.891177] xe 0000:03:00.0: [drm] Missing outer runtime PM protection<br /> [46.891178] WARNING: drivers/gpu/drm/xe/xe_pm.c:885 at<br /> xe_pm_runtime_get_noresume+0x8b/0xc0<br /> <br /> Fix this by protecting xe_gt_reset() with the scope-based<br /> guard(xe_pm_runtime)(xe), which is the preferred form when<br /> the reference lifetime matches a single scope.<br /> <br /> v2:<br /> - Use scope-based guard(xe_pm_runtime)(xe) (Shuicheng)<br /> - Update commit message accordingly<br /> <br /> (cherry picked from commit 7937ea733f79b3f25e802a0c8360bf7423856f36)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Fix NULL dereference on notify error path<br /> <br /> Since commit b5daf93b809d1 ("firmware: arm_scmi: Avoid notifier<br /> registration for unsupported events") the call chains leading to the helper<br /> __scmi_event_handler_get_ops expect an ERR_PTR to be returned on failure to<br /> get an handler for the requested event key, while the current helper can<br /> still return a NULL when no handler could be found or created.<br /> <br /> Fix by forcing an ERR_PTR return value when the handler reference is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crash_dump: don&amp;#39;t log dm-crypt key bytes in read_key_from_user_keying<br /> <br /> When debug logging is enabled, read_key_from_user_keying() logs the first<br /> 8 bytes of the key payload and partially exposes the dm-crypt key. Stop<br /> logging any key bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/platform/uv: Handle deconfigured sockets<br /> <br /> When a socket is deconfigured, it&amp;#39;s mapped to SOCK_EMPTY (0xffff). This causes<br /> a panic while allocating UV hub info structures.<br /> <br /> Fix this by using NUMA_NO_NODE, allowing UV hub info structures to be<br /> allocated on valid nodes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix trace_marker copy link list updates<br /> <br /> When the "copy_trace_marker" option is enabled for an instance, anything<br /> written into /sys/kernel/tracing/trace_marker is also copied into that<br /> instances buffer. When the option is set, that instance&amp;#39;s trace_array<br /> descriptor is added to the marker_copies link list. This list is protected<br /> by RCU, as all iterations uses an RCU protected list traversal.<br /> <br /> When the instance is deleted, all the flags that were enabled are cleared.<br /> This also clears the copy_trace_marker flag and removes the trace_array<br /> descriptor from the list.<br /> <br /> The issue is after the flags are called, a direct call to<br /> update_marker_trace() is performed to clear the flag. This function<br /> returns true if the state of the flag changed and false otherwise. If it<br /> returns true here, synchronize_rcu() is called to make sure all readers<br /> see that its removed from the list.<br /> <br /> But since the flag was already cleared, the state does not change and the<br /> synchronization is never called, leaving a possible UAF bug.<br /> <br /> Move the clearing of all flags below the updating of the copy_trace_marker<br /> option which then makes sure the synchronization is performed.<br /> <br /> Also use the flag for checking the state in update_marker_trace() instead<br /> of looking at if the list is empty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bonding: fix NULL deref in bond_debug_rlb_hash_show<br /> <br /> rlb_clear_slave intentionally keeps RLB hash-table entries on<br /> the rx_hashtbl_used_head list with slave set to NULL when no<br /> replacement slave is available. However, bond_debug_rlb_hash_show<br /> visites client_info-&gt;slave without checking if it&amp;#39;s NULL.<br /> <br /> Other used-list iterators in bond_alb.c already handle this NULL-slave<br /> state safely:<br /> <br /> - rlb_update_client returns early on !client_info-&gt;slave<br /> - rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance<br /> compare slave values before visiting<br /> - lb_req_update_subnet_clients continues if slave is NULL<br /> <br /> The following NULL deref crash can be trigger in<br /> bond_debug_rlb_hash_show:<br /> <br /> [ 1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41)<br /> [ 1.293101] RSP: 0018:ffffc900004a7d00 EFLAGS: 00010286<br /> [ 1.293333] RAX: 0000000000000000 RBX: ffff888102b48200 RCX: ffff888102b48204<br /> [ 1.293631] RDX: ffff888102b48200 RSI: ffffffff839daad5 RDI: ffff888102815078<br /> [ 1.293924] RBP: ffff888102815078 R08: ffff888102b4820e R09: 0000000000000000<br /> [ 1.294267] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100f929c0<br /> [ 1.294564] R13: ffff888100f92a00 R14: 0000000000000001 R15: ffffc900004a7ed8<br /> [ 1.294864] FS: 0000000001395380(0000) GS:ffff888196e75000(0000) knlGS:0000000000000000<br /> [ 1.295239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1.295480] CR2: 0000000000000000 CR3: 0000000102adc004 CR4: 0000000000772ef0<br /> [ 1.295897] Call Trace:<br /> [ 1.296134] seq_read_iter (fs/seq_file.c:231)<br /> [ 1.296341] seq_read (fs/seq_file.c:164)<br /> [ 1.296493] full_proxy_read (fs/debugfs/file.c:378 (discriminator 1))<br /> [ 1.296658] vfs_read (fs/read_write.c:572)<br /> [ 1.296981] ksys_read (fs/read_write.c:717)<br /> [ 1.297132] do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> [ 1.297325] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> <br /> Add a NULL check and print "(none)" for entries with no assigned slave.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: nxp-nci: allow GPIOs to sleep<br /> <br /> Allow the firmware and enable GPIOs to sleep.<br /> <br /> This fixes a `WARN_ON&amp;#39; and allows the driver to operate GPIOs which are<br /> connected to I2C GPIO expanders.<br /> <br /> -- &gt;8 --<br /> kernel: WARNING: CPU: 3 PID: 2636 at drivers/gpio/gpiolib.c:3880 gpiod_set_value+0x88/0x98<br /> -- &gt;8 --