Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: skip rehash for peers already removed from by_id<br /> <br /> ovpn_nl_peer_set_doit() resolves the target peer via<br /> ovpn_peer_get_by_id() before taking ovpn-&gt;lock. In the window between<br /> the lookup (which only takes a refcount) and the subsequent<br /> spin_lock_bh(&amp;ovpn-&gt;lock), a concurrent OVPN_CMD_PEER_DEL, keepalive<br /> expiry, or socket teardown can take ovpn-&gt;lock first, run<br /> ovpn_peer_remove() to unhash the peer from all four tables (by_id,<br /> by_vpn_addr4/6, by_transp_addr) and release the lock. set_doit then<br /> acquires ovpn-&gt;lock and calls ovpn_peer_hash_vpn_ip(), which<br /> re-inserts the now-removed peer back into the rehashing tables.<br /> <br /> The same race affects the float path: ovpn_peer_endpoints_update()<br /> holds only a refcount and acquires ovpn-&gt;lock very late (after async<br /> AEAD decrypt and a netlink notification), then rehashes the peer<br /> in the by_transp_addr table.<br /> <br /> The resurrected peer becomes reachable again from the RX lookup<br /> (ovpn_peer_get_by_transp_addr) and the TX VPN-IP lookup, even though<br /> userspace believes it is gone. Once the data-path refcount drops the<br /> peer is freed via call_rcu while the hash entries embedded in it<br /> remain linked, opening a UAF window.<br /> <br /> Bail out of the rehash when hash_entry_id is unhashed, mirroring<br /> the sentinel already used by ovpn_peer_remove() to detect the<br /> already-removed state. The check is safe under ovpn-&gt;lock, which<br /> serializes every mutation of hash_entry_id, and is a no-op for the<br /> add path because ovpn_peer_add_mp() inserts hash_entry_id before<br /> calling ovpn_peer_hash_vpn_ip().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: handle NULL b_addr in xfs_buf_free<br /> <br /> When xfs_buf_alloc_backing_mem() fails, xfs_buf_free() is called with<br /> bp-&gt;b_addr still NULL. The code falls through to the folio_put path<br /> which calls virt_to_folio(NULL), dereferencing an invalid address and<br /> causing a kernel crash.<br /> <br /> Call Trace:<br /> xfs_buf_free+0x25f/0x510<br /> xfs_buf_alloc+0xc98/0x19b0<br /> xfs_buf_find_insert+0x55/0x14d0<br /> xfs_buf_get_map+0x122b/0x17c0<br /> xfbtree_init_leaf_block+0x11c/0x4a0<br /> xfbtree_init+0x1bb/0x460<br /> xrep_rmap_setup_scan+0x100/0x1f0<br /> xrep_rmapbt+0x41/0xc0<br /> <br /> Fix this by skipping folio_put() when bp-&gt;b_addr is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost_iotlb: bound map allocation in add_range<br /> <br /> vhost_iotlb_add_range_ctx() only retires an old entry when the table<br /> has a non-zero limit, has exactly reached that limit and has<br /> VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating<br /> entries after reaching their configured limit.<br /> <br /> Existing vhost devices allocate their IOTLB with max_iotlb_entries from<br /> vhost.c, which defaults to 2048 and is tunable by module parameter. Use<br /> the caller-provided limit at the allocation point instead of adding a<br /> separate default in the common IOTLB helper, and reject non-positive<br /> values in vhost paths that can report an error.<br /> <br /> Other vhost IOTLB users should not create zero-limit tables when entries<br /> can be populated from userspace or guest-controlled requests. Add<br /> caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and<br /> vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require<br /> at least two entries for vdpa_sim and mlx5 vDPA paths that install<br /> full-range mappings, since those mappings are split into two IOTLB<br /> entries.<br /> <br /> Handle full-range mappings in the common helper by checking that the<br /> IOTLB can hold both split entries before inserting the first half. This<br /> avoids returning an error after leaving a half mapping behind.<br /> <br /> When the table is full, keep the existing retire behavior for retiring<br /> tables and return -ENOSPC for non-retiring tables. Reuse the retired map<br /> node instead of freeing it and allocating a replacement, so a stream of<br /> IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table<br /> has reached its limit. If a zero-limit IOTLB still reaches the common<br /> helper, treat it as a configuration error and return -EINVAL.<br /> <br /> I found this bug myself, though the patch was written with AI assistance.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: tcp: Fix use-after-free in bpf_iter_tcp_established_batch()<br /> <br /> reqsk_queue_hash_req() publishes a TCP_NEW_SYN_RECV request_sock onto<br /> the ehash chain, drops the bucket lock, and only afterwards sets<br /> rsk_refcnt to 3.<br /> <br /> Lockless readers such as __inet_lookup_established() handle this with<br /> refcount_inc_not_zero(), but bpf_iter_tcp_established_batch() uses plain<br /> sock_hold() while holding the bucket lock, on the assumption that the<br /> lock guarantees sk_refcnt &gt; 0. That assumption does not hold for<br /> request_sock:<br /> <br /> CPU 0 CPU 1<br /> ----- -----<br /> tcp_conn_request()<br /> reqsk_queue_hash_req()<br /> inet_ehash_insert(req)<br /> spin_lock(bucket)<br /> __sk_nulls_add_node_rcu(req) // rsk_refcnt == 0<br /> spin_unlock(bucket)<br /> bpf_iter_tcp_established_batch()<br /> spin_lock(bucket)<br /> sock_hold(req) rsk_refcnt, 3) // clobbers saturated value<br /> <br /> which surfaces as:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: lib/refcount.c:25 at refcount_warn_saturate+0x48/0x90, CPU#1<br /> Call Trace:<br /> bpf_iter_tcp_established_batch+0x14e/0x170<br /> bpf_iter_tcp_batch+0x53/0x200<br /> bpf_iter_tcp_seq_next+0x27/0x70<br /> bpf_seq_read+0x107/0x410<br /> vfs_read+0xb9/0x380<br /> <br /> The iterator&amp;#39;s stolen reference is lost when the publishing CPU&amp;#39;s<br /> refcount_set() overwrites the count, leaving the socket one reference<br /> short. When the last legitimate owner drops its reference the reqsk is<br /> freed while still reachable, leading to use-after-free.<br /> <br /> This reproduces in seconds with tcp_syncookies=0, a handful of threads<br /> doing connect()/close() to a local listener while others read an<br /> iter/tcp link in a tight loop.<br /> <br /> Use refcount_inc_not_zero() and skip the socket on failure. A skipped<br /> socket is still part of the bucket, so keep counting it in expected.<br /> The reallocations are sized from expected, and a request sock whose<br /> refcount gets published while the lock is held across the last realloc<br /> must already have room.<br /> <br /> A skipped socket is counted in expected but never batched, so end_sk<br /> can be short of expected on a batch that is actually complete. Decide<br /> completeness by whether the walk left any socket behind instead. The<br /> WARN after the locked realloc checks the same, replacing an<br /> end_sk == expected check that could not hold on that path since<br /> commit cdec67a489d4 ("bpf: tcp: Make sure iter-&gt;batch always<br /> contains a full bucket snapshot").<br /> <br /> If every matching socket in a bucket is mid-init (refcount 0), end_sk<br /> stays 0. Advance to the next bucket rather than returning a batch entry<br /> that was never filled this round.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix netns reference imbalance in conntrack kfuncs<br /> <br /> The opts argument of the BPF conntrack kfuncs can point to a shared<br /> map value. __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read<br /> opts-&gt;netns_id separately when acquiring and releasing the network<br /> namespace reference.<br /> <br /> The reference imbalance can occur as follows:<br /> <br /> CPU 0 CPU 1<br /> read opts-&gt;netns_id (-1)<br /> skip get_net_ns_by_id()<br /> write opts-&gt;netns_id (id)<br /> read opts-&gt;netns_id (id)<br /> put_net(net) /* no matching get */<br /> <br /> The reverse transition leaks the reference. Repeating the unmatched put<br /> can destroy a live namespace and crash later users.<br /> <br /> The kernel reported:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]<br /> RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700<br /> Call Trace:<br /> __sys_bpf+0x1662/0x50c0<br /> __x64_sys_bpf+0x73/0xb0<br /> do_syscall_64+0xf9/0x540<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> Snapshot every input field of opts with READ_ONCE() before validating or<br /> using it. The netns_id snapshot keeps the namespace get/put pair<br /> balanced, while the other snapshots keep the remaining options from<br /> changing partway through an invocation. The individual reads can still<br /> observe an inconsistent combination during a concurrent update, but each<br /> selected field value remains stable for that invocation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Fix locally exploitable BUG_ON in amdxdna_insert_pages()<br /> <br /> In amdxdna_insert_pages(), vm_flags_mod() sets VM_MIXEDMAP and clears<br /> VM_PFNMAP. If an unprivileged userspace process mmaps a non-imported GEM<br /> object and then calls madvise(MADV_DONTNEED), the PTEs will be<br /> successfully cleared because VM_MIXEDMAP allows this (unlike VM_PFNMAP).<br /> <br /> When userspace subsequently accesses the memory, drm_gem_shmem_fault()<br /> handles the page fault and attempts to map the backing shmem page via<br /> vmf_insert_pfn() which calls vmf_insert_pfn_prot(). Because the backing<br /> shmem page is normal system memory (pfn_valid(pfn) is true) and the VMA<br /> now has VM_MIXEDMAP set, won&amp;#39;t this predictably trigger the explicit<br /> assertion BUG_ON((vma-&gt;vm_flags &amp; VM_MIXEDMAP) &amp;&amp; pfn_valid(pfn))<br /> <br /> Fix by removing the vm_flags_mod() call and replacing the vm_insert_pages()<br /> pre-population with the handle_mm_fault() loop that was already used for<br /> the import (dma-buf) path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: fw_tracer, return NULL on create error<br /> <br /> Tracer creation can fail by returning either NULL or ERR_PTR.<br /> The return value is stored without a check on the device, and users<br /> treat ERR_PTR and NULL the same way.<br /> This also causes a crash in the core dump logic, which is missing the<br /> ERR_PTR check and ends up dereferencing it, as shown in the trace below.<br /> <br /> Switch tracer creation to return NULL on failure only, so callers only<br /> need a single NULL check.<br /> <br /> Internal error: Oops: 0000000096000006 [#1] SMP<br /> Modules linked in: mlx5_ib ib_uverbs ib_core ipv6 mlx5_core<br /> CPU: 1 UID: 0 PID: 12 Comm: kworker/u16:0 Not tainted 6.19.7 #1 PREEMPT(none)<br /> Workqueue: mlx5_health0001:01:00.0 mlx5_fw_reporter_err_work [mlx5_core]<br /> pstate: a3400009 (NzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core]<br /> lr : mlx5_fw_tracer_trigger_core_dump_general+0x40/0xe0 [mlx5_core]<br /> sp : ffff800081cf3c40<br /> x29: ffff800081cf3c90 x28: 0000000000000000 x27: 0000000000000000<br /> x26: ffff000080018828 x25: 0000000000000000 x24: ffff000080304a05<br /> x23: ffff800081cf3d80 x22: ffff0000847e01a0 x21: 0000000000000000<br /> x20: ffff0000847e01a0 x19: ffffffffffffffa1 x18: ffff80008310bbf0<br /> x17: ffff800080119650 x16: ffff80008010df54 x15: ffff80008010d4ac<br /> x14: ffff800079c202e4 x13: ffff80008002fe60 x12: ffff800080119650<br /> x11: ffff80008010df54 x10: ffff80008010d4ac x9 : ffff800079c203d8<br /> x8 : ffff800081cf3c88 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000030<br /> x2 : 0000000000000008 x1 : 0000000000000000 x0 : 00000000c5c4000e<br /> Call trace:<br /> mlx5_fw_tracer_trigger_core_dump_general+0x58/0xe0 [mlx5_core] (P)<br /> mlx5_fw_reporter_dump+0x30/0x2e0 [mlx5_core]<br /> devlink_health_do_dump+0x9c/0x160<br /> devlink_health_report+0x1c0/0x288<br /> mlx5_fw_reporter_err_work+0xac/0xc0 [mlx5_core]<br /> process_one_work+0x15c/0x3d8<br /> worker_thread+0x18c/0x320<br /> kthread+0x148/0x228<br /> ret_from_fork+0x10/0x20<br /> Code: b9400000 5ac00800 7a401800 540003ca (3940a260)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception<br /> SMP: stopping secondary CPUs<br /> Kernel Offset: disabled<br /> CPU features: 0x000000,00078031,75fce5a1,35fffe67<br /> Memory Limit: none<br /> ---[ end Kernel panic - not syncing: Oops: Fatal exception ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: fix net namespace reference leak in reload<br /> <br /> devlink_nl_reload_doit() calls devlink_netns_get(), which returns a net<br /> with a held reference. When the requested namespace differs from the<br /> current one and the reload action is not DRIVER_REINIT, the function<br /> returns -EOPNOTSUPP without releasing the reference. Add the missing<br /> put_net() on this error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix qentry overwrite for CONFIRM_LINK and ADD_LINK_CONT in smc_llc_event_handler()<br /> <br /> The SMC_LLC_CONFIRM_LINK / SMC_LLC_ADD_LINK_CONT branch in<br /> smc_llc_event_handler() stores an incoming qentry into the local LLC flow<br /> without first checking whether a qentry is already pending. If a malicious or<br /> buggy peer sends a second CONFIRM_LINK or ADD_LINK_CONT request while a flow is<br /> active and flow-&gt;qentry is already set, smc_llc_flow_qentry_set() overwrites the<br /> pointer without freeing the previous allocation, leaking one kmalloc-96 object<br /> per spurious message.<br /> <br /> The sibling SMC_LLC_DELETE_LINK branch already has the correct !flow-&gt;qentry<br /> guard. Apply the same guard to the CONFIRM_LINK/ADD_LINK_CONT branch so that a<br /> duplicate message when qentry is already occupied falls through to break and is<br /> freed by the kfree(qentry) at the out: label, rather than silently leaking the<br /> existing allocation.<br /> <br /> The response direction (smc_llc_rx_response()) is unaffected: it already guards<br /> with flow-&gt;qentry at the equivalent site and drops duplicate responses<br /> correctly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Preserve pointer state for commuted arithmetic<br /> <br /> When scalar += pointer is handled in adjust_ptr_min_max_vals(), the<br /> destination register inherits the pointer state from the source pointer.<br /> Copying only selected fields is fragile because pointer provenance is<br /> tracked by several bpf_reg_state fields.<br /> <br /> Use the caller&amp;#39;s temporary offset register to preserve the scalar operand<br /> while replacing the destination with the full pointer state. This preserves<br /> the frame number for PTR_TO_STACK registers and keeps parent identity<br /> fields consistent.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_cake: drop WARN_ON(1) for malformed packets in ACK filter<br /> <br /> The sch_cake ACK filter parses packets to find the TCP header and filter<br /> duplicated ACKs if the flow is backlogged. The parsing code contains a<br /> WARN_ON(1) which can be triggered by a malformed IP header in certain<br /> cases. Depending on the system configuration, this leads either to<br /> either spamming dmesg with warnings, or a panic if panic_on_warn is set.<br /> <br /> The code already correctly skips the offending packet in the branch that<br /> triggers the warning, so the WARN_ON itself doesn&amp;#39;t really serve any<br /> purpose. So just drop it altogether to avoid the inconvenient side<br /> effects.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: fix potential use-after-free in tunnel segmentation<br /> <br /> __skb_udp_tunnel_segment() gets the UDP header before ensuring the<br /> tunnel header is in the skb head. If the pull reallocates skb-&gt;head,<br /> the saved UDP header pointer is no longer valid.<br /> <br /> Get the UDP header after the pull to avoid a potential use-after-free.