CVE-2024-39486drm/drm_file: Fix pid refcounting race
- 7.8HighCVSS base score
- 0.23%Exploitation in 30 daysEPSS · top 86% of all CVEs
- NoKnown exploitednot in CISA's KEV catalog
- NonePublic exploitsnone known yet
Description
In the Linux kernel, the following vulnerability has been resolved: drm/drm_file: Fix pid refcounting race <[email protected]>, Maxime Ripard <[email protected]>, Thomas Zimmermann <[email protected]> filp->pid is supposed to be a refcounted pointer; however, before this patch, drm_file_update_pid() only increments the refcount of a struct pid after storing a pointer to it in filp->pid and dropping the dev->filelist_mutex, making the following race possible: process A process B ========= ========= begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid B>, 1) mutex_unlock(&dev->filelist_mutex) begin drm_file_update_pid mutex_lock(&dev->filelist_mutex) rcu_replace_pointer(filp->pid, <pid A>, 1) mutex_unlock(&dev->filelist_mutex) get_pid(<pid A>) synchronize_rcu() put_pid(<pid B>) *** pid B reaches refcount 0 and is freed here *** get_pid(<pid B>) *** UAF *** synchronize_rcu() put_pid(<pid A>) As far as I know, this race can only occur with CONFIG_PREEMPT_RCU=y because it requires RCU to detect a quiescent state in code that is not explicitly calling into the scheduler. This race leads to use-after-free of a "struct pid". It is probably somewhat hard to hit because process A has to pass through a synchronize_rcu() operation while process B is between mutex_unlock() and get_pid(). Fix it by ensuring that by the time a pointer to the current task's pid is stored in the file, an extra reference to the pid has been taken. This fix also removes the condition for synchronize_rcu(); I think that optimization is unnecessary complexity, since in that case we would usually have bailed out on the lockless check above.
Timeline
ID reserved
By Linux
- 11 days later
· 11 days later
Published
- 2 years later
· 2 years later
Record updated
Changes after publication (a new score, a public exploit, EPSS crossing 1, 10 or 50 %, leaving KEV) are kept since November 2026; earlier ones are not known.
Scores
| Scored by | CVSS | Score | Vector |
|---|---|---|---|
| LinuxCNA (assigner) | 3.1 | High7.8 | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| NVDNVD · Modified | 3.1 | High7.0 | CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H |
- EPSS (exploitation in 30 days)
- 0.23% · top 86% of all CVEs (13 Nov 2026)
- CISA SSVC
- Exploitation: none · Automatable: no · Technical impact: partial
The list uses the assigner's score when there is one, then CISA's, then NVD's: High 7.8.
Affected products
- affected 031ddd28008971cce0b5626379b910d0a05fb4dd – < 16682588ead4a593cf1aebb33b36df4d1e9e4ffa
- affected 1c7a387ffef894b1ab3942f0482dac7a6e0a909c – < 0acce2a5c619ef1abdee783d7fea5eac78ce4844
- affected 1c7a387ffef894b1ab3942f0482dac7a6e0a909c – < 4f2a129b33a2054e62273edd5a051c34c08d96e9
- affected 6.6.9 – < 6.6.37
- affected 6.7
- unaffected < 6.7
- unaffected 6.6.37 – ≤ 6.6.*
- unaffected 6.9.8 – ≤ 6.9.*
- unaffected 6.10 – ≤ *
References
References3
- https://git.kernel.org/stable/c/16682588ead4a593cf1aebb33b36df4d1e9e4ffa (opens in a new tab)x_transferred
- https://git.kernel.org/stable/c/0acce2a5c619ef1abdee783d7fea5eac78ce4844 (opens in a new tab)x_transferred
- https://git.kernel.org/stable/c/4f2a129b33a2054e62273edd5a051c34c08d96e9 (opens in a new tab)x_transferred
Sources
The same CVE in the primary databases and aggregators, to check against.
- CVE.org record (opens in a new tab)
- CVE List JSON (GitHub) (opens in a new tab)
- NVD (opens in a new tab)
- FIRST EPSS (opens in a new tab)
- EUVD EUVD-2024-38011 (opens in a new tab)
- OSV.dev (opens in a new tab)
- GitHub Advisories (opens in a new tab)
- CIRCL Vulnerability-Lookup (opens in a new tab)
Badge for a README or a ticket
[](https://cveledger.app/cve/CVE-2024-39486)Record last updated .