Vulnerabilidades do Linux Linux

In the Linux kernel, the following vulnerability has been resolved: regulator: core: use system_freezable_wq for init complete work schedule_delayed_work() uses system_wq, which is non-freezable, allowing regulator_init_complete_work to run concurrently with system suspend. This work fires ~30s after boot to disable unused regulators via I2C. When it races with PM suspend, the I2C adapter may already be suspended, triggering a -ESHUTDOWN warning in __i2c_transfer(): WARNING: ... at __i2c_transfer+0x36c/0x3c8 Call trace: __i2c_transfer i2c_transfer regmap_i2c_write _regmap_update_bits regulator_disable_regmap _regulator_do_disable regulator_late_cleanup regulator_init_complete_work_function process_one_work Switch to system_freezable_wq so the work is frozen before any device is suspended, eliminating the race.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: free vif links after clearing wcid entries on full reset mt7996_mac_reset_vif_iter() queues non-default vif links for kfree_rcu while dev->wcid[] still holds pointers to the wcid embedded in each freed link; mt76_reset_device() then dereferences those entries and runs mt76_wcid_cleanup() on them. If a grace period elapses in between, the cleanup operates on freed memory. Run mt76_reset_device() first, so the wcid entries are cleaned up and cleared while the links are still valid.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix double hif2 init on the non-WED path mt7915_pci_init_hif2() was called unconditionally and again inside the WED-inactive branch. The helper increments the global hif_idx, writes the PCIe RECOG_ID register and takes a get_device() reference via mt7915_pci_get_hif2(), while removal only drops one reference. On non-WED dual-hif hardware this double-incremented hif_idx, wrote RECOG_ID twice and leaked a device reference. Only the call inside the WED-inactive branch is correct; drop the unconditional one. hif2 is already initialised to NULL.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: release hif2 reference on probe IRQ failure The hif2 reference obtained by mt7915_pci_init_hif2() is only released on error paths that key off dev->hif2, which is not assigned until after the IRQ setup. If pci_alloc_irq_vectors() or the primary devm_request_irq() fails, the reference leaks. Drop it explicitly on those paths via mt7915_put_hif2().

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: clear stale link state on full reset After a full chip reset, mac80211 reconfig replays interface, link and channel context setup. mt7996_vif_link_add() short-circuits when the link_id is still marked in mvif->valid_links, a state introduced for postponing link teardown to interface removal. The reset path frees the link structures without clearing those bits, so the replayed setup never re-creates dev_info/bss_info/STA records in the restarted firmware and never re-registers the link wcid, leaving the device inoperative. The reset path also leaks every allocated MLD index: per-link indices and the per-vif group/remap indices are re-allocated from scratch during reconfig, but the old bits stay set in the masks, so repeated full resets exhaust the index space. Clear valid_links in the reset vif iterator and reset the MLD index masks alongside the existing omac_mask clearing.

In the Linux kernel, the following vulnerability has been resolved: bpf: Reject >8 byte return values on return-reading trampoline paths btf_distill_func_proto() builds the function model used for the fentry/fexit/fmod_ret/fsession trampolines and struct_ops. It has accepted a 16-byte __int128 return value since the trampoline was introduced: __get_type_size() returns the integer's type size, and the return-type check only rejected ret < 0. But the BPF trampoline preserves only 8 bytes of the return value (RAX on x86, i.e. R0). For an attach type that reads the target's return value the second half (RDX / R3) is neither saved nor restored, so a program attached to a function returning a 16-byte value corrupts the value seen by the real caller and itself observes only half of it. struct_ops trampolines have the same limitation. This affects the attach types that read the target's return value: fexit, fmod_ret and fsession (plus the _multi variants of fexit and fsession), and struct_ops. fentry/fentry_multi run before the target returns and are unaffected. Reject a >8 byte return value for these attach types in bpf_check_attach_target() and bpf_check_attach_btf_id_multi(), and for struct_ops in bpf_struct_ops_desc_init().

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: do not attach hif2 WED when the main WED attach failed If the WED attach for the primary PCIe function fails, the probe path still attached wed_hif2 for the secondary function, leaving the device in an inconsistent half-WED configuration that crashes later. The hif2 call also re-enabled hwrro_mode, which the failed primary attach had just turned off. Skip the hif2 WED setup when the primary WED device is not active.

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: reject out-of-range link ids in mt76_vif_link() mt76_vif_link() indexes mvif->link[] without validating link_id, but callers pass mvif->deflink_id / msta->deflink_id, which hold IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added. Since IEEE80211_MLD_MAX_NUM_LINKS is 15, that reads one element past the end of the array, aliasing mt76_vif_data.offchannel_link. Reachable via mt7996_set_tsf()/mt7996_offset_tsf() and mt7996_net_fill_forward_path(). Bounds check link_id and return NULL, matching mt7996_sta_link() and mt7996_sta_link_protected().

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix out-of-bounds link array access in mt7996_tx() When mac80211 leaves the link unspecified, mt7996_tx() substitutes the primary link id of the station or vif. That value is IEEE80211_LINK_UNSPECIFIED (0xf) until the first link has been added, and it is then used unchecked to index vif->link_conf[], mvif->mt76.link[] and sta->link[], all of which hold IEEE80211_MLD_MAX_NUM_LINKS (15) entries. Clamp the primary link id to the default link before using it, and use the clamped value for the link_sta fallback as well.

In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: snoc: use memcpy_fromio() for MSA ramdump On WCN3990/SNOC the MSA region is mapped with devm_memremap(MEMREMAP_WT). On arm64 such a mapping is not Normal-cacheable, so unaligned accesses to it are not permitted. ath10k_msa_dump_memory() copies the region with a plain memcpy(), whose optimized __pi_memcpy_generic implementation issues wide/unaligned loads. This triggers an alignment fault (FSC=0x21) Oops in ath10k_snoc_fw_crashed_dump() while collecting the devcoredump: Unable to handle kernel paging request ... FSC=0x21: alignment fault pc : __pi_memcpy_generic lr : ath10k_snoc_fw_crashed_dump [ath10k_snoc] The Oops both leaves the firmware RAM dump buffer zeroed (no dump is captured) and crashes the kernel, which in turn breaks modem SSR recovery. Use memcpy_fromio(), which only performs accesses that are valid for such a device-memory mapping. The generic memcpy_fromio() implementation aligns the source before issuing word-sized reads and stores the destination with put_unaligned(), so it is also safe for the coherent DMA allocation used on the non-reserved-memory path. ath11k and ath12k use the same pattern when copying target memory into crash dumps, so call it unconditionally here too. The MEMREMAP_WT pointer is a plain void *, so an explicit __iomem cast is needed; use __force to keep sparse happy. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.3.7.c5-00107-QCAHLSWMTPL-1

In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: disconnect on CSA to channel 0 The refactor for the CSA parsing erroneously equates channel zero and no information present, leading it to ignore a CSA on an AP that advertises a switch to that (invalid) channel. This leads to not disconnecting, which we should. For Intel devices, this can lead to a firmware crash. Fix this by using an int type for the channel number as well as the opclass, and using a (negative) value that cannot be encoded in the element to indicate it's not present.

In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: clean up color-change beacon data on errors nl80211_color_change() calls nl80211_parse_beacon() for the beacon_next template, which can allocate params.beacon_next.mbssid_ies and .rnr_ies. A parsing failure returned directly instead of using the out: cleanup, leaking any allocations completed before the error. Allocate the nested attribute table before parsing beacon_next. Its allocation failure can then return before beacon data exists, while a later parsing failure uses out: to release the parsed data.

In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix P2P action frame handling without device vif Some P2P action frame paths assume the P2P device vif is always available. That is not true when userspace sends non-P2P public action frames through the primary interface, or when action-frame abort runs after the P2P device vif has not been created. Fall back to the primary vif when aborting an action frame without a P2P device vif, and guard P2P device saved IE access before using it for peer channel search.

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix mmap_lock deadlock on arena lock failure Reported by the Sashiko AI review. arena_vm_fault() returns VM_FAULT_RETRY when it can't take arena->spinlock, but it never took mmap_lock. The fault path assumes a VM_FAULT_RETRY handler already dropped mmap_lock and re-takes it on the retry, so mmap_lock gets taken twice and can deadlock: do_user_addr_fault() { fault = handle_mm_fault(...); // calls arena_vm_fault() if (fault & VM_FAULT_RETRY) goto retry; // re-locks mmap_lock mmap_read_unlock(mm); } Return VM_FAULT_SIGBUS instead, for two reasons: 1. We could keep VM_FAULT_RETRY, but then we'd have to drop the fault lock first and cap the retry ourselves, the way __folio_lock_or_retry() does. 2. A failed raw_res_spin_lock_irqsave() already means a possible deadlock was detected, so retrying just hits the same lock again. So returning VM_FAULT_RETRY here is overkill.

In the Linux kernel, the following vulnerability has been resolved: pinctrl: generic: free maps on pinctrl_generic_to_map() failure pinctrl_generic_to_map() parses DT configuration and allocates pinctrl maps via pinctrl_utils_reserve_map(). If subsequent steps (such as pinctrl_utils_add_map_mux(), pinctrl_generic_add_group(), pinconf_generic_parse_dt_config(), or pinctrl_utils_add_map_configs()) return an error, *maps may contain partially allocated map entries. Returning the error directly without freeing *maps leaks the allocated mapping memory across all drivers that rely on pinctrl_generic_to_map(). Fix this by calling pinctrl_utils_free_map() and resetting *maps, *num_maps, and *num_reserved_maps in the error path of pinctrl_generic_to_map().

In the Linux kernel, the following vulnerability has been resolved: powerpc/syscall: Fix syscall skip handling for seccomp and ptrace After enabling GENERIC_ENTRY on PowerPC, syscall_enter_from_user_mode() returns -1 as a sentinel to signal that seccomp or ptrace has intercepted the syscall and already set a return value via syscall_set_return_value(). system_call_exception() was not handling this sentinel, and since -1UL is >= NR_syscalls, the code fell into the out-of-range path and returned -ENOSYS, overwriting the errno already placed in regs->gpr[3]. The naive fix of checking r0 == -1L before the NR_syscalls bounds check is ambiguous: a user legitimately calling syscall(-1) also produces r0 == -1L, and a tracer intercepting such a call would have its injected return value silently discarded. Fix this by introducing a thread flag that is set whenever syscall_set_return_value() explicitly updates the return value. In system_call_exception(), check and clear this flag before dispatching the syscall, and return the preset value directly when it is present. This ensures that an explicitly supplied return value always suppresses syscall execution, regardless of the syscall number. This handles all seccomp actions correctly: - SECCOMP_RET_ERRNO, SECCOMP_RET_TRACE (no tracer), SECCOMP_RET_USER_NOTIF: all call syscall_set_return_value(), flag is set, injected value returned. - SECCOMP_RET_TRAP, SECCOMP_RET_KILL: call syscall_rollback() and deliver a signal; flag is not set, but the process is dying so the return value is irrelevant. The fix covers both ppc32 and ppc64 with no #ifdefs.

In the Linux kernel, the following vulnerability has been resolved: serial: amba-pl011: keep console clock enabled for atomic writes pl011_console_write_atomic() runs from nbcon atomic context, where sleeping is not allowed. It calls clk_enable(), which takes the common-clk enable_lock. Under PREEMPT_RT that is a sleeping lock: clk_enable_lock() first tries spin_trylock_irqsave(), but on contention falls back to spin_lock_irqsave(). Therefore, an atomic-context printk on an RT kernel with a clk-backed pl011 can trip: BUG: sleeping function called from invalid context at spinlock_rt.c:48 __might_resched from rt_spin_lock rt_spin_lock from clk_enable_lock clk_enable_lock from clk_enable clk_enable from pl011_console_write_atomic ... from vprintk_emit This was found and reproduced on PREEMPT_RT. Arm32 and arm64 DT SoCs are affected; arm64 SBSA/ACPI has no clk, so clk_enable(NULL) short-circuits before the lock. In addition, write_atomic() may be invoked from NMI context and is documented to avoid locking. Removing clk_enable() from the callback also avoids a potentially unsafe NMI acquisition of the common-clock enable_lock. An nbcon atomic-capable console must be printable from any context, so the clock cannot be gated between writes. Enable the clock while the console is available for output: use clk_prepare_enable() in pl011_console_setup(), release it via clk_disable_unprepare() in the console .exit() callback, and drop the per-write clk_enable()/clk_disable() pairs from write_atomic() and write_thread(). When printk suspends consoles, drop the reference after uart_suspend_port() stops console access and restore it before uart_resume_port() -- but only if suspend actually marked the port suspended (a wake-capable tty stays running and must keep its clock), and keep it when console_suspend_enabled is false so no_console_suspend works. The active power cost of keeping the clock enabled is platform-dependent: none where the UART clock is a fixed always-on oscillator, real where it is a gateable clock branch, which then cannot be gated (nor possibly can its parent clocks) while the console is available for output. When serial core actually suspends the port, the reference is released so the clock provider can gate the clock tree.

In the Linux kernel, the following vulnerability has been resolved: serial: core: do fallible allocations before the console can be registered serial_core_add_one_port() allocates uport->tty_groups after uart_configure_port(), which may register the console. If the allocation fails, the driver unwinds the port while its console remains registered. The earlier uport->name allocation has a related failure path that leaves state->uart_port linked to a port being freed. Failslab reproduced a NULL dereference in PL011 console output and a KASAN use-after-free in i.MX console output after failed binds. Allocate the name and tty_groups before linking the port and configuring it. Reserve space for the optional driver attribute group because config_port() may populate uport->attr_group during configuration.

In the Linux kernel, the following vulnerability has been resolved: serial: core: clear freed pointers on uart_register_driver() failure uart_register_driver() leaves drv->state pointing to freed memory when tty_alloc_driver() fails. If tty_register_driver() fails, drv->tty_driver also retains a pointer after its reference is dropped. Drivers that use drv->state as an "already registered" flag can then skip registration on the next probe and pass the freed state to uart_add_one_port(). This issue was found with failslab on QEMU's raspi1ap board by failing registration and binding the PL011 port again. Clear both pointers on their failure paths, as uart_unregister_driver() already does.