Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()<br /> <br /> In vti6_tnl_lookup(), when an exact match for a tunnel fails,<br /> the code falls back to searching for wildcard tunnels:<br /> <br /> - Tunnels matching the packet&amp;#39;s local address, with any remote address<br /> wildcard remote).<br /> <br /> - Tunnels matching the packet&amp;#39;s remote address, with any local address<br /> (wildcard local).<br /> <br /> However, vti6 stores all these different types of tunnels in the same<br /> hash table (ip6n-&gt;tnls_r_l) prone to hash collisions.<br /> <br /> The bug is that the fallback search loops in vti6_tnl_lookup() were<br /> missing checks to ensure that the candidate tunnel actually has<br /> a wildcard address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: revalidate bridge ports<br /> <br /> ebt_redirect_tg() dereferences br_port_get_rcu() return without a<br /> NULL check, causing a kernel panic when the bridge port has been<br /> removed between the original hook invocation and an NFQUEUE<br /> reinject.<br /> <br /> A mere NULL check isn&amp;#39;t sufficient, however. As sashiko review<br /> points out userspace can not only remove the port from the bridge,<br /> it could also place the device in a different virtual device, e.g.<br /> macvlan.<br /> <br /> If this happens, we must drop the packet, there is no way for us to<br /> reinject it into the bridge path.<br /> <br /> Switch to _upper API, we don&amp;#39;t need the bridge port structure.<br /> Also, this fix keeps another bug intact:<br /> <br /> Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER<br /> too aggressive, which prevents certain logging features when queueing<br /> in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old<br /> CONFIG_BRIDGE_NETFILTER cruft is off.<br /> <br /> Fixes tag is a common ancestor, this was always broken.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: x_tables: avoid leaking percpu counter pointers<br /> <br /> The native and compat get-entries paths copy the fixed rule entry header<br /> from the kernelized rule blob to userspace before overwriting the entry&amp;#39;s<br /> counter fields with a sanitized counter snapshot.<br /> <br /> On SMP kernels, entry-&gt;counters.pcnt contains the percpu allocation<br /> address used by x_tables rule counters. A caller can provide a userspace<br /> buffer that faults during the initial fixed-header copy after pcnt has<br /> been copied but before the later sanitized counter copy runs. The syscall<br /> then returns -EFAULT while leaving the raw percpu pointer in userspace.<br /> <br /> Copy only the fixed entry prefix before counters from the kernelized rule<br /> blob, then copy the sanitized counter snapshot into the counter field.<br /> Apply this ordering to the IPv4, IPv6, and ARP native and compat<br /> get-entries implementations so a fault cannot expose the internal percpu<br /> counter pointer.

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.

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.

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.

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.

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)

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().

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.

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.

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.