Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sysfs: don&amp;#39;t remove existing directory on update failure<br /> <br /> When sysfs_update_group() is called for a named group and create_files()<br /> fails (e.g. -ENOMEM), internal_create_group() calls kernfs_remove(kn) on<br /> the group directory. In the update path, kn was obtained via<br /> kernfs_find_and_get() and refers to a directory that already existed<br /> before this call. Removing it silently destroys a sysfs group that the<br /> caller did not create.<br /> <br /> Only remove the directory if we created it ourselves. On update failure<br /> the directory remains as it is left empty by remove_files() inside<br /> create_files(), but can be repopulated by a retry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: ep93xx: fix error pointer deref after DMA setup failure<br /> <br /> The driver falls back to PIO mode if DMA setup fails during probe.<br /> <br /> Make sure to the clear the DMA channel pointers on setup failure to<br /> avoid dereferencing an error pointer on later probe errors or driver<br /> unbind.<br /> <br /> This issue was flagged by Sashiko when reviewing a devres allocation<br /> conversion patch.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: qup: fix error pointer deref after DMA setup failure<br /> <br /> The driver falls back to PIO mode if DMA setup fails during probe.<br /> <br /> Make sure to the clear the DMA channel pointers on setup failure to<br /> avoid dereferencing an error pointer (or attempting to release a channel<br /> a second time) on later probe errors or driver unbind.<br /> <br /> This issue was flagged by Sashiko when reviewing a devres allocation<br /> conversion patch.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: tegra: fix pm_runtime leak on mutex_lock failure<br /> <br /> If tegra_i2c_mutex_lock() fails, the function returns without calling<br /> pm_runtime_put(), leaking the runtime PM reference acquired by the<br /> preceding pm_runtime_get_sync(). This prevents the device from ever<br /> entering runtime suspend.<br /> <br /> Add the missing pm_runtime_put() before returning on lock failure.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Disable AVIC IPI virtualization on Hygon Family 18h (erratum #1235)<br /> <br /> Hygon Family 18h CPUs are derived from AMD Family 17h (Zen1) silicon and<br /> share the same erratum #1235: hardware may read a stale IsRunning=1 bit<br /> during ICR write emulation and silently fail to generate an<br /> AVIC_IPI_FAILURE_TARGET_NOT_RUNNING VM-Exit on the sending vCPU.<br /> <br /> The absence of the VM-Exit causes KVM to miss the required wakeup of<br /> blocking target vCPUs, leading to hung vCPUs and unbounded delays in<br /> guest execution.<br /> <br /> Extend the existing AMD Family 17h erratum #1235 workaround to also cover<br /> Hygon Family 18h. With IPI virtualization disabled, KVM never sets<br /> IsRunning=1 in the Physical ID table, so every non-self IPI generates a<br /> VM-Exit and is correctly emulated.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Do not call map-&gt;ops-&gt;elt_free() if elt_alloc() fails<br /> <br /> In paths where tracing_map_elt_alloc() failed to allocate objects,<br /> the map-&gt;ops-&gt;elt_alloc() call was never successful. In this case,<br /> map-&gt;ops-&gt;elt_free() should not be called.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: advance loop vars in cfg80211_merge_profile()<br /> <br /> cfg80211_merge_profile() reassembles a Multi-BSSID non-transmitted BSS<br /> profile that has been split across multiple consecutive MBSSID elements.<br /> Its while-loop calls<br /> <br /> cfg80211_get_profile_continuation(ie, ielen, mbssid_elem, sub_elem)<br /> <br /> but never advances mbssid_elem or sub_elem inside the body. Each<br /> iteration therefore searches for a continuation that follows the same<br /> fixed pair; the helper returns the same next_mbssid; and the same<br /> next_sub bytes are memcpy()&amp;#39;d into merged_ie at a growing offset until<br /> the buffer fills.<br /> <br /> Advance both mbssid_elem and sub_elem to the just-consumed continuation<br /> so the next call to cfg80211_get_profile_continuation() searches for a<br /> further continuation beyond it (or returns NULL when none exists).<br /> <br /> A specially-crafted malicious beacon can take advantage of this bug<br /> to cause the kernel to spend an excessive amount of time in<br /> cfg80211_merge_profile (up to as much as 2ms per beacon received),<br /> which could theoretically be abused in some way.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mld: stop TX during firmware restart<br /> <br /> When iwlwifi firmware crashes (e.g., NMI_INTERRUPT_UNKNOWN on Intel<br /> BE201/Wi-Fi 7), iwl_mld_nic_error() sets mld-&gt;fw_status.in_hw_restart<br /> to true. However, iwl_mld_tx_from_txq() does not check this flag before<br /> dequeuing frames from mac80211 and pushing them to the transport layer.<br /> <br /> Since the firmware is dead, iwl_trans_tx() returns -EIO for each frame,<br /> which then gets freed immediately. Under high-throughput conditions<br /> (e.g., Tailscale UDP traffic or active SSH sessions), this creates a<br /> tight dequeue-send-fail-free loop that wastes CPU cycles and generates<br /> rapid skb allocation churn, leading to memory pressure from slab<br /> fragmentation.<br /> <br /> The RX path already has this guard (iwl_mld_rx_mpdu checks<br /> in_hw_restart at rx.c:1906), and so does the TXQ allocation worker<br /> (iwl_mld_add_txqs_wk at tx.c:156). Add the same guard to<br /> iwl_mld_tx_from_txq() to stop all TX during firmware restart.<br /> <br /> Frames left in mac80211&amp;#39;s TXQs are naturally drained after restart<br /> completes, when queue reallocation triggers iwl_mld_tx_from_txq()<br /> via iwl_mld_add_txq_list(), or when new upper-layer traffic invokes<br /> wake_tx_queue.<br /> <br /> Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on<br /> kernel 6.19.5 where the firmware crashes approximately every 10-15<br /> minutes under Tailscale traffic.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix driver-set TX rates on old devices<br /> <br /> On old devices such as 7265D, rates are still encoded in version 1<br /> format, which doesn&amp;#39;t use the CCK/OFDM rate index (0-3/0-7) but<br /> rather their PLCP value (e.g. 10 for 1 Mbps CCK rate.)<br /> <br /> While introducing v3 rates, I changed the driver from internally<br /> handling v1 rates and converting to v2, to internally handling v3<br /> and converting to v1 or v2 according to the firmware. I accordingly<br /> changed the code in iwl_mvm_mac80211_idx_to_hwrate() to no longer<br /> have different values for different APIs. This was correct.<br /> <br /> However, I later reverted this part of the change, because it was<br /> reported that I had broken beacon rates, causing a FW assert/crash.<br /> This caused TX_CMD rates to be set incorrectly, potentially causing<br /> a warning when reported back from the device as having been used.<br /> <br /> Fix this (hopefully correctly now) by handling beacon rates in the<br /> TX_CMD that&amp;#39;s embedded in the beacon template command separately.<br /> Restore iwl_mvm_mac80211_idx_to_hwrate() to return only the rate<br /> index, not PLCP value, fixing the real TX_CMD.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phonet/pep: disable BH around forwarded sk_receive_skb()<br /> <br /> The networking receive path is usually run from softirq context, but<br /> protocols that take the socket lock may have packets stored in the<br /> backlog and processed later from process context. In that case<br /> release_sock() -&gt; __release_sock() drops the slock with spin_unlock_bh()<br /> and then calls sk-&gt;sk_backlog_rcv() with bottom halves enabled.<br /> <br /> Typical sk_backlog_rcv handlers process the socket whose backlog is<br /> being drained, so the BH state at entry is irrelevant for the slocks<br /> they touch. pep_do_rcv() is different: when the inbound skb targets an<br /> existing PEP pipe, it forwards the skb to a different *child* socket<br /> via sk_receive_skb(). That helper takes the child slock with<br /> bh_lock_sock_nested(), which is just spin_lock_nested() and assumes BH<br /> is already off. The same child slock therefore ends up acquired with<br /> BH on (process path) and with BH off (softirq path):<br /> <br /> process context softirq context<br /> --------------- ---------------<br /> release_sock(listener) __netif_receive_skb()<br /> __release_sock() phonet_rcv()<br /> spin_unlock_bh() __sk_receive_skb(listener)<br /> [BH now ENABLED] [BH already disabled]<br /> sk_backlog_rcv: sk_backlog_rcv:<br /> pep_do_rcv() pep_do_rcv()<br /> sk_receive_skb(child) sk_receive_skb(child)<br /> bh_lock_sock_nested(child) bh_lock_sock_nested(child)<br /> =&gt; SOFTIRQ-ON-W =&gt; IN-SOFTIRQ-W<br /> <br /> Lockdep flags this as inconsistent lock state, and it can become a real<br /> self-deadlock if a softirq on the same CPU tries to receive to the same<br /> child socket while its slock is held in the BH-enabled path:<br /> <br /> WARNING: inconsistent lock state<br /> inconsistent {SOFTIRQ-ON-W} -&gt; {IN-SOFTIRQ-W} usage.<br /> (slock-AF_PHONET/1){+.?.}-{3:3}, at: __sk_receive_skb+0x1cf/0x900<br /> __sk_receive_skb net/core/sock.c:563<br /> sk_receive_skb include/net/sock.h:2022 [inline]<br /> pep_do_rcv net/phonet/pep.c:675<br /> sk_backlog_rcv include/net/sock.h:1190<br /> __release_sock net/core/sock.c:3216<br /> release_sock net/core/sock.c:3815<br /> pep_sock_accept net/phonet/pep.c:879<br /> <br /> Wrap the forwarded sk_receive_skb() in local_bh_disable() /<br /> local_bh_enable() so the child slock is always acquired with BH off.<br /> local_bh_disable() nests safely on the softirq path.<br /> <br /> Discovered via in-house syzkaller fuzzing; the same root cause also<br /> on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c.<br /> Reproduced under KASAN + LOCKDEP + PROVE_LOCKING, reproducer:<br /> https://pastebin.com/A3t8xzCR

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix potential for tearing in -&gt;remote_i_size and -&gt;zero_point<br /> <br /> Fix potential tearing in using -&gt;remote_i_size and -&gt;zero_point by copying<br /> i_size_read() and i_size_write() and using the same seqcount as for i_size.<br /> <br /> We need to make sure that netfslib and the filesystems that use it always<br /> hold i_lock whilst updating any of the sizes to prevent i_size_seqcount<br /> from getting corrupted.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: icssm-prueth: fix eth_ports_node leak in probe<br /> <br /> The error path on of_property_read_u32() failure inside<br /> icssm_prueth_probe() returns without putting eth_ports_node,<br /> which was acquired before the for_each_child_of_node() loop.<br /> <br /> Drop it before returning.