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 /> 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 /> 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: hold dev ref until after transport_finish NF_HOOK<br /> <br /> After async crypto completes, xfrm_input_resume() calls dev_put()<br /> immediately on re-entry before the skb reaches transport_finish.<br /> The skb-&gt;dev pointer is then used inside NF_HOOK and its okfn,<br /> which can race with device teardown.<br /> <br /> Remove the dev_put from the async resumption entry and instead<br /> drop the reference after the NF_HOOK call in transport_finish,<br /> using a saved device pointer since NF_HOOK may consume the skb.<br /> This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip<br /> the okfn.<br /> <br /> For non-transport exits (decaps, gro, drop) and secondary<br /> async return points, release the reference inline when<br /> async is set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat<br /> <br /> A use-after-free / refcount underflow is possible when the heartbeat<br /> worker and intel_engine_park_heartbeat() race to release the same<br /> engine-&gt;heartbeat.systole request.<br /> <br /> The heartbeat worker reads engine-&gt;heartbeat.systole and calls<br /> i915_request_put() on it when the request is complete, but clears<br /> the pointer in a separate, non-atomic step. Concurrently, a request<br /> retirement on another CPU can drop the engine wakeref to zero, triggering<br /> __engine_park() -&gt; intel_engine_park_heartbeat(). If the heartbeat<br /> timer is pending at that point, cancel_delayed_work() returns true and<br /> intel_engine_park_heartbeat() reads the stale non-NULL systole pointer<br /> and calls i915_request_put() on it again, causing a refcount underflow:<br /> <br /> ```<br /> [487.221889] Workqueue: i915-unordered engine_retire [i915]<br /> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0<br /> ...<br /> [487.222707] Call Trace:<br /> [487.222711] <br /> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915]<br /> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915]<br /> [487.223566] __engine_park+0xb9/0x650 [i915]<br /> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915]<br /> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915]<br /> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915]<br /> [487.225238] intel_context_exit+0xf1/0x1b0 [i915]<br /> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915]<br /> [487.226178] i915_request_retire+0x1c/0x40 [i915]<br /> [487.226625] engine_retire+0x122/0x180 [i915]<br /> [487.227037] process_one_work+0x239/0x760<br /> [487.227060] worker_thread+0x200/0x3f0<br /> [487.227068] ? __pfx_worker_thread+0x10/0x10<br /> [487.227075] kthread+0x10d/0x150<br /> [487.227083] ? __pfx_kthread+0x10/0x10<br /> [487.227092] ret_from_fork+0x3d4/0x480<br /> [487.227099] ? __pfx_kthread+0x10/0x10<br /> [487.227107] ret_from_fork_asm+0x1a/0x30<br /> [487.227141] <br /> ```<br /> <br /> Fix this by replacing the non-atomic pointer read + separate clear with<br /> xchg() in both racing paths. xchg() is a single indivisible hardware<br /> instruction that atomically reads the old pointer and writes NULL. This<br /> guarantees only one of the two concurrent callers obtains the non-NULL<br /> pointer and performs the put, the other gets NULL and skips it.<br /> <br /> (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: hold claim backbone gateways by reference<br /> <br /> batadv_bla_add_claim() can replace claim-&gt;backbone_gw and drop the old<br /> gateway&amp;#39;s last reference while readers still follow the pointer.<br /> <br /> The netlink claim dump path dereferences claim-&gt;backbone_gw-&gt;orig and<br /> takes claim-&gt;backbone_gw-&gt;crc_lock without pinning the underlying<br /> backbone gateway. batadv_bla_check_claim() still has the same naked<br /> pointer access pattern.<br /> <br /> Reuse batadv_bla_claim_get_backbone_gw() in both readers so they operate<br /> on a stable gateway reference until the read-side work is complete.<br /> This keeps the dump and claim-check paths aligned with the lifetime<br /> rules introduced for the other BLA claim readers.