Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: rockchip: fix generic IRQ chip leak on remove<br /> <br /> The driver allocates domain generic chips using<br /> irq_alloc_domain_generic_chips() during probe. However, on driver<br /> remove/teardown, the generic chips are not automatically freed when the<br /> IRQ domain is removed because the domain flags do not include<br /> IRQ_DOMAIN_FLAG_DESTROY_GC.<br /> <br /> This causes both the domain generic chips structure and the associated<br /> generic chips to be leaked. Additionally, the generic chips remain on<br /> the global gc_list and may later be visited by generic IRQ chip suspend,<br /> resume, or shutdown callbacks after the GPIO bank has been removed,<br /> potentially resulting in a use-after-free and kernel crash.<br /> <br /> Fix the resource leak by explicitly calling<br /> irq_domain_remove_generic_chips() before removing the IRQ domain in<br /> rockchip_gpio_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: fix possible kfree_skb of ERR_PTR<br /> <br /> After the patch in the "Fixes" tag, the allocation of the "reply" skb<br /> can happen either before or after locking the ovs_mutex.<br /> <br /> However, error cleanups still follow the classical reversed order,<br /> assuming "reply" is allocated before locking: it is freed after unlocking.<br /> <br /> If "reply" allocation happens after locking the mutex and it fails,<br /> "reply" is left with an ERR_PTR, and execution jumps to the correspondent<br /> cleanup stage which will try to free an invalid pointer.<br /> <br /> Fix this by setting the pointer to NULL after having saved its error<br /> value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list<br /> <br /> mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using<br /> the PF&amp;#39;s log_max_current_uc/mc_list capabilities. When querying a VF<br /> vport with a larger configured max (via devlink), the firmware response<br /> can overflow this buffer:<br /> <br /> BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core]<br /> Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385<br /> <br /> CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)<br /> Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x69/0xa0<br /> print_report+0x176/0x4e4<br /> kasan_report+0xc8/0x100<br /> mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core]<br /> esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core]<br /> esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core]<br /> esw_vport_change_handler+0x6a/0x90 [mlx5_core]<br /> process_one_work+0x87f/0x15e0<br /> worker_thread+0x62b/0x1020<br /> kthread+0x375/0x490<br /> ret_from_fork+0x4dc/0x810<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> <br /> Fix by querying the vport&amp;#39;s own HCA caps to size the buffer correctly.<br /> Refactor the function to allocate and return the MAC list internally,<br /> removing the caller&amp;#39;s dependency on knowing the correct max.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure<br /> <br /> In the XSK branch of mlx5e_xmit_xdp_buff(), when sq-&gt;xmit_xdp_frame()<br /> returns false (e.g. XDPSQ is full), the function returns without<br /> unmapping the DMA address or freeing the xdp_frame allocated by<br /> xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on<br /> success, so the completion path cannot recover these entries.<br /> <br /> With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind:<br /> <br /> DMA-API: pci 0000:08:00.0: device driver has pending DMA<br /> allocations while released from device [count=1116]<br /> One of leaked entries details: [device address=0x000000010ffd7028]<br /> [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy]<br /> WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180<br /> ...<br /> DMA-API: Mapped at:<br /> debug_dma_map_phys+0x4b/0xd0<br /> dma_map_phys+0xfd/0x2d0<br /> mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core]<br /> mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core]<br /> mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core]<br /> <br /> Add the missing unmap + xdp_return_frame, matching the cleanup already<br /> done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch,<br /> so no per-frag unmap is needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: sit: reload inner IPv6 header after GSO offloads<br /> <br /> ipip6_tunnel_xmit() caches the inner IPv6 header pointer at function<br /> entry and continues using it after iptunnel_handle_offloads().<br /> <br /> For GSO skbs, iptunnel_handle_offloads() calls skb_header_unclone().<br /> When the skb header is cloned, skb_header_unclone() can call<br /> pskb_expand_head(), which may move the skb head. The pskb_expand_head()<br /> contract requires pointers into the skb header to be reloaded after the<br /> call.<br /> <br /> If the later skb_realloc_headroom() branch is not taken, SIT uses the<br /> stale iph6 pointer to read the inner hop limit and DS field. That can<br /> read from a freed skb head after the old head&amp;#39;s remaining clone is<br /> released.<br /> <br /> Reload iph6 after the offload helper succeeds and before subsequent<br /> reads from the inner IPv6 header. Keep the existing reload after<br /> skb_realloc_headroom(), since that branch can also replace the skb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix uninit-value in __sctp_rcv_asconf_lookup()<br /> <br /> __sctp_rcv_asconf_lookup() in net/sctp/input.c only checks that the ASCONF<br /> chunk can hold the ADDIP header and a parameter header, then calls<br /> af-&gt;from_addr_param(), which reads the full address (16 bytes for IPv6)<br /> trusting the parameter&amp;#39;s declared length.<br /> <br /> An unauthenticated peer can send a truncated trailing ASCONF chunk that<br /> declares an IPv6 address parameter but stops after the 4-byte parameter<br /> header; reached from the no-association lookup path, from_addr_param() then<br /> reads uninitialized bytes past the parameter.<br /> <br /> Impact: an unauthenticated SCTP peer makes the receive path read up to 16<br /> bytes of uninitialized memory past a truncated ASCONF address parameter.<br /> <br /> The sibling __sctp_rcv_init_lookup() bounds parameters with<br /> sctp_walk_params(); this path open-codes the fetch and omits the bound.<br /> Verify the whole address parameter lies within the chunk before<br /> from_addr_param() reads it, the same class of fix as commit 51e5ad549c43<br /> ("net: sctp: fix KMSAN uninit-value in sctp_inq_pop").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: validate embedded INIT chunk and address list lengths in cookie<br /> <br /> sctp_unpack_cookie() only checked that the embedded INIT chunk length<br /> did not exceed the remaining cookie payload, but did not ensure that the<br /> INIT chunk is large enough to contain a complete INIT header.<br /> <br /> A malformed COOKIE_ECHO can therefore carry a truncated INIT chunk whose<br /> length field is smaller than sizeof(struct sctp_init_chunk). Later,<br /> sctp_process_init() accesses INIT parameters unconditionally, which may<br /> lead to out-of-bounds reads.<br /> <br /> In addition, raw_addr_list_len is not fully validated against the<br /> remaining cookie payload. When cookie authentication is disabled, an<br /> attacker can supply an oversized raw_addr_list_len and cause<br /> sctp_raw_to_bind_addrs() to read beyond the end of the cookie. The<br /> address parser also lacks sufficient bounds checks for parameter headers<br /> and lengths, allowing malformed address parameters to trigger<br /> out-of-bounds reads.<br /> <br /> Fix this by:<br /> <br /> - requiring the embedded INIT chunk length to be at least sizeof(struct<br /> sctp_init_chunk);<br /> - validating that the INIT chunk and raw address list together fit<br /> within the cookie payload;<br /> - verifying sufficient data exists for each address parameter header and<br /> payload before parsing it.<br /> <br /> Note that sctp_verify_init() must be called after sctp_unpack_cookie()<br /> and before sctp_process_init() when cookie authentication is disabled.<br /> This will be addressed in a separate patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: guard timestamp cmsgs to real error queue skbs<br /> <br /> skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb<br /> from sk_error_queue. That assumption is not true for AF_PACKET sockets:<br /> outgoing packet taps are also delivered to packet sockets with<br /> skb-&gt;pkt_type == PACKET_OUTGOING, but their skb-&gt;cb is owned by AF_PACKET<br /> instead of struct sock_exterr_skb.<br /> <br /> If such an skb is received with timestamping enabled, the generic<br /> timestamp cmsg path can read AF_PACKET control-buffer state as<br /> sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop<br /> counter overlaps opt_stats. An odd drop count makes the path emit<br /> SCM_TIMESTAMPING_OPT_STATS with skb-&gt;len and skb-&gt;data. For non-linear<br /> skbs this copies past the linear head and can trigger hardened usercopy or<br /> disclose adjacent heap contents.<br /> <br /> Keep skb_is_err_queue() local to net/socket.c, but make it verify that<br /> the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor<br /> installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal<br /> receive ownership and no longer pass as error-queue skbs, while legitimate<br /> sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free<br /> ownership.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ocp: fix resource freeing order<br /> <br /> Commit a60fc3294a37 ("ptp: rework ptp_clock_unregister() to disable<br /> events") added a call to ptp_disable_all_events() which changes the<br /> configuration of pins if they support EXTTS events. In ptp_ocp_detach()<br /> pins resources are freed before ptp_clock_unregister() and it leads to<br /> use-after-free during driver removal. Fix it by changing the order of<br /> free/unregister calls. To avoid irq handler running on the other core<br /> while ptp device unregistering, call synchronize_irq() after HW is<br /> configured to stop producing irqs and no irqs are in-flight.

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.