Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix shrinker deadlock<br /> <br /> With PROVE_LOCKING on an Snapdragon X1 and VM reclaim pressure, we see:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 7.0.0-debug+ #43 Tainted: G W<br /> ------------------------------------------------------<br /> kswapd0/82 is trying to acquire lock:<br /> ffff800080ec3870 (reservation_ww_class_acquire){+.+.}-{0:0}, at: msm_gem_shrinker_scan+0x17c/0x400 [msm]<br /> <br /> but task is already holding lock:<br /> ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> __lock_acquire+0x4d0/0xad0<br /> lock_acquire.part.0+0xc4/0x248<br /> lock_acquire+0x8c/0x248<br /> fs_reclaim_acquire+0xd0/0xf0<br /> dma_resv_lockdep+0x224/0x348<br /> do_one_initcall+0x84/0x5d0<br /> do_initcalls+0x194/0x1d8<br /> kernel_init_freeable+0x128/0x180<br /> kernel_init+0x2c/0x160<br /> ret_from_fork+0x10/0x20<br /> <br /> -&gt; #1 (reservation_ww_class_mutex){+.+.}-{4:4}:<br /> __lock_acquire+0x4d0/0xad0<br /> lock_acquire.part.0+0xc4/0x248<br /> lock_acquire+0x8c/0x248<br /> dma_resv_lockdep+0x1a8/0x348<br /> do_one_initcall+0x84/0x5d0<br /> do_initcalls+0x194/0x1d8<br /> kernel_init_freeable+0x128/0x180<br /> kernel_init+0x2c/0x160<br /> ret_from_fork+0x10/0x20<br /> <br /> -&gt; #0 (reservation_ww_class_acquire){+.+.}-{0:0}:<br /> check_prev_add+0x114/0x790<br /> validate_chain+0x594/0x6f0<br /> __lock_acquire+0x4d0/0xad0<br /> lock_acquire.part.0+0xc4/0x248<br /> lock_acquire+0x8c/0x248<br /> drm_gem_lru_scan+0x1ac/0x440<br /> msm_gem_shrinker_scan+0x17c/0x400 [msm]<br /> do_shrink_slab+0x150/0x4a0<br /> shrink_slab+0x144/0x460<br /> shrink_one+0x9c/0x1b0<br /> shrink_many+0x27c/0x5c0<br /> shrink_node+0x344/0x550<br /> balance_pgdat+0x2c0/0x988<br /> kswapd+0x11c/0x318<br /> kthread+0x10c/0x128<br /> ret_from_fork+0x10/0x20<br /> <br /> other info that might help us debug this:<br /> Chain exists of:<br /> reservation_ww_class_acquire --&gt; reservation_ww_class_mutex --&gt; fs_reclaim<br /> Possible unsafe locking scenario:<br /> CPU0 CPU1<br /> ---- ----<br /> lock(fs_reclaim);<br /> lock(reservation_ww_class_mutex);<br /> lock(fs_reclaim);<br /> lock(reservation_ww_class_acquire);<br /> <br /> *** DEADLOCK ***<br /> 1 lock held by kswapd0/82:<br /> #0: ffffc31709b263b8 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x88/0x988<br /> <br /> stack backtrace:<br /> CPU: 4 UID: 0 PID: 82 Comm: kswapd0 Tainted: G W 7.0.0-debug+ #43 PREEMPT(full)<br /> Tainted: [W]=WARN<br /> Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET94W (1.66 ) 09/15/2025<br /> Call trace:<br /> show_stack+0x20/0x40 (C)<br /> dump_stack_lvl+0x9c/0xd0<br /> dump_stack+0x18/0x30<br /> print_circular_bug+0x114/0x120<br /> check_noncircular+0x178/0x198<br /> check_prev_add+0x114/0x790<br /> validate_chain+0x594/0x6f0<br /> __lock_acquire+0x4d0/0xad0<br /> lock_acquire.part.0+0xc4/0x248<br /> lock_acquire+0x8c/0x248<br /> drm_gem_lru_scan+0x1ac/0x440<br /> msm_gem_shrinker_scan+0x17c/0x400 [msm]<br /> do_shrink_slab+0x150/0x4a0<br /> shrink_slab+0x144/0x460<br /> shrink_one+0x9c/0x1b0<br /> shrink_many+0x27c/0x5c0<br /> shrink_node+0x344/0x550<br /> balance_pgdat+0x2c0/0x988<br /> kswapd+0x11c/0x318<br /> kthread+0x10c/0x128<br /> ret_from_fork+0x10/0x20<br /> <br /> kswapd0 holding fs_reclaim calls the MSM shrinker, which calls<br /> dma_resv_lock. This in turn acquires fs_reclaim.<br /> <br /> Fix this deadlock by using dma_resv_trylock() instead, dropping the<br /> subsequently unused passed wait-wound lock &amp;#39;ticket&amp;#39;.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/723564/<br /> [rob: fixup compile errors, replace lockdep splat with somethin<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fwctl: pds: Validate RPC input size before parsing<br /> <br /> The fwctl core allocates the device-specific RPC input buffer with<br /> fwctl_rpc.in_len and passes that buffer to the driver callback.<br /> <br /> pdsfc_fw_rpc() casts the buffer to struct fwctl_rpc_pds and then calls<br /> pdsfc_validate_rpc(), which reads fields from that structure before<br /> checking that the input buffer is large enough to contain it. A short<br /> in_len can make pds_fwctl read beyond the allocation.<br /> <br /> Reject pds RPC buffers that are smaller than struct fwctl_rpc_pds before<br /> parsing any pds-specific fields.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: isci: Fix use-after-free in device removal path<br /> <br /> The ISCI completion tasklet is initialized in isci_host_alloc()<br /> (drivers/scsi/isci/init.c:496) and scheduled from both MSI-X and legacy<br /> interrupt handlers (drivers/scsi/isci/host.c:223,613).<br /> <br /> isci_host_deinit() stops the controller and waits for stop completion,<br /> but it never kills completion_tasklet before teardown continues. A<br /> top-of-function tasklet_kill() is not sufficient here: interrupts are<br /> only disabled when isci_host_stop_complete() runs, so until<br /> wait_for_stop() returns the IRQ handlers can still requeue the<br /> tasklet. The tasklet callback also re-enables interrupts after draining<br /> completions, so killing the tasklet before the source is quiesced leaves<br /> the same race open.<br /> <br /> Once wait_for_stop() returns, no further IRQ-driven scheduling can<br /> occur. Kill completion_tasklet there so teardown cannot race a queued<br /> tasklet running on a dead ihost. On remove or unload, the stale callback<br /> can otherwise dereference ihost and touch ihost-&gt;smu_registers after the<br /> host lifetime ends.<br /> <br /> A UML + KASAN analogue reproduced the failure class both with no<br /> tasklet_kill() and with tasklet_kill() placed before source quiesce, and<br /> stayed clean once the kill happened after quiescing the scheduling<br /> source.<br /> <br /> This mirrors commit f6ab594672d4 ("scsi: aic94xx: fix use-after-free in<br /> device removal path"), but ISCI needs the kill after wait_for_stop().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: vgic: Free private_irqs when init fails after allocation<br /> <br /> Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on<br /> failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy()<br /> call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The<br /> kvm_vgic_vcpu_init() failure path immediately above it has the same<br /> shape and still needs the same cleanup.<br /> <br /> Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private<br /> IRQs allocated before a redistributor iodev registration failure are<br /> released before the failed vCPU is freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Reject MPA FPDU length underflow before signed receive math<br /> <br /> A malicious connected siw peer can send an iWARP FPDU whose MPA length<br /> field (c_hdr-&gt;mpa_len, 16 bit big-endian, peer-controlled) is smaller<br /> than the fixed DDP/RDMAP header for the announced opcode. Soft-iWARP<br /> parses the full header in siw_get_hdr() based on iwarp_pktinfo[opcode]<br /> .hdr_len, but never compares mpa_len against that header length.<br /> <br /> siw_tcp_rx_data() then derives<br /> <br /> srx-&gt;fpdu_part_rem = be16_to_cpu(mpa_len) - fpdu_part_rcvd<br /> + MPA_HDR_SIZE;<br /> <br /> where fpdu_part_rcvd equals iwarp_pktinfo[opcode].hdr_len at this<br /> point. For a tagged WRITE (hdr_len 16, MPA_HDR_SIZE 2) the smallest<br /> on-wire mpa_len of 0 yields fpdu_part_rem = -14, and any mpa_len below<br /> hdr_len - MPA_HDR_SIZE underflows to a negative int.<br /> <br /> The signed value then flows into siw_proc_write()/siw_proc_rresp() as<br /> <br /> bytes = min(srx-&gt;fpdu_part_rem, srx-&gt;skb_new);<br /> <br /> is handed to siw_check_mem() as an int len (whose interval check<br /> addr + len &gt; mem-&gt;va + mem-&gt;len is satisfied for a valid base when<br /> len is negative), and reaches siw_rx_data() -&gt; siw_rx_kva() /<br /> siw_rx_umem() -&gt; skb_copy_bits() as a signed copy length. The header<br /> copy branch in skb_copy_bits() promotes that to size_t, producing a<br /> multi-gigabyte read.<br /> <br /> KASAN under a KUnit harness that drives the real kernel TCP receive<br /> path -- a loopback AF_INET socketpair, the malformed FPDU written via<br /> kernel_sendmsg, sk_data_ready firing in softirq, tcp_read_sock<br /> dispatching to siw_tcp_rx_data -- reports:<br /> <br /> BUG: KASAN: use-after-free in skb_copy_bits+0x284/0x480<br /> Read of size 4294967295 at addr ffff888...<br /> Call Trace:<br /> skb_copy_bits<br /> siw_rx_kva<br /> siw_rx_data<br /> siw_check_mem<br /> siw_proc_write<br /> siw_tcp_rx_data<br /> __tcp_read_sock<br /> siw_qp_llp_data_ready<br /> tcp_data_ready<br /> tcp_data_queue<br /> <br /> Add the missing invariant at the earliest point where the peer header<br /> is fully assembled. iwarp_pktinfo[*].hdr_len - MPA_HDR_SIZE is exactly<br /> the value the siw transmitter uses as the minimum mpa_len for each<br /> opcode (drivers/infiniband/sw/siw/siw_qp.c:33), so this matches the<br /> protocol contract. Out-of-range FPDUs terminate the connection with<br /> TERM_ERROR_LAYER_LLP / LLP_ETYPE_MPA / LLP_ECODE_FPDU_START -- which<br /> is RFC 5044 Section 8 error code 3 ("Marker and ULPDU Length fields<br /> do not agree on the start of an FPDU"), the correct framing-error<br /> class for this inconsistency.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virt: sev-guest: Explicitly leak pages in unknown state<br /> <br /> When set_memory_{encrypted,decrypted}() fail, the user cannot know at which<br /> point the function failed, meaning that the pages are left in an unknown state<br /> from the point of view of the caller.<br /> <br /> Since the pages may be left in an unencrypted state, they are not suitable for<br /> general use, and cannot be returned safely to the buddy allocator. Avoid the<br /> issue by never freeing the pages, and then do the proper accounting by calling<br /> snp_leak_pages().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits<br /> <br /> Userspace can restore an ITS Device Table Entry whose Size field encodes<br /> more EventID bits than the virtual ITS supports. The live MAPD path<br /> rejects that state, but vgic_its_restore_dte() accepts it and stores the<br /> out-of-range value in dev-&gt;num_eventid_bits.<br /> <br /> Reject restored DTEs with num_eventid_bits &gt; VITS_TYPER_IDBITS before<br /> allocating the device. This mirrors the MAPD check and prevents the<br /> restored state from reaching vgic_its_restore_itt(), where the unchecked<br /> value can be converted into an oversized scan_its_table() range.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tp_meter: fix tp_vars reference leak in receiver shutdown<br /> <br /> The receiver shutdown timer handler, batadv_tp_receiver_shutdown(), is<br /> responsible for releasing the tp_vars reference it holds. However, the<br /> existing logic for coordinating this release with batadv_tp_stop_all() was<br /> flawed.<br /> <br /> timer_shutdown_sync() guarantees the timer will not fire again after it<br /> returns, but it returns non-zero only when the timer was pending at the<br /> time of the call. If the timer had already expired (and<br /> batadv_tp_stop_all() would unsucessfully try to rearm itself),<br /> batadv_tp_stop_all() skips its batadv_tp_vars_put(), and<br /> batadv_tp_receiver_shutdown() fails to put its own reference as well.<br /> <br /> Fix this by introducing a new atomic variable receiving that is set to 1<br /> when the receiver is initialized and cleared atomically with atomic_xchg()<br /> by whichever side claims it first. Only the side that observes the<br /> transition from 1 to 0 is responsible for releasing the tp_vars timer<br /> reference, eliminating the uncertainty.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bla: avoid NULL-ptr deref for claim via dropped interface<br /> <br /> Without rtnl_lock held, a hardif might be retrieved as primary interface of<br /> a meshif, but then (while operating on this interface) getting decoupled<br /> from the mesh interface. In this case, the meshif still exists but the<br /> pointer from the primary hardif to the meshif is set to NULL.<br /> <br /> The mesh_iface must be checked first to be non-NULL before continuing to<br /> send an ARP request using meshif.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: tp_meter: directly shut down timer on cleanup<br /> <br /> batadv_tp_sender_cleanup() was calling timer_delete_sync() followed by<br /> timer_delete() to guard against the timer handler re-arming itself between<br /> the two calls. This double-deletion hack relied on the sending status being<br /> set to 0 to suppress re-arming.<br /> <br /> Replace both calls with a single timer_shutdown_sync(). This function both<br /> waits for any running timer callback to complete (like timer_delete_sync())<br /> and permanently disarms the timer so it cannot be re-armed afterwards,<br /> making re-arming prevention unconditional and self-documenting.<br /> <br /> The re-arming property is also required because otherwise:<br /> <br /> 1. context 0 (batadv_tp_recv_ack()) checks in<br /> batadv_tp_reset_sender_timer() if sending is still 1 -&gt; it is<br /> 2. context 1 changes in batadv_tp_sender_shutdown() sending to 0 and in<br /> this process forces the kthread to stop timer in<br /> batadv_tp_sender_cleanup()<br /> 3. context 0 continues in batadv_tp_reset_sender_timer() and rearms the<br /> timer -&gt; but the reference for it is already gone

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: bla: avoid double decrement of bla.num_requests<br /> <br /> The bla.num_requests is increased when no request_sent was in progress. And<br /> it is decremented in various places (announcement was received, backbone is<br /> purged, periodic work). But the check if the request_sent is actually set<br /> to a specific state and the atomic_dec/_inc are not safe because they are<br /> not atomic (TOCTOU) and multiple such code portions can run concurrently.<br /> <br /> At the same time, it is necessary to modify request_sent (state) and<br /> bla.num_requests atomically. Otherwise batadv_bla_send_request() might set<br /> request_sent to 1 and is interrupted. batadv_handle_announce() can then<br /> set request_sent back to 0 and decrement num_requests before<br /> batadv_bla_send_request() incremented it.<br /> <br /> The two operations must therefore be locked. And since state (request_sent)<br /> and wait_periods are only accessed inside this lock, they can be converted<br /> to simpler datatypes. And to avoid that the bla.num_requests is touched by<br /> a parallel running context with a valid backbone_gw reference after<br /> batadv_bla_purge_backbone_gw() ran, a third state "stopped" is required to<br /> correctly signal that a backbone_gw is in the state of being cleaned up.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: mcast: fix use-after-free in orig_node RCU release<br /> <br /> batadv_mcast_purge_orig() removes entries from RCU-protected hlists but<br /> does not wait for an RCU grace period before returning. Concurrent RCU<br /> readers may still accesses references to those entries at the point of<br /> removal. RCU-protected readers trying to operate on entries like<br /> orig-&gt;mcast_want_all_ipv6_node will then access already freed memory.<br /> <br /> Fix this by moving batadv_mcast_purge_orig() to batadv_orig_node_release(),<br /> just before the call_rcu() invocation. This ensures RCU readers that were<br /> active at purge time have drained before the orig_node memory is reclaimed.