Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: shaper: reject duplicate leaves in GROUP request<br /> <br /> net_shaper_nl_group_doit() does not deduplicate NET_SHAPER_A_LEAVES<br /> entries. When userspace supplies the same leaf handle twice, the same<br /> old-parent pointer lands twice in old_nodes[]. The cleanup loop double<br /> frees the parent. Of course the same parent may still be in old_nodes[]<br /> twice if we are moving multiple of its leaves.<br /> <br /> Note that this patch also implicitly fixes the fact that the<br /> i &gt;= leaves_count path forgets to set ret.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: cortina: Carry over frag counter<br /> <br /> The gmac_rx() NAPI poll function assembles packets in an<br /> SKB from a ring buffer.<br /> <br /> If the ring buffer gets completely emptied during a poll cycle,<br /> we exit gmac_rx(), but the packet is not yet completely<br /> assembled in the SKB, yet the fragment counter frag_nr is<br /> reset to zero on the next invocation.<br /> <br /> Solve this by making the RX fragment counter a part of the<br /> port struct, and carry it over between invocations.<br /> <br /> Reset the fragment counter only right after calling<br /> napi_gro_frags(), on error (after calling napi_free_frags())<br /> or if stopping the port.<br /> <br /> Reset it in some place where not strictly necessary just to<br /> emphasize what is going on.<br /> <br /> This was found by Sashiko during normal patch review.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (lm90) Stop work before releasing hwmon device<br /> <br /> Sashiko reports:<br /> <br /> In lm90_probe(), the devm action to cancel the alert_work and report_work<br /> (lm90_restore_conf) is registered in lm90_init_client() before<br /> devm_hwmon_device_register_with_info() is called.<br /> <br /> Because devm executes cleanup actions in reverse order during module<br /> unbind or probe failure, the hwmon device is unregistered and freed first.<br /> <br /> If lm90_alert_work() or lm90_report_alarms() runs in the window between<br /> the hwmon device being freed and the delayed works being cancelled,<br /> lm90_update_alarms() will dereference the freed data-&gt;hwmon_dev here.<br /> <br /> Fix the problem by canceling the workers separately after registering<br /> the hwmon device and before registering the interrupt handler. This ensures<br /> that the workers are canceled after interrupts are disabled and before<br /> the hwmon device is released. Add "shutdown" flag to indicate that device<br /> shutdown is in progress to prevent workers from being re-armed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/snapshot: fix dumping of the unaligned regions<br /> <br /> The snapshotting code internally aligns data segment to 16 bytes. This<br /> works fine for DPU code (where most of the regions are aligned), but<br /> fails for snapshotting of the DSI data (because DSI data region is<br /> shifted by 4 bytes). Fix the code by removing length alignment and by<br /> accurately printing last registers in the region. While reworking the<br /> code also fix the 16x memory overallocation in<br /> msm_disp_state_dump_regs().<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/725449/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cachefiles: Fix error return when vfs_mkdir() fails<br /> <br /> When vfs_mkdir() fails, the error code is not extracted from the<br /> returned error pointer. This causes mkdir_error to be reached with<br /> ret=0, which leads to returning ERR_PTR(0) (NULL) instead of a<br /> proper error pointer.<br /> <br /> Fix this by extracting the error code from the error pointer when<br /> vfs_mkdir() fails.

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