wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash
When an AER error occurs and the bus is hung, the register reads return
0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in
an invalid memory access when accessing q->desc[] or q->entry[].
Unable to handle kernel paging request at virtual address
ffffffc01099eac0
pc : mt76_dma_add_buf+0x124/0x188 [mt76]
lr : mt76_dma_rx_fill+0x11c/0x1d8 [mt76]
sp : ffffffc016d9bbf0
x29: ffffffc016d9bc10 x28: 0000000000000000
x27: 0000000000000000 x26: ffffffb7855e50b8
x25: ffffffb80d04f000 x24: 00
wifi: mt76: mt792x: Fix memory leak in SDIO TX path
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt792x: Fix memory leak in SDIO TX path
When tx_prepare_skb() returns an error in the SDIO TX path, the
skb is not freed, leading to a memory leak. This can occur when
zero-length frames (such as WNM NULL frames) are dropped to prevent
potential hardware TX hangs.
Fix this by properly releasing the skb with ieee80211_tx_status_ext()
when tx_prepare_skb() fails.
wifi: mt76: fix non-AQL packet accounting for MLO stations
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: fix non-AQL packet accounting for MLO stations
__mt76_tx_queue_skb() overrides the wcid passed by the driver with
sta->drv_priv, so the wcid might incorrectly be changed after TX,
causing wcid->non_aql_packets to be counted on the wrong wcid. For
example, on the AP side, if a station's setup link is the 5G link and
the station uses 2G to transmit a frame, the value of non_aql_packets
is increased on the 5G wcid but decreased on the 2G wcid. Once the
inflated counter exceeds MT_MAX_NON_AQL_PKT, the TX scheduler
permanently refuses to service the station.
Drop th
wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[]
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: validate RX band_idx before dereferencing phys[]
band_idx comes from a 2-bit descriptor field (0-3) and was used directly
to index dev->mt76.phys[] (size __MT_MAX_BAND == 3) and dereference the
result. A corrupt or reserved descriptor value could index out of bounds
or hit a NULL phy on parts with fewer bands. Reject invalid band indices,
mirroring mt7996_rx_get_wcid().
wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: avoid nss underflow in mt7915_mcu_get_sta_nss
If a peer's VHT/HE MCS map has no supported spatial stream (all fields
0x3), the loop exits with nss == 0 and the function returned (u8)-1 (255),
which was then written into the firmware sta_rec_bf beamforming fields.
Clamp the result to 0.
wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: bound TLV walk in mt7996_mcu_get_chip_config
The response TLV loop advanced by tlv->len without a minimum, so a
theoretical firmware response containing a zero-length TLV could spin
forever, hanging the CPU during device probe.
The u32 payload was also read without bounds checking.
Reject a short fixed field, stop on a TLV whose length underruns the
header or overruns the skb.
wifi: mt76: mt7915: unwind state on add_interface failure
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: unwind state on add_interface failure
When mt76_wcid_alloc() fails, mt7915_add_interface() returned without
clearing the vif_mask/omac_mask bits it had already set, without removing
the firmware dev info added earlier, and without clearing a monitor_vif
pointer to the vif mac80211 is about to free. mac80211 does not call
remove_interface() for a failed add, so the indices and firmware dev
entry leaked permanently and testmode could dereference the stale
monitor_vif. Add a proper error unwind.
wifi: mt76: mt7996: hold dev->mt76.mutex while disabling tx worker in SER
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: hold dev->mt76.mutex while disabling tx worker in SER
mt7996_mac_reset_work() parked the tx worker and disabled the RX/TX NAPIs
before taking dev->mt76.mutex. mt76_worker_disable()/_enable() are plain
kthread park/unpark, not refcounted, and __mt76_set_channel() toggles the
same worker and the MT76_RESET bit under the mutex. An L1 SER racing a
channel switch could therefore have the worker unparked and MT76_RESET
cleared while the reset path resets the DMA rings, corrupting descriptors
or tokens. Take the mutex before disabling the worker, as mt7915 does
wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7996: reserve space for the CSA-abort countdown TLV
When a CSA countdown is active, mt7996_mcu_beacon_cntdwn() emits two
bss_bcn_cntdwn_tlv entries (the CSA countdown and the CCA-abort BCC), but
MT7996_BEACON_UPDATE_SIZE only reserved one. With MBSSID enabled and a
near-maximum beacon template the extra 8 bytes could push the offload
command past MT7996_MAX_BSS_OFFLOAD_SIZE and trigger skb_over_panic().
Reserve room for both countdown TLVs.
wifi: mt76: cancel reset and rc work on device unregister
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: cancel reset and rc work on device unregister
Both drivers cancelled dump_work on unregister but left reset_work and
rc_work to be flushed only by destroy_workqueue() in mt76_free_device(),
which runs after the hw is unregistered and the hardware stopped. A
reset_work that fires in that window calls ieee80211_restart_hw() and
re-arms mac_work on an unregistered hw, and rc_work touches station state
being torn down. Cancel both up front, alongside dump_work.
ACPI: processor: Unregister cpufreq notifier on init failure
In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor: Unregister cpufreq notifier on init failure
acpi_processor_driver_init() registers the cpufreq policy notifier before
registering the ACPI processor driver and setting up CPU hotplug state.
If driver_register() or cpuhp_setup_state() fails, the error path only
unregisters the ACPI processor driver and the idle driver. The cpufreq
notifier remains registered even though initialization failed.
Mirror the module exit path on the init failure path and unregister the
cpufreq notifier when it has been registered.
drm/msm: don't tear down KMS twice when KMS init fails
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: don't tear down KMS twice when KMS init fails
When priv->kms_init() (mdp4_kms_init() / mdp5_kms_init()) fails partway
through, both display drivers already tear their KMS state down via
mdp4_destroy() / mdp5_kms_destroy() before returning the error. The
common error path in msm_drm_init() then runs msm_drm_uninit() ->
msm_drm_kms_uninit(), which tries to destroy the very same KMS a second
time, which causes a use-after-free crash.
Bring MDP4/MDP5 in line with the DPU driver whose dpu_kms_init() doesn't
perform error cleanup on the failure. Let the common path own
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dsi: Drop dev_pm_opp_set_rate(0)
dev_pm_opp_set_rate(0) removes the vote specified in required-opps but
does not actually park the clock, making it run without the necessary
power backing. Drop the explicit call to it.
Every call site of ops->link_clk_disable() is followed by
pm_runtime_put(), so the power vote will be rescinded if deemed safe.
Patchwork: https://patchwork.freedesktop.org/patch/742783/
wifi: ath11k: fix leak in ath11k_service_ready_ext_event()
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix leak in ath11k_service_ready_ext_event()
Currently, during ath11k_service_ready_ext_event() processing,
svc_rdy_ext.mac_phy_caps can be allocated during TLV parsing. This is a
temporary allocation that is freed on the success path, but not on the
error path. If parsing succeeds far enough to allocate mac_phy_caps and
then fails on a later TLV, the allocation leaks. So free the allocation
on the error path.
Compile tested only.
regulator: core: use system_freezable_wq for init complete work
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
_regulato
bpf: Reject >8 byte return values on return-reading trampoline paths
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,
bpf, x86: Fix trampoline stack size for 128-bit arguments
In the Linux kernel, the following vulnerability has been resolved:
bpf, x86: Fix trampoline stack size for 128-bit arguments
btf_distill_func_proto() accepts a function argument up to 16 bytes, so a
128-bit scalar such as __int128 reaches the x86 trampoline with
arg_size == 16. But the current implementation assumes an __int128
argument only needs one register, so the register save area is
under-allocated and save_args() overwrites adjacent stack slots.
Compute the register count from arg_size for all arguments to fix it.
wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement
The flow is added to dev->twt_list before sending the agreement to the
firmware, but the error path leaves it linked while flowid_mask is
never set. The flow slot can then be reused and memset while still on
the list, corrupting twt_list, and station removal leaves a dangling
entry behind that mt7915_mac_twt_sched_list_add() later walks.
wifi: mt76: mt7915: fix double hif2 init on the non-WED path
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: fix ext PHY use-after-free on register error path
After mt7915_register_ext_phy() succeeded, a failure of the main PHY
mt7915_init_debugfs() or mt7915_coredump_register() unwound through
free_phy2, which called ieee80211_free_hw() on the ext PHY hw while it
was still registered with mac80211, since mt76_unregister_device() only
unregisters the main hw. Unregister the ext PHY (thermal + phy + hw)
first and skip the redundant free.