Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rt2x00usb: fix devres lifetime<br /> <br /> USB drivers bind to USB interfaces and any device managed resources<br /> should have their lifetime tied to the interface rather than parent USB<br /> device. This avoids issues like memory leaks when drivers are unbound<br /> without their devices being physically disconnected (e.g. on probe<br /> deferral or configuration changes).<br /> <br /> Fix the USB anchor lifetime so that it is released on driver unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: fix use-after-free in timeout object destroy<br /> <br /> nft_ct_timeout_obj_destroy() frees the timeout object with kfree()<br /> immediately after nf_ct_untimeout(), without waiting for an RCU grace<br /> period. Concurrent packet processing on other CPUs may still hold<br /> RCU-protected references to the timeout object obtained via<br /> rcu_dereference() in nf_ct_timeout_data().<br /> <br /> Add an rcu_head to struct nf_ct_timeout and use kfree_rcu() to defer<br /> freeing until after an RCU grace period, matching the approach already<br /> used in nfnetlink_cttimeout.c.<br /> <br /> KASAN report:<br /> BUG: KASAN: slab-use-after-free in nf_conntrack_tcp_packet+0x1381/0x29d0<br /> Read of size 4 at addr ffff8881035fe19c by task exploit/80<br /> <br /> Call Trace:<br /> nf_conntrack_tcp_packet+0x1381/0x29d0<br /> nf_conntrack_in+0x612/0x8b0<br /> nf_hook_slow+0x70/0x100<br /> __ip_local_out+0x1b2/0x210<br /> tcp_sendmsg_locked+0x722/0x1580<br /> __sys_sendto+0x2d8/0x320<br /> <br /> Allocated by task 75:<br /> nft_ct_timeout_obj_init+0xf6/0x290<br /> nft_obj_init+0x107/0x1b0<br /> nf_tables_newobj+0x680/0x9c0<br /> nfnetlink_rcv_batch+0xc29/0xe00<br /> <br /> Freed by task 26:<br /> nft_obj_destroy+0x3f/0xa0<br /> nf_tables_trans_destroy_work+0x51c/0x5c0<br /> process_one_work+0x2c4/0x5a0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref()<br /> <br /> After commit 1618aa3c2e01 ("btrfs: simplify return variables in<br /> lookup_extent_data_ref()"), the err and ret variables were merged into<br /> a single ret variable. However, when btrfs_next_leaf() returns 0<br /> (success), ret is overwritten from -ENOENT to 0. If the first key in<br /> the next leaf does not match (different objectid or type), the function<br /> returns 0 instead of -ENOENT, making the caller believe the lookup<br /> succeeded when it did not. This can lead to operations on the wrong<br /> extent tree item, potentially causing extent tree corruption.<br /> <br /> Fix this by returning -ENOENT directly when the key does not match,<br /> instead of relying on the ret variable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: uinput - fix circular locking dependency with ff-core<br /> <br /> A lockdep circular locking dependency warning can be triggered<br /> reproducibly when using a force-feedback gamepad with uinput (for<br /> example, playing ELDEN RING under Wine with a Flydigi Vader 5<br /> controller):<br /> <br /> ff-&gt;mutex -&gt; udev-&gt;mutex -&gt; input_mutex -&gt; dev-&gt;mutex -&gt; ff-&gt;mutex<br /> <br /> The cycle is caused by four lock acquisition paths:<br /> <br /> 1. ff upload: input_ff_upload() holds ff-&gt;mutex and calls<br /> uinput_dev_upload_effect() -&gt; uinput_request_submit() -&gt;<br /> uinput_request_send(), which acquires udev-&gt;mutex.<br /> <br /> 2. device create: uinput_ioctl_handler() holds udev-&gt;mutex and calls<br /> uinput_create_device() -&gt; input_register_device(), which acquires<br /> input_mutex.<br /> <br /> 3. device register: input_register_device() holds input_mutex and<br /> calls kbd_connect() -&gt; input_register_handle(), which acquires<br /> dev-&gt;mutex.<br /> <br /> 4. evdev release: evdev_release() calls input_flush_device() under<br /> dev-&gt;mutex, which calls input_ff_flush() acquiring ff-&gt;mutex.<br /> <br /> Fix this by introducing a new state_lock spinlock to protect<br /> udev-&gt;state and udev-&gt;dev access in uinput_request_send() instead of<br /> acquiring udev-&gt;mutex. The function only needs to atomically check<br /> device state and queue an input event into the ring buffer via<br /> uinput_dev_event() -- both operations are safe under a spinlock<br /> (ktime_get_ts64() and wake_up_interruptible() do not sleep). This<br /> breaks the ff-&gt;mutex -&gt; udev-&gt;mutex link since a spinlock is a leaf in<br /> the lock ordering and cannot form cycles with mutexes.<br /> <br /> To keep state transitions visible to uinput_request_send(), protect<br /> writes to udev-&gt;state in uinput_create_device() and<br /> uinput_destroy_device() with the same state_lock spinlock.<br /> <br /> Additionally, move init_completion(&amp;request-&gt;done) from<br /> uinput_request_send() to uinput_request_submit() before<br /> uinput_request_reserve_slot(). Once the slot is allocated,<br /> uinput_flush_requests() may call complete() on it at any time from<br /> the destroy path, so the completion must be initialised before the<br /> request becomes visible.<br /> <br /> Lock ordering after the fix:<br /> <br /> ff-&gt;mutex -&gt; state_lock (spinlock, leaf)<br /> udev-&gt;mutex -&gt; state_lock (spinlock, leaf)<br /> udev-&gt;mutex -&gt; input_mutex -&gt; dev-&gt;mutex -&gt; ff-&gt;mutex (no back-edge)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> seg6: separate dst_cache for input and output paths in seg6 lwtunnel<br /> <br /> The seg6 lwtunnel uses a single dst_cache per encap route, shared<br /> between seg6_input_core() and seg6_output_core(). These two paths<br /> can perform the post-encap SID lookup in different routing contexts<br /> (e.g., ip rules matching on the ingress interface, or VRF table<br /> separation). Whichever path runs first populates the cache, and the<br /> other reuses it blindly, bypassing its own lookup.<br /> <br /> Fix this by splitting the cache into cache_input and cache_output,<br /> so each path maintains its own cached dst independently.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix slab-use-after-free in __inet_lookup_established<br /> <br /> The ehash table lookups are lockless and rely on<br /> SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability<br /> during RCU read-side critical sections. Both tcp_prot and<br /> tcpv6_prot have their slab caches created with this flag<br /> via proto_register().<br /> <br /> However, MPTCP&amp;#39;s mptcp_subflow_init() copies tcpv6_prot into<br /> tcpv6_prot_override during inet_init() (fs_initcall, level 5),<br /> before inet6_init() (module_init/device_initcall, level 6) has<br /> called proto_register(&amp;tcpv6_prot). At that point,<br /> tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab<br /> remains NULL permanently.<br /> <br /> This causes MPTCP v6 subflow child sockets to be allocated via<br /> kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab<br /> cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so<br /> when these sockets are freed without SOCK_RCU_FREE (which is<br /> cleared for child sockets by design), the memory can be<br /> immediately reused. Concurrent ehash lookups under<br /> rcu_read_lock can then access freed memory, triggering a<br /> slab-use-after-free in __inet_lookup_established.<br /> <br /> Fix this by splitting the IPv6-specific initialization out of<br /> mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called<br /> from mptcp_proto_v6_init() before protocol registration. This<br /> ensures tcpv6_prot_override.slab correctly inherits the<br /> SLAB_TYPESAFE_BY_RCU slab cache.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rfkill: prevent unlimited numbers of rfkill events from being created<br /> <br /> Userspace can create an unlimited number of rfkill events if the system<br /> is so configured, while not consuming them from the rfkill file<br /> descriptor, causing a potential out of memory situation. Prevent this<br /> from bounding the number of pending rfkill events at a "large" number<br /> (i.e. 1000) to prevent abuses like this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm_user: fix info leak in build_report()<br /> <br /> struct xfrm_user_report is a __u8 proto field followed by a struct<br /> xfrm_selector which means there is three "empty" bytes of padding, but<br /> the padding is never zeroed before copying to userspace. Fix that up by<br /> zeroing the structure before setting individual member variables.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: clear trailing padding in build_polexpire()<br /> <br /> build_expire() clears the trailing padding bytes of struct<br /> xfrm_user_expire after setting the hard field via memset_after(),<br /> but the analogous function build_polexpire() does not do this for<br /> struct xfrm_user_polexpire.<br /> <br /> The padding bytes after the __u8 hard field are left<br /> uninitialized from the heap allocation, and are then sent to<br /> userspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,<br /> leaking kernel heap memory contents.<br /> <br /> Add the missing memset_after() call, matching build_expire().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: altera-tse: fix skb leak on DMA mapping error in tse_start_xmit()<br /> <br /> When dma_map_single() fails in tse_start_xmit(), the function returns<br /> NETDEV_TX_OK without freeing the skb. Since NETDEV_TX_OK tells the<br /> stack the packet was consumed, the skb is never freed, leaking memory<br /> on every DMA mapping failure.<br /> <br /> Add dev_kfree_skb_any() before returning to properly free the skb.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: reject oversized global TT response buffers<br /> <br /> batadv_tt_prepare_tvlv_global_data() builds the allocation length for a<br /> global TT response in 16-bit temporaries. When a remote originator<br /> advertises a large enough global TT, the TT payload length plus the VLAN<br /> header offset can exceed 65535 and wrap before kmalloc().<br /> <br /> The full-table response path still uses the original TT payload length when<br /> it fills tt_change, so the wrapped allocation is too small and<br /> batadv_tt_prepare_tvlv_global_data() writes past the end of the heap object<br /> before the later packet-size check runs.<br /> <br /> Fix this by rejecting TT responses whose TVLV value length cannot fit in<br /> the 16-bit TVLV payload length field.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: pn533: allocate rx skb before consuming bytes<br /> <br /> pn532_receive_buf() reports the number of accepted bytes to the serdev<br /> core. The current code consumes bytes into recv_skb and may already hand<br /> a complete frame to pn533_recv_frame() before allocating a fresh receive<br /> buffer.<br /> <br /> If that alloc_skb() fails, the callback returns 0 even though it has<br /> already consumed bytes, and it leaves recv_skb as NULL for the next<br /> receive callback. That breaks the receive_buf() accounting contract and<br /> can also lead to a NULL dereference on the next skb_put_u8().<br /> <br /> Allocate the receive skb lazily before consuming the next byte instead.<br /> If allocation fails, return the number of bytes already accepted.