CVE-2026-72073: Linux kernel · mmc: vub300: fix use-after-free on probe failure
Affects Linux kernelSource CVE Database V5
Not known to be exploited · fixed in face65f80c6946c631ca3490b4ebd2c016a4fd2c : update Linux kernel when convenient.
Data as of 26 Oct 2026, 13:47 UTC
Rated by Threat Radar · CVSS not yet scored by NVD
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 12% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in face65f80c6946c631ca3490b4ebd2c016a4fd2c, a3b5f242997a3be7404112fd48784881560aea57, 618cf6b139503ec18ef93ffd663396aaf99b763a +10
Exploitation evidence
Disclosed: evidence found.
CVE published 15 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in– |
Description
In the Linux kernel, the following vulnerability has been resolved: mmc: vub300: fix use-after-free on probe failure The vub300 driver lifetime-manages its controller state using vub300->kref, with vub300_delete() freeing the mmc host when the last reference is dropped. The probe error path after the inactivity timer has been armed still bypasses that lifetime rule, however, and falls through to mmc_free_host() directly if mmc_add_host() fails. The race window is between arming the inactivity timer and reaching the probe error unwind after mmc_add_host() fails: probe thread timer/workqueue ------------ --------------- kref_init(&vub300->kref) ref = 1 kref_get(&vub300->kref) ref = 2, timer ref add_timer(inactivity_timer) fires after one second | | race window |<----------------------------------------------------> | mmc_add_host(mmc) inactivity timer fires vub300_queue_dead_work() kref_get() ref = 3 queue_work(deadwork) mmc_add_host() fails timer_delete_sync() mmc_free_host(mmc) frees vub300 deadwork runs use-after-free The inactivity timeout is one second, so this would require mmc_add_host() to both fail and take more than one second to do so. This is unlikely to happen in practice, but the error path is still wrong. timer_delete_sync() only waits for the timer callback itself. It does not flush deadwork that the callback may already have queued. As a result, queued deadwork can still hold a kref while the probe error path directly frees the backing mmc host, including the vub300 storage. Fix this by using the same lifetime mechanism as disconnect. Clear vub300->interface so that the timer callback and any queued deadwork return early and drop their references, then drop the initial probe reference and return without falling through to err_free_host.
References
- git.kernel.org/stable/c/face65f80c6946c631ca3490b4ebd2c016a4fd2c (opens in a new tab)
- git.kernel.org/stable/c/6c66653dac9b25272d5fd4ed42a34aa5249e16df (opens in a new tab)
- git.kernel.org/stable/c/5b82af744e06cd741938c3da54fdbe564a7e52d9 (opens in a new tab)
- git.kernel.org/stable/c/618cf6b139503ec18ef93ffd663396aaf99b763a (opens in a new tab)
- git.kernel.org/stable/c/a3b5f242997a3be7404112fd48784881560aea57 (opens in a new tab)