Vulnerabilities

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.

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.

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.

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.

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.

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

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: integrator: Fix early initialization<br /> <br /> Starting with commit bdb249fce9ad4 ("ARM: integrator: read counter using<br /> syscon/regmap"), intcp_init_early calls syscon_regmap_lookup_by_compatible<br /> which in turn calls of_syscon_register. This function allocates memory.<br /> Since the memory management code has not been initialized at that time,<br /> the call always fails. It either returns -ENOMEM or crashes as follows.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000c when read<br /> [0000000c] *pgd=00000000<br /> Internal error: Oops: 5 [#1] ARM<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.15.0-rc5-00026-g5fcc9bf84ee5 #1 PREEMPT<br /> Hardware name: ARM Integrator/CP (Device Tree)<br /> PC is at __kmalloc_cache_noprof+0xec/0x39c<br /> LR is at __kmalloc_cache_noprof+0x34/0x39c<br /> ...<br /> Call trace:<br /> __kmalloc_cache_noprof from of_syscon_register+0x7c/0x310<br /> of_syscon_register from device_node_get_regmap+0xa4/0xb0<br /> device_node_get_regmap from intcp_init_early+0xc/0x40<br /> intcp_init_early from start_kernel+0x60/0x688<br /> start_kernel from 0x0<br /> <br /> The crash is seen due to a dereferenced pointer which is not supposed to be<br /> NULL but is NULL if the memory management subsystem has not been<br /> initialized. The crash is not seen with all versions of gcc. Some versions<br /> such as gcc 9.x apparently do not dereference the pointer, presumably if<br /> tracing is disabled. The problem has been reproduced with gcc 10.x, 11.x,<br /> and 13.x. Either case, if the crash is not seen, the call to<br /> syscon_regmap_lookup_by_compatible returns -ENOMEM, and<br /> sched_clock_register is never called.<br /> <br /> Fix the problem by moving the early initialization code into the standard<br /> machine initialization code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_ffa: Check for NULL FF-A ID table while driver registration<br /> <br /> The bus match callback assumes that every FF-A driver provides an<br /> id_table and dereferences it unconditionally. Enforce that contract at<br /> registration time so a buggy client driver cannot crash the bus during<br /> match.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kho: skip KHO for crash kernel<br /> <br /> kho_fill_kimage() unconditionally populates the kimage with KHO<br /> metadata for every kexec image type. When the image is a crash kernel,<br /> this can be problematic as the crash kernel can run in a small reserved<br /> region and the KHO scratch areas can sit outside it.<br /> The crash kernel then faults during kho_memory_init() when it<br /> tries phys_to_virt() on the KHO FDT address:<br /> <br /> Unable to handle kernel paging request at virtual address xxxxxxxx<br /> ...<br /> fdt_offset_ptr+...<br /> fdt_check_node_offset_+...<br /> fdt_first_property_offset+...<br /> fdt_get_property_namelen_+...<br /> fdt_getprop+...<br /> kho_memory_init+...<br /> mm_core_init+...<br /> start_kernel+...<br /> <br /> kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH<br /> images, but kho_fill_kimage() was missing the same guard. As<br /> kho_fill_kimage() is the single point that populates image-&gt;kho.fdt<br /> and image-&gt;kho.scratch, fixing it here is sufficient for both arm64<br /> and x86 as the FDT and boot_params path are bailing out when these<br /> fields are unset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: sprd: 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 check the dma.enabled flag before trying to release the DMA<br /> channels also on late probe errors to avoid dereferencing an error<br /> pointer (or attempting to release a channel a second time).<br /> <br /> This issue was flagged by Sashiko when reviewing a devres allocation<br /> conversion patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> test_kprobes: clear kprobes between test runs<br /> <br /> Running the kprobes sanity tests twice makes all tests fail and<br /> eventually crashes the kernel.<br /> <br /> [root@martin-riscv-1 ~]# echo 1 &gt; /sys/kernel/debug/kunit/kprobes_test/run<br /> ...<br /> # Totals: pass:5 fail:0 skip:0 total:5<br /> ok 1 kprobes_test<br /> [root@martin-riscv-1 ~]# echo 1 &gt; /sys/kernel/debug/kunit/kprobes_test/run<br /> ...<br /> # test_kprobe: EXPECTATION FAILED at lib/tests/test_kprobes.c:64<br /> Expected 0 == register_kprobe(&amp;kp), but<br /> register_kprobe(&amp;kp) == -22 (0xffffffffffffffea)<br /> ...<br /> Unable to handle kernel paging request ...<br /> <br /> The testsuite defines several kprobes and kretprobes as static variables<br /> that are preserved across test runs.<br /> <br /> After register_kprobe and unregister_kprobe, a kprobe contains some<br /> leftover data that must be cleared before the kprobe can be registered<br /> again. The tests are setting symbol_name to define the probe location.<br /> Address and flags must be cleared.<br /> <br /> The existing code clears some of the probes between subsequent tests, but<br /> not between two test runs. The leftover data from a previous test run<br /> makes the registrations fail in the next run.<br /> <br /> Move the cleanups for all kprobes into kprobes_test_init, this function<br /> is called before each single test (including the first test of a test<br /> run).