Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix managed cache race for unaligned extents<br /> <br /> After unaligned compressed extents were introduced, the following race<br /> could occur:<br /> <br /> [Thread 1] [Thread 2]<br /> (z_erofs_fill_bio_vec)<br /> <br /> ...<br /> filemap_add_folio (1)<br /> (z_erofs_bind_cache)<br /> <br /> ..<br /> ..<br /> folio_attach_private (2)<br /> filemap_add_folio (3) again<br /> <br /> Since (1) is executed but (2) hasn&amp;#39;t been executed yet, it&amp;#39;s possible<br /> that another thread finds the same managed folio in z_erofs_bind_cache()<br /> for a different pcluster and calls filemap_add_folio() again since<br /> folio-&gt;private is still Z_EROFS_PREALLOCATED_FOLIO.<br /> <br /> Fix this by explicitly clearing folio-&gt;private before making the folio<br /> visible in the managed cache so that another pcluster can simply wait<br /> on the locked managed folio as what we did for other shared cases [1].<br /> <br /> This only impacts unaligned data compression (`-E48bit` with zstd,<br /> for example).<br /> <br /> [1] Commit 9e2f9d34dd12 ("erofs: handle overlapped pclusters out of<br /> crafted images properly") was originally introduced to handle crafted<br /> overlapped extents, but it addresses unaligned extents as well.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: mcast: Fix a possible use-after-free when removing a bridge port<br /> <br /> When per-VLAN multicast snooping is enabled, the bridge iterates over<br /> all the bridge ports, disables the per-port multicast context on each<br /> port and enables the per-{port, VLAN} multicast contexts instead. The<br /> reverse happens when per-VLAN multicast snooping is disabled.<br /> <br /> When global multicast snooping is enabled, the bridge iterates over all<br /> the bridge ports and enables the per-port multicast context on each<br /> port. The reverse happens when multicast snooping is disabled.<br /> <br /> The above scheme can result in a situation where both types of contexts<br /> (per-port and per-{port, VLAN}) are enabled on a single bridge port:<br /> <br /> # ip link add name br1 up type bridge mcast_snooping 1 mcast_querier 1 vlan_filtering 1<br /> # ip link add name dummy1 up master br1 type dummy<br /> # ip link set dev br1 type bridge mcast_vlan_snooping 1<br /> # ip link set dev br1 type bridge mcast_snooping 0<br /> # ip link set dev br1 type bridge mcast_snooping 1<br /> <br /> This is not intended and it is a problem since the commit cited below.<br /> Prior to this commit, when removing a bridge port,<br /> br_multicast_disable_port() would disable the per-port multicast context<br /> and the per-{port, VLAN} multicast contexts would get disabled when<br /> flushing VLANs.<br /> <br /> After this commit, br_multicast_disable_port() only disables the<br /> per-port multicast context if per-VLAN multicast snooping is disabled.<br /> If both types of contexts were enabled on the port when it was removed,<br /> the per-port multicast context would remain enabled when freeing the<br /> bridge port, leading to a use-after-free [1].<br /> <br /> Fix by preventing the bridge from enabling / disabling the per-port<br /> multicast contexts when toggling global multicast snooping if per-VLAN<br /> multicast snooping is enabled.<br /> <br /> [1]<br /> ODEBUG: free active (active state 0) object: ffff88810f8bda78 object type: timer_list hint: br_ip6_multicast_port_query_expired (net/bridge/br_multicast.c:1927)<br /> WARNING: lib/debugobjects.c:629 at debug_print_object+0x1b1/0x3e0, CPU#5: swapper/5/0<br /> [...]<br /> Call Trace:<br /> <br /> __debug_check_no_obj_freed (lib/debugobjects.c:1116)<br /> kfree (mm/slub.c:2620 mm/slub.c:6250 mm/slub.c:6565)<br /> kobject_cleanup (lib/kobject.c:689)<br /> rcu_do_batch (kernel/rcu/tree.c:2617)<br /> rcu_core (kernel/rcu/tree.c:2869)<br /> handle_softirqs (kernel/softirq.c:622)<br /> __irq_exit_rcu (kernel/softirq.c:656 kernel/softirq.c:496 kernel/softirq.c:735)<br /> irq_exit_rcu (kernel/softirq.c:752)<br /> sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1061 (discriminator 47) arch/x86/kernel/apic/apic.c:1061 (discriminator 47))<br />

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rtrs: Fix use-after-free in path file creation cleanup<br /> <br /> In the error path of rtrs_srv_create_path_files(), the sysfs root folders<br /> may already have been created and srv_path-&gt;kobj may already have been<br /> initialized. If a later step fails, the cleanup currently calls<br /> kobject_put(&amp;srv_path-&gt;kobj) before<br /> rtrs_srv_destroy_once_sysfs_root_folders(srv_path).<br /> <br /> kobject_put() may drop the last reference to srv_path-&gt;kobj and invoke the<br /> release callback, rtrs_srv_release(), which frees srv_path. The following<br /> call to rtrs_srv_destroy_once_sysfs_root_folders(srv_path) then<br /> dereferences srv_path internally to access srv_path-&gt;srv, resulting in a<br /> use-after-free.<br /> <br /> This failure path is reached before rtrs_srv_create_path_files() returns<br /> success, so the successful-path lifetime handling is not involved.<br /> <br /> Fix this by destroying the sysfs root folders before calling<br /> kobject_put(&amp;srv_path-&gt;kobj), so srv_path is still valid while the helper<br /> accesses it.<br /> <br /> This issue was found by a static analysis tool I am developing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: mana: Fix TOCTOU double-fetch of hwc_msg_id from DMA buffer<br /> <br /> In mana_hwc_rx_event_handler(), resp-&gt;response.hwc_msg_id is read from<br /> DMA-coherent memory and bounds-checked, then mana_hwc_handle_resp()<br /> re-reads the same field from the same DMA buffer for test_bit() and<br /> pointer arithmetic.<br /> <br /> DMA-coherent memory is mapped uncacheable on x86 and is shared,<br /> unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes<br /> directly to host-visible memory. A H/W can modify the value<br /> between the check and the use, bypassing the bounds validation.<br /> <br /> Fix this by reading hwc_msg_id exactly once using READ_ONCE() into a<br /> stack-local variable in mana_hwc_rx_event_handler(), and passing the<br /> validated value as a parameter to mana_hwc_handle_resp().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: set tx buffer type for SMD frames<br /> <br /> Sashiko pointed out that igc_fpe_init_smd_frame() initializes<br /> igc_tx_buffer fields for an SMD skb, but does not set the buffer type:<br /> https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp<br /> <br /> Since igc_tx_buffer entries are reused, a stale XDP or XSK type can<br /> remain and make TX completion use the wrong cleanup path.<br /> <br /> Set the buffer type to IGC_TX_BUFFER_TYPE_SKB.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup/rstat: validate cpu before css_rstat_cpu() access<br /> <br /> css_rstat_updated() is exposed as a BPF kfunc and accepts a<br /> caller-provided cpu argument. The function uses cpu for per-cpu rstat<br /> lookups without checking whether it refers to a valid possible CPU.<br /> <br /> A BPF iter/cgroup program with CAP_BPF and CAP_PERFMON can pass an<br /> invalid cpu value. On an unfixed UBSCAN_BOUNDS test kernel, cpu ==<br /> 0x7fffffff triggers:<br /> <br /> UBSAN: array-index-out-of-bounds in kernel/cgroup/rstat.c:31:9<br /> index 2147483647 is out of range for type &amp;#39;long unsigned int [64]&amp;#39;<br /> Call Trace:<br /> css_rstat_updated<br /> bpf_iter_run_prog<br /> cgroup_iter_seq_show<br /> bpf_seq_read<br /> <br /> Add cpu validation to the BPF-facing css_rstat_updated() kfunc and<br /> move the common implementation to __css_rstat_updated() for in-kernel<br /> callers.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled<br /> <br /> When the TLC notification disables AMSDU for a TID, the MLD driver sets<br /> max_tid_amsdu_len to the sentinel value 1. The TSO segmentation path in<br /> iwl_mld_tx_tso_segment() checks for zero but not for this sentinel,<br /> allowing it to reach the num_subframes calculation:<br /> <br /> num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad)<br /> = (1 + 2) / (1534 + 2) = 0<br /> <br /> This zero propagates to iwl_tx_tso_segment() which sets:<br /> <br /> gso_size = num_subframes * mss = 0<br /> <br /> Calling skb_gso_segment() with gso_size=0 creates over 32000 tiny<br /> segments from a single GSO skb. This floods the TX ring with ~1024<br /> micro-frames (the rest are purged), creating a massive burst of TX<br /> completion events that can lead to memory corruption and a subsequent<br /> use-after-free in TCP&amp;#39;s retransmit queue (refcount underflow in<br /> tcp_shifted_skb, NULL deref in tcp_rack_detect_loss).<br /> <br /> The MVM driver is immune because it checks mvmsta-&gt;amsdu_enabled before<br /> reaching the num_subframes calculation. The MLD driver has no equivalent<br /> bitmap check and relies solely on max_tid_amsdu_len, which does not<br /> catch the sentinel value.<br /> <br /> Fix this by detecting the sentinel value (max_tid_amsdu_len == 1) at the<br /> existing check and falling back to non-AMSDU TSO segmentation. Also add<br /> a WARN_ON_ONCE guard after the num_subframes division as defense-in-depth<br /> to catch any future code paths that produce zero through a different<br /> mechanism.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix dma_vecs leak on p2p memory<br /> <br /> We don&amp;#39;t unmap P2P memory, so we don&amp;#39;t need to track it. The dma_vec<br /> allocation was getting leaked on the completion.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/oa: Fix exec_queue leak on width check in stream open<br /> <br /> In xe_oa_stream_open_ioctl(), when param.exec_q-&gt;width &gt; 1 the<br /> function returns -EOPNOTSUPP directly, skipping the existing<br /> err_exec_q cleanup path. The exec_queue reference obtained by<br /> xe_exec_queue_lookup() is leaked.<br /> <br /> The exec queue holds a reference on the xe_file, which is only<br /> dropped during queue teardown. The leaked lookup ref is not on<br /> the file&amp;#39;s exec_queue xarray, so file close cannot release it.<br /> This keeps both the exec queue and the file private state pinned<br /> indefinitely.<br /> <br /> Jump to err_exec_q instead of returning directly so the reference<br /> is released.<br /> <br /> (cherry picked from commit 339fa0be9e4a5d69fa47e91f4a36574224fb478f)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: aggregator: remove the software node when deactivating the aggregator<br /> <br /> The dynamic software node we create for the aggregator platform device<br /> when using configfs is leaked when the device is deactivated. Destroy it<br /> as the last step in the tear-down path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: aggregator: fix a potential use-after-free<br /> <br /> On error we free aggr-&gt;lookups-&gt;dev_id before removing the entry from<br /> the lookup table. If a concurrent thread calls gpiod_find() before we<br /> remove the entry, it could iterate over the list and call<br /> gpiod_match_lookup_table() which unconditionally dereferences dev_id<br /> when calling strcmp(). Reverse the order of cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix stale per-CPU tcp_tw_isn leak enabling ISN prediction<br /> <br /> Blamed commit moved the TIME_WAIT-derived ISN from the skb control<br /> block to a per-CPU variable, assuming the value would always be consumed<br /> by tcp_conn_request() for the same packet that wrote it. That assumption<br /> is violated by multiple drop paths between the producer<br /> (__this_cpu_write(tcp_tw_isn, isn) in tcp_v{4,6}_rcv()) and the consumer<br /> (tcp_conn_request()):<br /> <br /> - min_ttl / min_hopcount check<br /> - xfrm policy check<br /> - tcp_inbound_hash() MD5/AO mismatch<br /> - tcp_filter() eBPF/SO_ATTACH_FILTER drop<br /> - th-&gt;syn &amp;&amp; th-&gt;fin discard in tcp_rcv_state_process() TCP_LISTEN<br /> - psp_sk_rx_policy_check() in tcp_v{4,6}_do_rcv()<br /> - tcp_checksum_complete() in tcp_v{4,6}_do_rcv()<br /> - tcp_v{4,6}_cookie_check() returning NULL<br /> <br /> When a packet is dropped on any of these paths, tcp_tw_isn is left set.<br /> <br /> The next SYN processed on the same CPU then consumes the non zero value in<br /> tcp_conn_request(), receiving a potentially predictable ISN.<br /> <br /> This patch moves back tcp_tw_isn to skb-&gt;cb[], getting rid of the per-cpu<br /> variable.<br /> <br /> Note that tcp_v{4,6}_fill_cb() do not set it.<br /> <br /> Very litle impact on overall code size/complexity:<br /> <br /> $ scripts/bloat-o-meter -t vmlinux.old vmlinux.new<br /> add/remove: 0/0 grow/shrink: 2/1 up/down: 8/-15 (-7)<br /> Function old new delta<br /> tcp_v6_rcv 3038 3042 +4<br /> tcp_v4_rcv 3035 3039 +4<br /> tcp_conn_request 2938 2923 -15<br /> Total: Before=24436060, After=24436053, chg -0.00%