Description
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link
mt76_put_vif_phy_link() frees the offchannel mlink with plain kfree()
after rcu_assign_pointer(NULL). However, rcu_assign_pointer only prevents
future RCU readers from obtaining the pointer -- it does not wait for
existing readers that already hold it via rcu_dereference.
The TX datapath (e.g. mt7996_mac_write_txwi) dereferences mlink->wcid
and mlink->idx under rcu_read_lock. If a TX softirq obtained the pointer
via rcu_dereference just before the NULL assignment, it will dereference
freed memory after the kfree.
struct mt76_vif_link already contains an rcu_head field that is unused at
this free site -- a developer oversight, since the adjacent
kfree_rcu_mightsleep call for rx_sc in the same function shows the
pattern was understood.
Replace kfree(mlink) with kfree_rcu(mlink, rcu_head).
wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link
mt76_put_vif_phy_link() frees the offchannel mlink with plain kfree()
after rcu_assign_pointer(NULL). However, rcu_assign_pointer only prevents
future RCU readers from obtaining the pointer -- it does not wait for
existing readers that already hold it via rcu_dereference.
The TX datapath (e.g. mt7996_mac_write_txwi) dereferences mlink->wcid
and mlink->idx under rcu_read_lock. If a TX softirq obtained the pointer
via rcu_dereference just before the NULL assignment, it will dereference
freed memory after the kfree.
struct mt76_vif_link already contains an rcu_head field that is unused at
this free site -- a developer oversight, since the adjacent
kfree_rcu_mightsleep call for rx_sc in the same function shows the
pattern was understood.
Replace kfree(mlink) with kfree_rcu(mlink, rcu_head).
Published:
2026-08-15
Score:
n/a
EPSS:
n/a
KEV:
No
Impact:
n/a
Action:
n/a
Analysis
No analysis available yet.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux | unaffected |
|
||||||||||||||||||
| Linux | Linux | affected |
|
No data.
No data.
No data available yet.
Remediation
No remediation available yet.
Tracking
Sign in to view the affected projects.
Advisories
No advisories yet.
References
History
Sat, 15 Aug 2026 06:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link mt76_put_vif_phy_link() frees the offchannel mlink with plain kfree() after rcu_assign_pointer(NULL). However, rcu_assign_pointer only prevents future RCU readers from obtaining the pointer -- it does not wait for existing readers that already hold it via rcu_dereference. The TX datapath (e.g. mt7996_mac_write_txwi) dereferences mlink->wcid and mlink->idx under rcu_read_lock. If a TX softirq obtained the pointer via rcu_dereference just before the NULL assignment, it will dereference freed memory after the kfree. struct mt76_vif_link already contains an rcu_head field that is unused at this free site -- a developer oversight, since the adjacent kfree_rcu_mightsleep call for rx_sc in the same function shows the pattern was understood. Replace kfree(mlink) with kfree_rcu(mlink, rcu_head). | |
| Title | wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link | |
| First Time appeared |
Linux
Linux linux Kernel |
|
| CPEs | cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Linux
Linux linux Kernel |
|
| References |
|
MITRE
Status: PUBLISHED
Assigner: Linux
Published:
Updated: 2026-08-15T05:58:20.236Z
Reserved: 2026-08-15T05:44:03.884Z
Link: CVE-2026-74325
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-08-15T06:22:33.130
Modified: 2026-08-15T06:22:33.130
Link: CVE-2026-74325
Redhat
No data.
OpenCVE Enrichment
No data.
Weaknesses
No weakness.