Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: prevent NULL vif dereference in mt7925_mac_write_txwi<br /> <br /> Check for a NULL `vif` before accessing `ieee80211_vif_is_mld(vif)` to<br /> avoid a potential kernel panic in scenarios where `vif` might not be<br /> initialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: Fix memory leak destroying device<br /> <br /> All MT76 rx queues have an associated page_pool even if the queue is not<br /> associated to a NAPI (e.g. WED RRO queues with WED enabled). Destroy the<br /> page_pool running mt76_dma_cleanup routine during module unload.<br /> Moreover returns pages to the page pool if WED is not enabled for WED RRO<br /> queues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Do not allow deleting local storage in NMI<br /> <br /> Currently, local storage may deadlock when deferring freeing selem or<br /> local storage through kfree_rcu(), call_rcu() or call_rcu_tasks_trace()<br /> in NMI or reentrant. Since deleting selem in NMI is an unlikely use<br /> case, partially mitigate it by returning error when calling from<br /> bpf_xxx_storage_delete() helpers in NMI. Note that, it is still possible<br /> to deadlock through reentrant. A full mitigation requires returning<br /> error when irqs_disabled() is true, which, however is too heavy-handed<br /> for bpf_xxx_storage_delete().<br /> <br /> The long-term solution requires _nolock versions of call_rcu. Another<br /> possible solution is to defer the free through irq_work [0], but it<br /> would grow the size of selem, which is non-ideal.<br /> <br /> The check is only needed in bpf_selem_unlink(), which is used by helpers<br /> and syscalls. bpf_selem_unlink_nofail() is fine as it is called during<br /> map and owner tear down that never run in NMI or reentrant.<br /> <br /> [0] https://lore.kernel.org/bpf/20260205190233.912-1-alexei.starovoitov@gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: libertas: don&amp;#39;t kill URBs in interrupt context<br /> <br /> Serialization for the TX path was enforced by calling<br /> usb_kill_urb()/usb_kill_anchored_urbs(), to prevent transmission before<br /> a previous URB was completed. usb_tx_block() can be called from<br /> interrupt context (e.g. in the HCD giveback path), so we can&amp;#39;t always<br /> use it to kill in-flight URBs.<br /> <br /> Prevent sleeping during interrupt context by checking the tx_submitted<br /> anchor for existing URBs. We now return -EBUSY, to indicate there&amp;#39;s<br /> a pending request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work()<br /> <br /> When the mt7996 pci chip is detaching, the mt7996_crash_data is<br /> released in mt7996_coredump_unregister(). However, the work item<br /> dump_work may still be running or pending, leading to UAF bugs<br /> when the already freed crash_data is dereferenced again in<br /> mt7996_mac_dump_work().<br /> <br /> The race condition can occur as follows:<br /> <br /> CPU 0 (removal path) | CPU 1 (workqueue)<br /> mt7996_pci_remove() | mt7996_sys_recovery_set()<br /> mt7996_unregister_device() | mt7996_reset()<br /> mt7996_coredump_unregister() | queue_work()<br /> vfree(dev-&gt;coredump.crash_data) | mt7996_mac_dump_work()<br /> | crash_data-&gt; // UAF<br /> <br /> Fix this by ensuring dump_work is properly canceled before<br /> the crash_data is deallocated. Add cancel_work_sync() in<br /> mt7996_unregister_device() to synchronize with any pending<br /> or executing dump work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Use RCU-safe iteration in dev_map_redirect_multi() SKB path<br /> <br /> The DEVMAP_HASH branch in dev_map_redirect_multi() uses<br /> hlist_for_each_entry_safe() to iterate hash buckets, but this function<br /> runs under RCU protection (called from xdp_do_generic_redirect_map()<br /> in softirq context). Concurrent writers (__dev_map_hash_update_elem,<br /> dev_map_hash_delete_elem) modify the list using RCU primitives<br /> (hlist_add_head_rcu, hlist_del_rcu).<br /> <br /> hlist_for_each_entry_safe() performs plain pointer dereferences without<br /> rcu_dereference(), missing the acquire barrier needed to pair with<br /> writers&amp;#39; rcu_assign_pointer(). On weakly-ordered architectures (ARM64,<br /> POWER), a reader can observe a partially-constructed node. It also<br /> defeats CONFIG_PROVE_RCU lockdep validation and KCSAN data-race<br /> detection.<br /> <br /> Replace with hlist_for_each_entry_rcu() using rcu_read_lock_bh_held()<br /> as the lockdep condition, consistent with the rcu_dereference_check()<br /> used in the DEVMAP (non-hash) branch of the same functions. Also fix<br /> the same incorrect lockdep_is_held(&amp;dtab-&gt;index_lock) condition in<br /> dev_map_enqueue_multi(), where the lock is not held either.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix abuse of kprobe_write_ctx via freplace<br /> <br /> uprobe programs are allowed to modify struct pt_regs.<br /> <br /> Since the actual program type of uprobe is KPROBE, it can be abused to<br /> modify struct pt_regs via kprobe+freplace when the kprobe attaches to<br /> kernel functions.<br /> <br /> For example,<br /> <br /> SEC("?kprobe")<br /> int kprobe(struct pt_regs *regs)<br /> {<br /> return 0;<br /> }<br /> <br /> SEC("?freplace")<br /> int freplace_kprobe(struct pt_regs *regs)<br /> {<br /> regs-&gt;di = 0;<br /> return 0;<br /> }<br /> <br /> freplace_kprobe prog will attach to kprobe prog.<br /> kprobe prog will attach to a kernel function.<br /> <br /> Without this patch, when the kernel function runs, its first arg will<br /> always be set as 0 via the freplace_kprobe prog.<br /> <br /> To fix the abuse of kprobe_write_ctx=true via kprobe+freplace, disallow<br /> attaching freplace programs on kprobe programs with different<br /> kprobe_write_ctx values.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix stale offload-&gt;prog pointer after constant blinding<br /> <br /> When a dev-bound-only BPF program (BPF_F_XDP_DEV_BOUND_ONLY) undergoes<br /> JIT compilation with constant blinding enabled (bpf_jit_harden &gt;= 2),<br /> bpf_jit_blind_constants() clones the program. The original prog is then<br /> freed in bpf_jit_prog_release_other(), which updates aux-&gt;prog to point<br /> to the surviving clone, but fails to update offload-&gt;prog.<br /> <br /> This leaves offload-&gt;prog pointing to the freed original program. When<br /> the network namespace is subsequently destroyed, cleanup_net() triggers<br /> bpf_dev_bound_netdev_unregister(), which iterates ondev-&gt;progs and calls<br /> __bpf_prog_offload_destroy(offload-&gt;prog). Accessing the freed prog<br /> causes a page fault:<br /> <br /> BUG: unable to handle page fault for address: ffffc900085f1038<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:__bpf_prog_offload_destroy+0xc/0x80<br /> Call Trace:<br /> __bpf_offload_dev_netdev_unregister+0x257/0x350<br /> bpf_dev_bound_netdev_unregister+0x4a/0x90<br /> unregister_netdevice_many_notify+0x2a2/0x660<br /> ...<br /> cleanup_net+0x21a/0x320<br /> <br /> The test sequence that triggers this reliably is:<br /> <br /> 1. Set net.core.bpf_jit_harden=2 (echo 2 &gt; /proc/sys/net/core/bpf_jit_harden)<br /> 2. Run xdp_metadata selftest, which creates a dev-bound-only XDP<br /> program on a veth inside a netns (./test_progs -t xdp_metadata)<br /> 3. cleanup_net -&gt; page fault in __bpf_prog_offload_destroy<br /> <br /> Dev-bound-only programs are unique in that they have an offload structure<br /> but go through the normal JIT path instead of bpf_prog_offload_compile().<br /> This means they are subject to constant blinding&amp;#39;s prog clone-and-replace,<br /> while also having offload-&gt;prog that must stay in sync.<br /> <br /> Fix this by updating offload-&gt;prog in bpf_jit_prog_release_other(),<br /> alongside the existing aux-&gt;prog update. Both are back-pointers to<br /> the prog that must be kept in sync when the prog is replaced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Fix error pointer dereference<br /> <br /> The function brcmf_chip_add_core() can return an error pointer and is<br /> not checked. Add checks for error pointer.<br /> <br /> Detected by Smatch:<br /> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1010 brcmf_chip_recognition() error:<br /> &amp;#39;core&amp;#39; dereferencing possible ERR_PTR()<br /> <br /> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1013 brcmf_chip_recognition() error:<br /> &amp;#39;core&amp;#39; dereferencing possible ERR_PTR()<br /> <br /> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1016 brcmf_chip_recognition() error:<br /> &amp;#39;core&amp;#39; dereferencing possible ERR_PTR()<br /> <br /> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1019 brcmf_chip_recognition() error:<br /> &amp;#39;core&amp;#39; dereferencing possible ERR_PTR()<br /> <br /> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1022 brcmf_chip_recognition() error:<br /> &amp;#39;core&amp;#39; dereferencing possible ERR_PTR()<br /> <br /> [add missing wifi: prefix]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix linked reg delta tracking when src_reg == dst_reg<br /> <br /> Consider the case of rX += rX where src_reg and dst_reg are pointers to<br /> the same bpf_reg_state in adjust_reg_min_max_vals(). The latter first<br /> modifies the dst_reg in-place, and later in the delta tracking, the<br /> subsequent is_reg_const(src_reg)/reg_const_value(src_reg) reads the<br /> post-{add,sub} value instead of the original source.<br /> <br /> This is problematic since it sets an incorrect delta, which sync_linked_regs()<br /> then propagates to linked registers, thus creating a verifier-vs-runtime<br /> mismatch. Fix it by just skipping this corner case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: pull headers in qdisc_pkt_len_segs_init()<br /> <br /> Most ndo_start_xmit() methods expects headers of gso packets<br /> to be already in skb-&gt;head.<br /> <br /> net/core/tso.c users are particularly at risk, because tso_build_hdr()<br /> does a memcpy(hdr, skb-&gt;data, hdr_len);<br /> <br /> qdisc_pkt_len_segs_init() already does a dissection of gso packets.<br /> <br /> Use pskb_may_pull() instead of skb_header_pointer() to make<br /> sure drivers do not have to reimplement this.<br /> <br /> Some malicious packets could be fed, detect them so that we can<br /> drop them sooner with a new SKB_DROP_REASON_SKB_BAD_GSO drop_reason.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix ld_{abs,ind} failure path analysis in subprogs<br /> <br /> Usage of ld_{abs,ind} instructions got extended into subprogs some time<br /> ago via commit 09b28d76eac4 ("bpf: Add abnormal return checks."). These<br /> are only allowed in subprograms when the latter are BTF annotated and<br /> have scalar return types.<br /> <br /> The code generator in bpf_gen_ld_abs() has an abnormal exit path (r0=0 +<br /> exit) from legacy cBPF times. While the enforcement is on scalar return<br /> types, the verifier must also simulate the path of abnormal exit if the<br /> packet data load via ld_{abs,ind} failed.<br /> <br /> This is currently not the case. Fix it by having the verifier simulate<br /> both success and failure paths, and extend it in similar ways as we do<br /> for tail calls. The success path (r0=unknown, continue to next insn) is<br /> pushed onto stack for later validation and the r0=0 and return to the<br /> caller is done on the fall-through side.