Kernel use-after-free via file descriptor syscalls
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in p9, p5, p14
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
A file descriptor can be closed while a thread is blocked in a poll(2) or select(2) call waiting for that descriptor. Because the blocked thread does not hold a reference to the underlying object, this closure may result in the object being freed while the thread remains blocked. In this situation, the kernel must remove the blocked thread from the per-object wait queue prior to freeing the object. In the case of some file descriptor types, the kernel failed to unlink blocked threads from the object before freeing it. When the blocked thread is subsequently woken, it accesses memory that has already been freed resulting in a use-after-free vulnerability. The use-after-free vulnerability may be triggered by an unprivileged local user and can be exploited to obtain superuser privileges.
Timeline
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- CVE published
- Record last updated
Affected versions
- FreeBSD FreeBSD
From 15.0-RELEASE · fixed in p9; From 14.4-RELEASE · fixed in p5; From 14.3-RELEASE · fixed in p14