Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: fs210x: fix possible buffer overflow<br /> <br /> In fs210x_effect_scene_info(), a string was copied like this:<br /> <br /> strscpy(DST, SRC, strlen(SRC) + 1);<br /> <br /> A buffer overflow would happen if strlen(SRC) &gt;= sizeof(DST).<br /> Actually, strscpy() must be used this way:<br /> <br /> strscpy(DST, SRC, sizeof(DST));<br /> strscpy(DST, SRC); // defaults to sizeof(DST)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: Check BAR resources before exporting a DMABUF<br /> <br /> A DMABUF exports access to BAR resources and, although they are<br /> requested at startup time, we need to ensure they really were reserved<br /> before exporting. Otherwise, it&amp;#39;s possible to access unreserved<br /> resources through the export.<br /> <br /> Add a check to the DMABUF-creation path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: fix race between deleting interface and adding new peer<br /> <br /> While deleting an existing ovpn interface, there is a very<br /> narrow window where adding a new peer via netlink may cause<br /> the netdevice to hang and prevent its unregistration.<br /> <br /> It may happen during ovpn_dellink(), when all existing peers are<br /> freed and the device is queued for deregistration, but a<br /> CMD_PEER_NEW message comes in adding a new peer that takes again<br /> a reference to the netdev.<br /> <br /> At this point there is no way to release the device because we are<br /> under the assumption that all peers were already released.<br /> <br /> Fix the race condition by releasing all peers in ndo_uninit(),<br /> when the netdevice has already been removed from the netdev<br /> list.<br /> <br /> Also ovpn_peer_add() has now an extra check that forces the<br /> function to bail out if the device reg_state is not REGISTERED.<br /> This way any incoming CMD_PEER_NEW racing with the interface<br /> deletion routine will simply stop before adding the peer.<br /> <br /> Note that the above check happens while holding the netdev_lock<br /> to prevent racing netdev state changes.<br /> <br /> ovpn_dellink() is now empty and can be removed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: respect peer refcount in CMD_NEW_PEER error path<br /> <br /> ovpn_nl_peer_new_doit()&amp;#39;s error path calls ovpn_peer_release() directly<br /> rather than ovpn_peer_put(), bypassing the kref. The accompanying<br /> comment ("peer was not yet hashed, thus it is not used in any context")<br /> holds for UDP but not for TCP.<br /> <br /> For UDP, the ovpn_socket union uses the .ovpn arm and never points back<br /> at a peer; UDP encap_recv looks up peers via the not-yet-populated<br /> hashtables, so the new peer is unreachable until ovpn_peer_add()<br /> publishes it.<br /> <br /> For TCP, ovpn_socket_new() sets ovpn_sock-&gt;peer and<br /> ovpn_tcp_socket_attach() publishes ovpn_sock via rcu_assign_sk_user_data().<br /> From that moment until ovpn_socket_release() detaches in the error path,<br /> the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll<br /> on the fd, as well as the strparser-driven ovpn_tcp_rcv() path, can<br /> reach the peer through sk_user_data -&gt; ovpn_sock-&gt;peer and bump its<br /> refcount via ovpn_peer_hold().<br /> <br /> ovpn_tcp_socket_wait_finish() (called inside ovpn_socket_release())<br /> drains strparser and the tx work, but does not synchronize with<br /> userspace syscall callers that already hold a peer reference. If<br /> ovpn_nl_peer_modify() or ovpn_peer_add() returns an error while such<br /> a caller is in flight - notably an ovpn_tcp_recvmsg() blocked in<br /> __skb_recv_datagram() on peer-&gt;tcp.user_queue - the direct<br /> ovpn_peer_release() destroys the peer while the caller still holds<br /> the reference, and the eventual ovpn_peer_put() from that caller<br /> operates on freed memory.<br /> <br /> Replace the direct destructor call with ovpn_peer_put() so the kref<br /> correctly defers destruction until the last reference is dropped.<br /> In the common case where no concurrent user is present, behaviour is<br /> unchanged: the kref hits zero immediately and ovpn_peer_release_kref()<br /> runs the same destructor.<br /> <br /> With this conversion ovpn_peer_release() has no callers outside peer.c<br /> - ovpn_peer_release_kref() in the same translation unit is the only<br /> remaining user - so make it static and drop its declaration from<br /> peer.h.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: tcp - use cached peer pointer in ovpn_tcp_close()<br /> <br /> ovpn_tcp_close() loads the ovpn_socket via rcu_dereference_sk_user_data()<br /> under rcu_read_lock(), takes a reference on sock-&gt;peer, caches the peer<br /> pointer in a local, and drops the read lock. It then passes sock-&gt;peer<br /> (rather than the cached local) to ovpn_peer_del(), re-dereferencing the<br /> ovpn_socket after the RCU read section has ended.<br /> <br /> Unlike ovpn_tcp_sendmsg(), which uses the same "load under RCU, use<br /> after unlock" pattern but is protected by lock_sock() held across the<br /> function, ovpn_tcp_close() runs without the socket lock: inet_release()<br /> invokes sk_prot-&gt;close() without taking lock_sock first.<br /> <br /> ovpn_socket_release() can therefore complete its kref_put -&gt; detach -&gt;<br /> synchronize_rcu -&gt; kfree(sock) sequence concurrently, in the window<br /> after ovpn_tcp_close() drops rcu_read_lock() but before it dereferences<br /> sock-&gt;peer. The synchronize_rcu() in ovpn_socket_release() protects<br /> readers that use the dereferenced pointer inside the RCU read section,<br /> not those that escape the pointer to a local and use it afterwards.<br /> <br /> A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp -<br /> don&amp;#39;t deref NULL sk_socket member after tcp_close()"): trigger a peer<br /> removal (keepalive expiration or netlink OVPN_CMD_DEL_PEER) at the same<br /> moment userspace closes the TCP fd. That commit fixed the detach-side<br /> of the same race window; this one fixes the close-side at a different<br /> victim.<br /> <br /> Tighten the entry block to read sock-&gt;peer exactly once into the cached<br /> peer local, and route all subsequent uses (the hold check, the<br /> ovpn_peer_del() call, and the prot-&gt;close() invocation) through that<br /> local. sock-&gt;peer is only ever written once in ovpn_socket_new() under<br /> lock_sock(), before rcu_assign_sk_user_data() publishes the ovpn_socket,<br /> and is never reassigned afterwards - but the previous multi-read pattern<br /> made that invariant implicit rather than explicit. The same multi-read<br /> shape exists in ovpn_tcp_recvmsg(), ovpn_tcp_sendmsg(),<br /> ovpn_tcp_data_ready() and ovpn_tcp_write_space(); those will be cleaned<br /> up via a dedicated helper in a follow-up net-next series.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tls: prevent chain-after-chain in plain text SG<br /> <br /> Sashiko points out that if end = 0 (start != 0) the current<br /> code will create a chain link to content type right after<br /> the wrap link:<br /> <br /> This would create a chain where the wrap link points directly<br /> to another chain link. The scatterlist API sg_next iterator<br /> does not recursively resolve consecutive chain links.<br /> <br /> meaning this is illegal input to crypto.<br /> <br /> The wrapping link is unnecessary if end = 0. end is the entry after<br /> the last one used so end = 0 means there&amp;#39;s nothing pushed after<br /> the wrap:<br /> <br /> end start i<br /> v v v<br /> [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]<br /> <br /> Skip the wrapping in this case.<br /> <br /> TLS 1.3 can use the "wrapping slot" for it&amp;#39;s chaining if end = 0.<br /> This avoids the chain-after-chain.<br /> <br /> Move the wrap chaining before marking END and chaining off content<br /> type, that feels like more logical ordering to me, but should not<br /> matter from functional perspective.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: bounds-check link_id in ieee80211_ml_epcs<br /> <br /> IEEE80211_MLE_STA_EPCS_CONTROL_LINK_ID is 0x000f, so link_id extracted<br /> from a PRIO_ACCESS ML element PER_STA_PROFILE subelement can be 0..15.<br /> sdata-&gt;link[] has IEEE80211_MLD_MAX_NUM_LINKS (15) entries (indices 0..14),<br /> making index 15 out-of-bounds.<br /> <br /> A connected WiFi 7 AP can trigger this by sending an EPCS Enable Response<br /> action frame with a PER_STA_PROFILE subelement where link_id = 15. The<br /> unsolicited-notification path (dialog_token = 0) is reachable any time<br /> EPCS is already enabled, without any prior client request.<br /> <br /> sdata-&gt;link[15] reads into the first word of sdata-&gt;activate_links_work<br /> (a wiphy_work whose embedded list_head is non-NULL after INIT_LIST_HEAD),<br /> so the NULL check on the result does not catch the invalid access. The<br /> garbage pointer is then passed to ieee80211_sta_wmm_params(), which<br /> dereferences link-&gt;sdata and crashes the kernel.<br /> <br /> The same class of bug was fixed for ieee80211_ml_reconfiguration() by<br /> commit 162d331d833d ("wifi: mac80211: bounds-check link_id in<br /> ieee80211_ml_reconfiguration").

*** 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.