Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ima: fix out-of-bounds read in xattr_verify()<br /> <br /> The digest-length check in xattr_verify() mixes int and size_t:<br /> <br /> if (xattr_len - sizeof(xattr_value-&gt;type) - hash_start &gt;=<br /> iint-&gt;ima_hash-&gt;length)<br /> <br /> sizeof() yields size_t, so the usual arithmetic conversions promote<br /> the whole left-hand side to unsigned 64-bit before the subtraction<br /> runs. For a truncated xattr this underflows instead of going negative:<br /> a 1-byte IMA_XATTR_DIGEST_NG xattr (xattr_len == 1, hash_start == 1)<br /> turns "1 - 1 - 1" into SIZE_MAX, which is trivially &gt;= ima_hash-&gt;length.<br /> The check then passes and the following memcmp() reads<br /> iint-&gt;ima_hash-&gt;length bytes starting past the end of the buffer<br /> vfs_getxattr_alloc() allocated for it.<br /> <br /> Nothing upstream clamps xattr_len back into a safe range first:<br /> ima_get_hash_algo() only special-cases xattr_len

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF<br /> <br /> Patch series "mm: fix UAF caused by race between ptdump and vmap pgtable<br /> freeing", v6.<br /> <br /> Kernel page table walkers fall into two broad categories - those ranges<br /> where no exclusion is required via walk_kernel_page_table_range_lockless()<br /> and those where exclusion is required via walk_kernel_page_table_range()<br /> or walk_page_range_debug().<br /> <br /> The former category is used only by arm64 arch code operating on ranges it<br /> both wholly owns and does not concurrently write.<br /> <br /> The latter category consists of kernel page table walkers operating on<br /> ranges that are wholly owned (but which need exclusion against concurrent<br /> writers).<br /> <br /> The lock used for exclusion is the mmap lock, and for kernel ranges this<br /> is the mmap lock on init_mm.<br /> <br /> ptdump is a special case being both the only user of<br /> walk_page_range_debug(), and the only case in which it walks ranges it<br /> does not own.<br /> <br /> This presents a problem, as page tables may be freed under ptdump. And<br /> indeed there is a use-after-free bug in the kernel as a result, which this<br /> series addresses.<br /> <br /> vmap promotes page tables to huge leaf entries where possible, freeing the<br /> lower page table when it does. It does this with no meaningful locks held<br /> against concurrent ptdump walks.<br /> <br /> As a result, use-after-free can currently occur. This series addresses<br /> the issue by having the vmap huge promotion logic acquire the mmap read<br /> lock while both setting the huge page table entry and freeing the prior<br /> leaf page table.<br /> <br /> The ptdump code already acquires the mmap write lock, so by doing so we<br /> ensure that the ptdump walker only ever observes either the huge page<br /> table entry or the existing page table entry, and nothing is freed<br /> underneath it.<br /> <br /> A mitigation for this issue was already applied for arm64 in commit<br /> fa93b45fd397 ("arm64: Enable vmalloc-huge with ptdump"), which this series<br /> has to deal with carefully.<br /> <br /> This mitigation resolves the issue by acquiring the mmap read lock on<br /> init_mm on vmap page table free if a ptdump is in progress.<br /> <br /> However the fix in this series would cause a deadlock if we were to simply<br /> apply it for arm64 without also reverting the change.<br /> <br /> This is because vmap may acquire the read lock before ptdump attempts to<br /> acquire the write lock, which then gets queued, and rwsem starvation rules<br /> mean that the (unacknowledged) nested mmap read lock in the arm64 code<br /> would also block, meaning the original read lock is never released and<br /> thus deadlock.<br /> <br /> This series works around this by #ifndef CONFIG_ARM64&amp;#39;ing the mmap read<br /> lock in vmap logic, then partially reverting commit fa93b45fd397 ("arm64:<br /> Enable vmalloc-huge with ptdump"), keeping the enablement of huge vmap<br /> support, and removing the ifdeffery with the partial revert patch.<br /> <br /> There are related issues that are also addressed in this series:<br /> <br /> * x86 page attribute logic, specifically Change Page Attributes (CPA),<br /> implements a feature whereby huge ranges can be collapsed into huge leaf<br /> entries. This can similarly cause a UAF when done in parallel with a<br /> ptdump walk, so similarly acquire the init_mm mmap lock to avoid this.<br /> <br /> * The CPA logic allows concurrent page table manipulation and CPA<br /> collapse, meaning the former risks accessing a page table the latter<br /> frees. Fix this by acquiring mmap write lock on init_mm across the<br /> whole CPA collapse operation and read lock on the page table<br /> manipulation.<br /> <br /> * x86 and arm64 permit walks of non-kernel mm&amp;#39;s (both allowing efi mm<br /> walks, and in x86&amp;#39;s case arbitrary mm&amp;#39;s), so we ensure kernel mappings<br /> remain stable by locking the init_mm as well as the mm being walked.<br /> <br /> The ordering of patches is established for both strict dependencies (the<br /> arm64 partial revert in particular has to be done after the vmap changes)<br /> and logical ones (the non-kernel mm fix only makes sense once the vmap/CPA<br /> fixes are in place).<br /> <br /> <br /> This patch (of 3):<br /> <br /> Currently there is a nasty ra<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: evdev - fix information leak in evdev_pass_values()<br /> <br /> In evdev_pass_values(), the input_event structure is allocated on the<br /> kernel stack and populated field-by-field. However, it is never fully<br /> initialized. On architectures where struct input_event contains explicit<br /> or implicit padding (such as the 32-bit __pad field on SPARC64), these<br /> padding bytes are left uninitialized.<br /> <br /> When this event structure is subsequently passed to the client buffer<br /> and later copied to userspace, the uninitialized padding bytes leak<br /> kernel stack memory, potentially exposing sensitive information.<br /> <br /> Similar issues exist in __evdev_queue_syn_dropped and __pass_event.<br /> <br /> Fix this by explicitly zeroing the entire event structure with memset()<br /> before populating its fields. This ensures all padding bytes are cleared<br /> before the data crosses the security boundary.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: fix incorrect flush address in direct page table reclaim<br /> <br /> When zap_pte_range reclaims a page table, it does:<br /> <br /> pte_free_tlb(tlb, pmd_pgtable(pmdval), addr);<br /> <br /> and this is unconditionally wrong: if this code executes, addr *always*<br /> points one past the end of the range covered by the table. The addr<br /> parameter is used to flush the TLB (really the paging-structure-cache)<br /> to drop references to the to-be-freed table, and any architecture that<br /> cares about the parameter will flush the wrong address. (But they&amp;#39;ll<br /> still free the correct page).<br /> <br /> I think it&amp;#39;s worth contemplating why the kernel works at all.<br /> <br /> If we hit the offending line of code, we will first clear the PMD entry<br /> (line 1954, zap_empty_pte_table), then we will issue pending flushes if<br /> force_flush is set (tlb_flush_mmu_tlbonly(tlb)), then we will skip the<br /> retry on line 1979 (phew!), and then we will do the offending<br /> pte_free_tlb call. *Or* we will clear the PMD entry immediately before<br /> pte_free_tlb (line 1983, zap_pte_table_if_empty).<br /> <br /> If we have any pending flushes (i.e. we actually zapped any last-level<br /> entries) at the time we clear the PMD entry, then the flush really ought<br /> to flush all references to the table (Linus certainly seems to think it<br /> will on all architectures [0]).<br /> <br /> The condition under which we have no accumulated flushes at the time of<br /> the clear is very complex (the whole zap_pte_range function has absurdly<br /> complex control flow). If we do hit the bad case, then we will end up<br /> clearing the PMD entry after the last time the range is flushed, and any<br /> CPU is free to cache a reference to the (empty) page table. If this<br /> happens due to an ordinary read or write, it would segfault, so it would<br /> be rare. But the cache could be speculatively filled as well. Then<br /> we&amp;#39;ll flush the wrong address and then free and possibly reuse the<br /> table.<br /> <br /> On x86, even flushing the wrong address works on non-KPTI Intel systems<br /> because INVLPG flushes *all* paging-structure-caches, not just the ones<br /> for the target address. But INVPCID does not, and flush_tlb_one_user<br /> will use INVPCID if it&amp;#39;s available. And then we&amp;#39;re toast. AMD systems<br /> are more susceptible: we set the EFER.TCE bit, which makes even INVLPG<br /> only flush the target address.<br /> <br /> I think this might fix an issue in ripgrep reported here:<br /> https://github.com/BurntSushi/ripgrep/issues/3494<br /> <br /> [0] https://lore.kernel.org/all/CA+55aFzBggoXtNXQeng5d_mRoDnaMBE5Y+URs+PHR67nUpMtaw@mail.gmail.com/T/#u

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: stabilize tty reference in kbd_keycode with tty_port_tty_get<br /> <br /> kbd_keycode() reads vc-&gt;port.tty without acquiring a tty reference,<br /> racing against con_shutdown() which clears port.tty under a different<br /> lock. Use tty_port_tty_get()/tty_kref_put() to hold a proper reference<br /> for the duration the tty pointer is needed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vt: add permission check for KDSKBMETA ioctl<br /> <br /> KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all<br /> other keyboard setter ioctls in vt_k_ioctl() enforce, allowing a process<br /> to change meta mode on a non-controlling console without authorization.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: ipheth: fix carrier_work UAF on disconnect<br /> <br /> ipheth_sndbulk_callback() re-arms the carrier-check work on any<br /> non-zero URB status:<br /> <br /> else<br /> schedule_delayed_work(&amp;dev-&gt;carrier_work, 0);<br /> <br /> Nothing ties that to the interface being up, so the work can be armed<br /> again after ipheth_close() has already drained it, and stay armed<br /> until the netdev whose private area embeds it is freed.<br /> <br /> On unplug with a TX URB in flight, ipheth_disconnect() drains the work<br /> through unregister_netdev() -&gt; ipheth_close() -&gt;<br /> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs().<br /> usb_kill_urb() completes the in-flight TX URB with -ENOENT, so<br /> ipheth_sndbulk_callback() runs after the drain and re-arms<br /> carrier_work.<br /> <br /> The same completion also re-arms the work if the interface is only<br /> brought down while a TX URB is in flight, and<br /> ipheth_carrier_check_work() then keeps re-queueing itself once a<br /> second. unregister_netdev() does not call ipheth_close() for an<br /> already-down interface, so nothing drains it on the later unplug<br /> either.<br /> <br /> In both cases free_netdev() frees the netdev while carrier_work is<br /> still pending, and ipheth_carrier_check_work() dereferences freed<br /> memory.<br /> <br /> Tie the work to the interface state instead of chasing the completion:<br /> disable it in ipheth_close() and enable it in ipheth_open(), so a<br /> schedule_delayed_work() from the URB completion is a no-op whenever<br /> the interface is not up. disable_delayed_work_sync() also waits for a<br /> running instance, so it fully replaces the cancel_delayed_work_sync()<br /> it takes the place of. The work starts out disabled in ipheth_probe()<br /> so the enable/disable counts balance from the first open.<br /> <br /> Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and<br /> raw-gadget standing in for the device, driving the second path above (the<br /> interface is already down, so unregister_netdev() does not call<br /> ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in<br /> __run_timers(), freed by ipheth_disconnect() and re-armed from<br /> ipheth_sndbulk_callback() via queue_delayed_work_on(). The<br /> same trigger on a kernel differing only by this patch reports 0 of 15,<br /> and the carrier check still functions across open/close cycles.<br /> <br /> The reproducer needs an attached USB device that stops draining bulk OUT,<br /> plus a link down and unplug, driven as root. It is not a privilege<br /> boundary crossing and no exploit primitive was developed.<br /> <br /> Found by 0sec (https://0sec.ai).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: ax88179_178a: fix skb leak in ax88179_tx_fixup()<br /> <br /> When the interface has NETIF_F_SG enabled and skb_linearize() fails in<br /> ax88179_tx_fixup(), the function returns NULL without freeing the skb.<br /> <br /> usbnet_start_xmit() treats a NULL return from tx_fixup() as a drop<br /> (info-&gt;flags does not set FLAG_MULTI_PACKET for this driver), jumping<br /> to the "drop" label where it does `if (skb) dev_kfree_skb_any(skb)`.<br /> Because tx_fixup() returned NULL, the local skb variable in<br /> usbnet_start_xmit() is NULL, so the original skb is never freed — a<br /> memory leak on every TX frame whose linearization fails (i.e. under<br /> memory pressure).<br /> <br /> Free the skb before returning, matching the error handling already used<br /> for the pskb_expand_head() failure path in the same function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: reject overly deep qdisc hierarchies<br /> <br /> Deep qdisc hierarchies can lead to excessive recursion in qdisc tree<br /> walkers and exhaust the kernel stack. The existing loop check does not<br /> cover the create-and-graft path, so a hierarchy can still be extended by<br /> creating a new child qdisc below an already deep parent.<br /> <br /> Store the hierarchy depth in struct Qdisc and update it when qdiscs are<br /> grafted. Reject new child qdiscs once the parent is already at the maximum<br /> allowed depth.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: reallocate update replies for mismatched IDs<br /> <br /> ovs_flow_cmd_new() preallocates the optional reply skb before it takes<br /> ovs_mutex and before it knows which existing flow will be updated.<br /> <br /> That is normally fine because the skb is sized from the request flow<br /> identifier. That identifier also becomes the inserted flow&amp;#39;s identifier.<br /> For updates, however, a request with a UFID may miss the UFID lookup and<br /> then fall back to the flow key lookup. That lookup can legitimately find<br /> an existing key-identified flow. UFIDs are optional and the flow key is<br /> the primary identifier.<br /> <br /> For echoed replies, ovs_flow_cmd_fill_info() writes the matched flow&amp;#39;s<br /> identifier, not the request identifier used for the preallocation. A short<br /> request UFID can therefore leave too little room for the key identifier.<br /> The fill can then fail with -EMSGSIZE and hit the BUG_ON(error

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix skb length accounting after generic XDP frag adjustment<br /> <br /> Generic XDP exposes non-linear skb fragments through an xdp_buff. If an<br /> XDP program adjusts the fragment area, bpf_prog_run_generic_xdp() copies<br /> xdp_frags_size back to skb-&gt;data_len but leaves skb-&gt;len containing the<br /> old fragment contribution.<br /> <br /> After a fragment shrink, this makes skb_headlen() larger than the actual<br /> linear area. In the reproduced UDP receive path, __skb_datagram_iter()<br /> copied 1024 bytes past the actual linear tail to userspace, starting at<br /> struct skb_shared_info. The copied bytes included the affected skb&amp;#39;s<br /> nr_frags, xdp_frags_size and a kernel pointer from<br /> skb_shinfo(skb)-&gt;frags[0]. Real packet data was displaced by the same<br /> amount and truncated at the end.<br /> <br /> Subtract the old data_len before replacing it and add the new data_len<br /> afterwards, keeping skb-&gt;len and skb-&gt;data_len synchronized.<br /> <br /> A 60000-byte UDP datagram on a veth pair with MTU 64000 was shortened by<br /> 1024 bytes from its fragment area. Before the fix, all 10 runs produced<br /> corrupted payloads. After the fix, all 10 runs matched the expected<br /> payload exactly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> packet: synchronize pressure clearing with ring reconfiguration<br /> <br /> packet_set_ring() updates the RX ring state under sk_receive_queue.lock,<br /> but used to publish the tpacket receive mode through po-&gt;prot_hook.func<br /> after releasing that lock. packet_poll() and packet_recvmsg() can then<br /> run the pressure clearing path after the ring has been cleared while<br /> still seeing tpacket_rcv, causing __packet_rcv_has_room() to dereference<br /> stale or NULL ring storage.<br /> <br /> Move the existing receive hook assignment into the same<br /> sk_receive_queue.lock section as the ring state update. Keep the<br /> assignment otherwise unchanged, including on TX ring reconfiguration, to<br /> avoid adding behavior changes that are not required for the fix.<br /> <br /> Serialize packet_recvmsg() pressure clearing with the same queue lock<br /> only after PACKET_SOCK_PRESSURE has been observed. If the flag is clear<br /> and the socket has moved away from tpacket_rcv, packet_set_ring() has<br /> already detached the socket and waited for synchronize_net(), so no new<br /> packet input can set the flag again.<br /> <br /> packet_poll() already holds sk_receive_queue.lock, so it uses the new<br /> unlocked helper directly.