{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-74325", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-74325" ], "published": "2026-08-15T06:04:33Z", "summary": "wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link\n\nmt76_put_vif_phy_link() frees the offchannel mlink with plain kfree()\nafter rcu_assign_pointer(NULL). However, rcu_assign_pointer only prevents\nfuture RCU readers from obtaining the pointer -- it does not wait for\nexisting readers that already hold it via rcu_dereference.\n\nThe TX datapath (e.g. mt7996_mac_write_txwi) dereferences mlink->wcid\nand mlink->idx under rcu_read_lock. If a TX softirq obtained the pointer\nvia rcu_dereference just before the NULL assignment, it will dereference\nfreed memory after the kfree.\n\nstruct mt76_vif_link already contains an rcu_head field that is unused at\nthis free site -- a developer oversight, since the adjacent\nkfree_rcu_mightsleep call for rx_sc in the same function shows the\npattern was understood.\n\nReplace kfree(mlink) with kfree_rcu(mlink, rcu_head).", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.18.29-1+rpt1", "1:6.18.33-1+rpt1", "1:6.18.34-1+rpt1", "1:6.18.39-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.18.29+rpt-rpi-2712", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v6", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v7", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-2712", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v6", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v7", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-2712", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v6", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v7", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8-rt", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-2712", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v6", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v7", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8-rt", "binary_version": "1:6.18.39-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.18.29-1+rpt1": { "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc", "upstream_version": "6.18.29", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" }, "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" }, "1:6.18.34-1+rpt1": { "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af", "upstream_version": "6.18.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" }, "1:6.18.39-1+rpt1": { "linux_commit": "60ea684a8ace97bb0db1a16e20753bdd6ab371ff", "upstream_version": "6.18.39", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.40" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-74325" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/c7a83899203ed36696a2d35ddd03c0f522874a63" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/50e700ac0edce72dee5c3a9755865d9423696ac7" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7fae097aa9a56c30febf539d72ef3773165d3aa3" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-17T05:50:24Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The bug is reached only through local nl80211/genl paths (NL80211_CMD_REMAIN_ON_CHANNEL, CANCEL_REMAIN_ON_CHANNEL, TRIGGER_SCAN) that call mt76_put_vif_phy_link during ROC/scan teardown; remote WiFi frames cannot invoke this free path.\nAC:L - Exploitation is a race between ROC/scan completion freeing the offchannel mlink and the TX datapath still dereferencing it under RCU; an attacker with nl80211 access controls both sides by starting offchannel ops, queuing offchannel TX, and cancelling ROC concurrently.\nPR:L - Entry points require GENL_UNS_ADMIN_PERM (CAP_NET_ADMIN in the socket user namespace). Per CNA guidance this is Low because unprivileged users can obtain CAP_NET_ADMIN via user namespaces and drive ROC/scan on an mt76 multi-radio interface they control.\nUI:N - No victim interaction is required once the attacker can issue nl80211 ROC/scan commands and offchannel TX; exploitation does not depend on a user opening files, mounting filesystems, or clicking prompts.\nS:U - Impact is confined to kernel memory corruption and privilege escalation within the same OS security boundary; it does not cross VM, container, or IOMMU isolation boundaries on its own.\nC:H - This is a use-after-free of struct mt76_vif_link freed via kfree while TX paths such as mt7996_mac_write_txwi still rcu_dereference and read mlink fields; UAF enables heap grooming for arbitrary kernel memory disclosure.\nI:H - Freed mlink contents control TXWI fields (omac_idx, wmm_idx, band_idx, bss idx) passed to firmware DMA descriptors; UAF provides a practical path to corrupt kernel heap metadata and achieve arbitrary code execution.\nA:H - Dereferencing the freed offchannel_link in the TX worker/softirq path causes kernel oops or panic; UAF on a hot transmit path can crash multi-radio mt76 APs, routers, and client devices during P2P/scan offchannel operations." } } }