Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix use-after-free in offloaded map/prog info fill<br /> <br /> When querying info for an offloaded BPF map or program,<br /> bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns()<br /> obtain the network namespace with get_net(dev_net(offmap-&gt;netdev)).<br /> However, the associated netdev&amp;#39;s netns may be racing with teardown<br /> during netns destruction. If the netns refcount has already reached 0,<br /> get_net() performs a refcount_t increment on 0, triggering:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> <br /> Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains<br /> valid, they cannot prevent the netns refcount from reaching zero.<br /> <br /> Fix this by using maybe_get_net() instead of get_net(). maybe_get_net()<br /> uses refcount_inc_not_zero() and returns NULL if the refcount is already<br /> zero, which causes ns_get_path_cb() to fail and the caller to return<br /> -ENOENT -- the correct behavior when the netns is being destroyed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmgenet: fix off-by-one in bcmgenet_put_txcb<br /> <br /> The write_ptr points to the next open tx_cb. We want to return the<br /> tx_cb that gets rewinded, so we must rewind the pointer first then<br /> return the tx_cb that it points to. That way the txcb can be correctly<br /> cleaned up.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmgenet: fix leaking free_bds<br /> <br /> While reclaiming the tx queue we fast forward the write pointer to<br /> drop any data in flight. These dropped frames are not added back<br /> to the pool of free bds. We also need to tell the netdev that we<br /> are dropping said data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmgenet: fix racing timeout handler<br /> <br /> The bcmgenet_timeout handler tries to take down all tx queues when<br /> a single queue times out. This is over zealous and causes many race<br /> conditions with queues that are still chugging along. Instead lets<br /> only restart the timed out queue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix mm lifecycle in open-coded task_vma iterator<br /> <br /> The open-coded task_vma iterator reads task-&gt;mm locklessly and acquires<br /> mmap_read_trylock() but never calls mmget(). If the task exits<br /> concurrently, the mm_struct can be freed as it is not<br /> SLAB_TYPESAFE_BY_RCU, resulting in a use-after-free.<br /> <br /> Safely read task-&gt;mm with a trylock on alloc_lock and acquire an mm<br /> reference. Drop the reference via bpf_iter_mmput_async() in _destroy()<br /> and error paths. bpf_iter_mmput_async() is a local wrapper around<br /> mmput_async() with a fallback to mmput() on !CONFIG_MMU.<br /> <br /> Reject irqs-disabled contexts (including NMI) up front. Operations used<br /> by _next() and _destroy() (mmap_read_unlock, bpf_iter_mmput_async)<br /> take spinlocks with IRQs disabled (pool-&gt;lock, pi_lock). Running from<br /> NMI or from a tracepoint that fires with those locks held could<br /> deadlock.<br /> <br /> A trylock on alloc_lock is used instead of the blocking task_lock()<br /> (get_task_mm) to avoid a deadlock when a softirq BPF program iterates<br /> a task that already holds its alloc_lock on the same CPU.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: return VMA snapshot from task_vma iterator<br /> <br /> Holding the per-VMA lock across the BPF program body creates a lock<br /> ordering problem when helpers acquire locks that depend on mmap_lock:<br /> <br /> vm_lock -&gt; i_rwsem -&gt; mmap_lock -&gt; vm_lock<br /> <br /> Snapshot the VMA under the per-VMA lock in _next() via memcpy(), then<br /> drop the lock before returning. The BPF program accesses only the<br /> snapshot.<br /> <br /> The verifier only trusts vm_mm and vm_file pointers (see<br /> BTF_TYPE_SAFE_TRUSTED_OR_NULL in verifier.c). vm_file is reference-<br /> counted with get_file() under the lock and released via fput() on the<br /> next iteration or in _destroy(). vm_mm is already correct because<br /> lock_vma_under_rcu() verifies vma-&gt;vm_mm == mm. All other pointers<br /> are left as-is by memcpy() since the verifier treats them as untrusted.