Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmsmac: Fix dma_free_coherent() size<br /> <br /> dma_alloc_consistent() may change the size to align it. The new size is<br /> saved in alloced.<br /> <br /> Change the free size to match the allocation size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG<br /> <br /> The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements<br /> bc_ackers on every inbound group ACK, even when the same member has<br /> already acknowledged the current broadcast round.<br /> <br /> Because bc_ackers is a u16, a duplicate ACK received after the last<br /> legitimate ACK wraps the counter to 65535. Once wrapped,<br /> tipc_group_bc_cong() keeps reporting congestion and later group<br /> broadcasts on the affected socket stay blocked until the group is<br /> recreated.<br /> <br /> Fix this by ignoring duplicate or stale ACKs before touching bc_acked or<br /> bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and<br /> prevents the underflow path.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix PREEMPT_RT raw/bh spinlock nesting for async VC handling<br /> <br /> Switch from using the completion&amp;#39;s raw spinlock to a local lock in the<br /> idpf_vc_xn struct. The conversion is safe because complete/_all() are<br /> called outside the lock and there is no reason to share the completion<br /> lock in the current logic. This avoids invalid wait context reported by<br /> the kernel due to the async handler taking BH spinlock:<br /> <br /> [ 805.726977] =============================<br /> [ 805.726991] [ BUG: Invalid wait context ]<br /> [ 805.727006] 7.0.0-rc2-net-devq-031026+ #28 Tainted: G S OE<br /> [ 805.727026] -----------------------------<br /> [ 805.727038] kworker/u261:0/572 is trying to lock:<br /> [ 805.727051] ff190da6a8dbb6a0 (&amp;vport_config-&gt;mac_filter_list_lock){+...}-{3:3}, at: idpf_mac_filter_async_handler+0xe9/0x260 [idpf]<br /> [ 805.727099] other info that might help us debug this:<br /> [ 805.727111] context-{5:5}<br /> [ 805.727119] 3 locks held by kworker/u261:0/572:<br /> [ 805.727132] #0: ff190da6db3e6148 ((wq_completion)idpf-0000:83:00.0-mbx){+.+.}-{0:0}, at: process_one_work+0x4b5/0x730<br /> [ 805.727163] #1: ff3c6f0a6131fe50 ((work_completion)(&amp;(&amp;adapter-&gt;mbx_task)-&gt;work)){+.+.}-{0:0}, at: process_one_work+0x1e5/0x730<br /> [ 805.727191] #2: ff190da765190020 (&amp;x-&gt;wait#34){+.+.}-{2:2}, at: idpf_recv_mb_msg+0xc8/0x710 [idpf]<br /> [ 805.727218] stack backtrace:<br /> ...<br /> [ 805.727238] Workqueue: idpf-0000:83:00.0-mbx idpf_mbx_task [idpf]<br /> [ 805.727247] Call Trace:<br /> [ 805.727249] <br /> [ 805.727251] dump_stack_lvl+0x77/0xb0<br /> [ 805.727259] __lock_acquire+0xb3b/0x2290<br /> [ 805.727268] ? __irq_work_queue_local+0x59/0x130<br /> [ 805.727275] lock_acquire+0xc6/0x2f0<br /> [ 805.727277] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf]<br /> [ 805.727284] ? _printk+0x5b/0x80<br /> [ 805.727290] _raw_spin_lock_bh+0x38/0x50<br /> [ 805.727298] ? idpf_mac_filter_async_handler+0xe9/0x260 [idpf]<br /> [ 805.727303] idpf_mac_filter_async_handler+0xe9/0x260 [idpf]<br /> [ 805.727310] idpf_recv_mb_msg+0x1c8/0x710 [idpf]<br /> [ 805.727317] process_one_work+0x226/0x730<br /> [ 805.727322] worker_thread+0x19e/0x340<br /> [ 805.727325] ? __pfx_worker_thread+0x10/0x10<br /> [ 805.727328] kthread+0xf4/0x130<br /> [ 805.727333] ? __pfx_kthread+0x10/0x10<br /> [ 805.727336] ret_from_fork+0x32c/0x410<br /> [ 805.727345] ? __pfx_kthread+0x10/0x10<br /> [ 805.727347] ret_from_fork_asm+0x1a/0x30<br /> [ 805.727354]