CVE-2024-56541

See a problem?
Please try reporting it to the source first.
Source
https://nvd.nist.gov/vuln/detail/CVE-2024-56541
Import Source
https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-56541.json
JSON Data
https://api.test.osv.dev/v1/vulns/CVE-2024-56541
Related
Published
2024-12-27T14:15:33Z
Modified
2025-01-08T23:46:02.596374Z
Severity
  • 7.8 (High) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H CVSS Calculator
Summary
[none]
Details

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix use-after-free in ath12kdpcc_cleanup()

During ath12k module removal, in ath12kcoredeinit(), ath12kmacdestroy() un-registers ah->hw from mac80211 and frees the ah->hw as well as all the ar's in it. After this ath12kcoresocdestroy()-> ath12kdpfree()-> ath12kdpcccleanup() tries to access one of the freed ar's from pending skb.

This is because during mac destroy, driver failed to flush few data packets, which were accessed later in ath12kdpcc_cleanup() and freed, but using ar from the packet led to this use-after-free.

BUG: KASAN: use-after-free in ath12kdpcc_cleanup.part.0+0x5e2/0xd40 [ath12k] Write of size 4 at addr ffff888150bd3514 by task modprobe/8926 CPU: 0 UID: 0 PID: 8926 Comm: modprobe Not tainted 6.11.0-rc2-wt-ath+ #1746 Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021

Call Trace: <TASK> dumpstacklvl+0x7d/0xe0 printaddressdescription.constprop.0+0x33/0x3a0 printreport+0xb5/0x260 ? kasanaddrtoslab+0x24/0x80 kasanreport+0xd8/0x110 ? ath12kdpcccleanup.part.0+0x5e2/0xd40 [ath12k] ? ath12kdpcccleanup.part.0+0x5e2/0xd40 [ath12k] kasancheckrange+0xf3/0x1a0 _kasancheckwrite+0x14/0x20 ath12kdpcccleanup.part.0+0x5e2/0xd40 [ath12k] ath12kdpfree+0x178/0x420 [ath12k] ath12kcorestop+0x176/0x200 [ath12k] ath12kcoredeinit+0x13f/0x210 [ath12k] ath12kpciremove+0xad/0x1c0 [ath12k] pcideviceremove+0x9b/0x1b0 deviceremove+0xbf/0x150 devicereleasedriverinternal+0x3c3/0x580 ? _kasancheckread+0x11/0x20 driverdetach+0xc4/0x190 busremovedriver+0x130/0x2a0 driverunregister+0x68/0x90 pciunregisterdriver+0x24/0x240 ? findmoduleall+0x13e/0x1e0 ath12kpciexit+0x10/0x20 [ath12k] _dosysdeletemodule+0x32c/0x580 ? moduleflags+0x2f0/0x2f0 ? kmemcachefree+0xf0/0x410 ? _fput+0x56f/0xab0 ? _fput+0x56f/0xab0 ? debugsmpprocessorid+0x17/0x20 _x64sysdeletemodule+0x4f/0x70 x64syscall+0x522/0x9f0 dosyscall64+0x64/0x130 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f8182c6ac8b

Commit 24de1b7b231c ("wifi: ath12k: fix flush failure in recovery scenarios") added the change to decrement the pending packets count in case of recovery which make sense as ah->hw as well all ar's in it are intact during recovery, but during core deinit there is no use in decrementing packets count or waking up the empty waitq as the module is going to be removed also ar's from pending skb's can't be used and the packets should just be released back.

To fix this, avoid accessing ar from skb->cb when driver is being unregistered.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00214-QCAHKSWPLSILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPLV1.0V2.0SILICONZ-3

References

Affected packages

Debian:13 / linux

Package

Name
linux
Purl
pkg:deb/debian/linux?arch=source

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
6.12.3-1

Affected versions

6.*

6.1.27-1
6.1.37-1
6.1.38-1
6.1.38-2~bpo11+1
6.1.38-2
6.1.38-3
6.1.38-4~bpo11+1
6.1.38-4
6.1.52-1
6.1.55-1~bpo11+1
6.1.55-1
6.1.64-1
6.1.66-1
6.1.67-1
6.1.69-1~bpo11+1
6.1.69-1
6.1.76-1~bpo11+1
6.1.76-1
6.1.82-1
6.1.85-1
6.1.90-1~bpo11+1
6.1.90-1
6.1.94-1~bpo11+1
6.1.94-1
6.1.98-1
6.1.99-1
6.1.106-1
6.1.106-2
6.1.106-3
6.1.112-1
6.1.115-1
6.1.119-1
6.1.123-1
6.3.1-1~exp1
6.3.2-1~exp1
6.3.4-1~exp1
6.3.5-1~exp1
6.3.7-1~bpo12+1
6.3.7-1
6.3.11-1
6.4~rc6-1~exp1
6.4~rc7-1~exp1
6.4.1-1~exp1
6.4.4-1~bpo12+1
6.4.4-1
6.4.4-2
6.4.4-3~bpo12+1
6.4.4-3
6.4.11-1
6.4.13-1
6.5~rc4-1~exp1
6.5~rc6-1~exp1
6.5~rc7-1~exp1
6.5.1-1~exp1
6.5.3-1~bpo12+1
6.5.3-1
6.5.6-1
6.5.8-1
6.5.10-1~bpo12+1
6.5.10-1
6.5.13-1
6.6.3-1~exp1
6.6.4-1~exp1
6.6.7-1~exp1
6.6.8-1
6.6.9-1
6.6.11-1
6.6.13-1~bpo12+1
6.6.13-1
6.6.15-1
6.6.15-2
6.7-1~exp1
6.7.1-1~exp1
6.7.4-1~exp1
6.7.7-1
6.7.9-1
6.7.9-2
6.7.12-1~bpo12+1
6.7.12-1
6.8.9-1
6.8.11-1
6.8.12-1~bpo12+1
6.8.12-1
6.9.2-1~exp1
6.9.7-1~bpo12+1
6.9.7-1
6.9.8-1
6.9.9-1
6.9.10-1~bpo12+1
6.9.10-1
6.9.11-1
6.9.12-1
6.10-1~exp1
6.10.1-1~exp1
6.10.3-1
6.10.4-1
6.10.6-1~bpo12+1
6.10.6-1
6.10.7-1
6.10.9-1
6.10.11-1~bpo12+1
6.10.11-1
6.10.12-1
6.11~rc4-1~exp1
6.11~rc5-1~exp1
6.11-1~exp1
6.11.2-1
6.11.4-1
6.11.5-1~bpo12+1
6.11.5-1
6.11.6-1
6.11.7-1
6.11.9-1
6.11.10-1~bpo12+1
6.11.10-1
6.12~rc6-1~exp1

Ecosystem specific 

{
    "urgency": "not yet assigned"
}