Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_exthdr: fix register tracking for F_PRESENT flag<br /> <br /> nft_exthdr_init() passes user-controlled priv-&gt;len to<br /> nft_parse_register_store(), which marks that many bytes in the<br /> register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT<br /> is set, the eval paths write only 1 byte (nft_reg_store8) or<br /> 4 bytes (*dest = 0 on TCP/DCCP error path). When len &gt; 4,<br /> registers beyond the first are never written, retaining<br /> uninitialized stack data from nft_regs.<br /> <br /> Bail out if userspace requests too much data when F_PRESENT is set.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mvpp2: sync RX data at the hardware packet offset<br /> <br /> mvpp2 programs the RX queue packet offset, so hardware writes received<br /> data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at<br /> dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the<br /> unused headroom and misses the same number of bytes at the packet tail.<br /> <br /> On non-coherent DMA systems this can leave the CPU reading stale cache<br /> contents for the end of the received frame.<br /> <br /> Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range<br /> offset so the sync covers the Marvell header and packet data actually<br /> written by hardware.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mvpp2: limit XDP frame size to the RX buffer<br /> <br /> mvpp2 has short and long BM pools, and short pool buffers can be smaller<br /> than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with<br /> PAGE_SIZE as frame size.<br /> <br /> XDP helpers use frame_sz to validate tail growth and to derive the hard<br /> end of the data area. Advertising PAGE_SIZE for short buffers can let<br /> bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting<br /> memory or later tripping skb tailroom checks.<br /> <br /> Initialize the XDP buffer with bm_pool-&gt;frag_size so XDP tailroom matches<br /> the actual buffer backing the packet.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mvpp2: refill RX buffers before XDP or skb use<br /> <br /> The RX error path returns the current descriptor buffer to the hardware<br /> BM pool. That is only valid while the driver still owns the buffer.<br /> <br /> mvpp2_rx_refill() can fail after the current buffer has been handed to<br /> XDP or attached to an skb. In those cases mvpp2_run_xdp() may have<br /> recycled, redirected, or queued the page for XDP_TX, and an skb free also<br /> retires the data buffer. Returning such a buffer to BM lets hardware DMA<br /> into memory that is no longer owned by the RX ring.<br /> <br /> Refill the BM pool before handing the current buffer to XDP or to the<br /> skb. If the allocation fails there, drop the packet and return the<br /> still-owned current buffer to BM, preserving the pool depth. Once the<br /> refill succeeds, later local drops retire/free the current buffer instead<br /> of returning it to BM.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: Fix a potential NPD in cleanup_prefix_route()<br /> <br /> addrconf_get_prefix_route() can return the fib6_null_entry sentinel<br /> entry which has a NULL fib6_table pointer. Therefore, before setting the<br /> route&amp;#39;s expiration time, check that we are not working with this entry,<br /> as otherwise a NPD will be triggered [1].<br /> <br /> Note that the other callers of addrconf_get_prefix_route() are not<br /> susceptible to this bug:<br /> <br /> 1. addrconf_prefix_rcv(): Requests a route with the &amp;#39;RTF_ADDRCONF |<br /> RTF_PREFIX_RT&amp;#39; flags which are not set on fib6_null_entry.<br /> <br /> 2. modify_prefix_route(): Fixed by commit a747e02430df ("ipv6: avoid<br /> possible NULL deref in modify_prefix_route()").<br /> <br /> 3. __ipv6_ifa_notify(): Calls ip6_del_rt() which specifically checks for<br /> fib6_null_entry and returns an error.<br /> <br /> [1]<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]<br /> [...]<br /> Call Trace:<br /> <br /> __kasan_check_byte (mm/kasan/common.c:573)<br /> lock_acquire.part.0 (kernel/locking/lockdep.c:5842 (discriminator 1))<br /> _raw_spin_lock_bh (kernel/locking/spinlock.c:182 (discriminator 1))<br /> cleanup_prefix_route (net/ipv6/addrconf.c:1280)<br /> ipv6_del_addr (net/ipv6/addrconf.c:1342)<br /> inet6_addr_del.isra.0 (net/ipv6/addrconf.c:3119)<br /> inet6_rtm_deladdr (net/ipv6/addrconf.c:4812)<br /> rtnetlink_rcv_msg (net/core/rtnetlink.c:6997)<br /> netlink_rcv_skb (net/netlink/af_netlink.c:2555)<br /> netlink_unicast (net/netlink/af_netlink.c:1344)<br /> netlink_sendmsg (net/netlink/af_netlink.c:1899)<br /> __sock_sendmsg (net/socket.c:802 (discriminator 4))<br /> ____sys_sendmsg (net/socket.c:2698)<br /> ___sys_sendmsg (net/socket.c:2752)<br /> __sys_sendmsg (net/socket.c:2784)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: fix krealloc() memory leak<br /> <br /> Don&amp;#39;t just overwrite the original pointer passed to krealloc()<br /> with its return value without checking latter:<br /> <br /> MEM = krealloc(MEM, SZ, GFP);<br /> <br /> If krealloc() returns NULL, that erases the pointer<br /> to the still allocated memory, hence leaks this memory.<br /> Instead, use a temporary variable, check it&amp;#39;s not NULL<br /> and only then assign it to the original pointer:<br /> <br /> TMP = krealloc(MEM, SZ, GFP);<br /> if (!TMP) return;<br /> MEM = TMP;<br /> <br /> While on it, use krealloc_array().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_tunnel: fix use-after-free on object destroy<br /> <br /> nft_tunnel_obj_destroy() calls metadata_dst_free() which directly<br /> kfree()s the metadata_dst, ignoring the dst_entry refcount. Packets<br /> that took a reference via dst_hold() in nft_tunnel_obj_eval() and<br /> are still queued (e.g. in a netem qdisc) are left with a dangling<br /> pointer. When these packets are eventually dequeued, dst_release()<br /> operates on freed memory.<br /> <br /> Replace metadata_dst_free() with dst_release() so the metadata_dst<br /> is freed only after all references are dropped. The dst subsystem<br /> already handles metadata_dst cleanup in dst_destroy() when<br /> DST_METADATA is set.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register<br /> <br /> NFT_META_BRI_IIFHWADDR declares its destination register with<br /> len = ETH_ALEN (6 bytes), which the register-init tracking rounds up to<br /> two 32-bit registers (8 bytes). nft_meta_bridge_get_eval() then does<br /> memcpy(dest, br_dev-&gt;dev_addr, ETH_ALEN), writing only 6 bytes and<br /> leaving the upper 2 bytes of the second register as uninitialised<br /> nft_do_chain() stack. A downstream load of that register span leaks<br /> those stale bytes to userspace.<br /> <br /> Zero the second register before the memcpy so the full declared span is<br /> written.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: shm: fix shm leak in register_shm_helper()<br /> <br /> register_shm_helper() allocates shm before calling<br /> iov_iter_npages(). If iov_iter_npages() returns 0, the function<br /> jumps to err_ctx_put and leaks shm.<br /> <br /> This can be triggered by TEE_IOC_SHM_REGISTER with<br /> struct tee_ioctl_shm_register_data where length is 0.<br /> <br /> Jump to err_free_shm instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_sync: reject oversized Broadcast Announcement prepend<br /> <br /> Existing advertising instances can already hold the maximum extended<br /> advertising payload. When hci_adv_bcast_annoucement() prepends the<br /> Broadcast Announcement service data to that payload, the combined data<br /> may no longer fit in the temporary buffer used to rebuild the<br /> advertising data.<br /> <br /> Reject that case before copying the existing payload and report the<br /> failure through the device log. This keeps the existing advertising<br /> data intact and avoids overrunning the temporary buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: reject BR/EDR signaling packets over MTUsig<br /> <br /> net/bluetooth/l2cap_core.c:l2cap_sig_channel() accepts BR/EDR<br /> signaling packets up to the channel MTU and dispatches each command<br /> without enforcing the signaling MTU (MTUsig). A Bluetooth BR/EDR peer<br /> within radio range can send a fixed-channel CID 0x0001 packet that is<br /> larger than MTUsig and contains many L2CAP_ECHO_REQ commands before<br /> pairing. In a real-radio stock-kernel run, one 681-byte signaling<br /> packet containing 168 zero-length ECHO_REQ commands made the target<br /> transmit 168 ECHO_RSP frames over about 220 ms.<br /> <br /> Impact: a Bluetooth BR/EDR peer within radio range, before pairing, can<br /> force 168 ECHO_RSP frames from one 681-byte fixed-channel signaling<br /> packet containing packed ECHO_REQ commands.<br /> <br /> Define Linux&amp;#39;s BR/EDR signaling MTU as the spec minimum of 48 bytes and<br /> reject any larger signaling packet with one L2CAP_COMMAND_REJECT_RSP<br /> carrying L2CAP_REJ_MTU_EXCEEDED before any command is dispatched.<br /> <br /> The Bluetooth Core spec wording for MTUExceeded says the reject<br /> identifier shall match the first request command in the packet, and<br /> that packets containing only responses shall be silently discarded.<br /> Linux intentionally deviates from that prescription: silently<br /> discarding desynchronizes the peer because the remote stack never<br /> learns its responses were dropped, and locating the first request<br /> command requires walking command headers past MTUsig, i.e. processing<br /> bytes from a packet we have already decided is too large to process.<br /> We therefore always emit one reject and use the identifier from the<br /> first command header, a single fixed-offset byte read.<br /> <br /> The unrestricted BR/EDR signaling parser and ECHO_REQ response path both<br /> trace to the initial git import; no later introducing commit is<br /> available for a Fixes tag.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison<br /> <br /> Two concurrent madvise(MADV_HWPOISON) calls on the same hugetlb page can<br /> trigger a recursive spinlock self-deadlock (AA deadlock) on hugetlb_lock<br /> when racing with a concurrent unmap:<br /> <br /> thread#0 thread#1<br /> -------- --------<br /> madvise(folio, MADV_HWPOISON)<br /> -&gt; poisons the folio successfully<br /> madvise(folio, MADV_HWPOISON) unmap(folio)<br /> try_memory_failure_hugetlb<br /> get_huge_page_for_hwpoison<br /> spin_lock_irq(&amp;hugetlb_lock) MF_HUGETLB_FOLIO_PRE_POISONED<br /> goto out:<br /> folio_put()<br /> refcount: 1 -&gt; 0<br /> free_huge_folio()<br /> spin_lock_irqsave(&amp;hugetlb_lock)<br /> -&gt; AA DEADLOCK!<br /> <br /> The out: path in __get_huge_page_for_hwpoison() calls folio_put() to drop<br /> the GUP reference while the hugetlb_lock is still held by the hugetlb.c<br /> wrapper get_huge_page_for_hwpoison(). If concurrent unmap has released<br /> the page table mapping reference, folio_put() drops the folio refcount to<br /> zero, triggering free_huge_folio() which attempts to re-acquire the<br /> non-recursive hugetlb_lock.<br /> <br /> Fix this by moving hugetlb_lock acquisition from the hugetlb.c wrapper<br /> into get_huge_page_for_hwpoison(). Place spin_unlock_irq() before the<br /> folio_put() at the out: label so the folio is always released outside the<br /> lock.<br /> <br /> [akpm@linux-foundation.org: fix race, rename label per Miaohe]