futex/pi: Plug private futex exec() race
In the Linux kernel, the following vulnerability has been resolved: futex/pi: Plug private futex exec() race The check for private futexes whether the waiter's mm, which is stored in the futex_key and copied into the pi_state, is the same as the owner's mm is not sufficient for exec(). exec() has a gap where the mm check fails to give the correct answer: exec() ... exec_release_mm() futex_exec_release() tsk::futex::exit_state = EXITING; cleanup_robust_list(); 1) tsk::futex::exit_state = OK; ... old_mm = tsk::mm; 2) tsk::mm = ->mm; Between #1 and #2 the check for the mm is wrong as that mm is about to be swapped out and eventually freed. Plug this gap by: 1) Setting tsk::futex::exit_state to FUTEX_STATE_DEAD in futex_exec_release() 2) Setting tsk::futex::exit_state to FUTEX_STATE_OK after the mm has been switched. From a futex point of view the task is dead after it finished the robust list cleanup up to the point where it sets the state to OK again.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.18.47, 7.1.11, 7.2.1
- CVEs
- CVE-2026-80777
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 15:06 UTC · Revision 1
Source evidence
In the Linux kernel, the following vulnerability has been resolved: futex/pi: Plug private futex exec() race The check for private futexes whether the waiter's mm, which is stored in the futex_key and copied into the pi_state, is the same as the owner's mm is not sufficient for exec(). exec() has a gap where the mm check fails to give the correct answer: exec() ... exec_release_mm() futex_exec_release() tsk::futex::exit_state = EXITING; cleanup_robust_list(); 1) tsk::futex::exit_state = OK; ... old_mm = tsk::mm; 2) tsk::mm = ->mm; Between #1 and #2 the check for the mm is wrong as that mm is about to be swapped out and eventually freed. Plug this gap by: 1) Setting tsk::futex::exit_state to FUTEX_STATE_DEAD in futex_exec_release() 2) Setting tsk::futex::exit_state to FUTEX_STATE_OK after the mm has been switched. From a futex point of view the task is dead after it finished the robust list cleanup up to the point where it sets the state to OK again.
osv:CVE-2026-80777
Kernel
Fixed versions: 6.18.47, 7.1.11, 7.2.1
Complete source record
{
"id": "d858bc0f7d5ed804e456f4c06bbb765074b025e1a6cff7c3d50ff2883220ae22",
"url": "https://osv.dev/vulnerability/CVE-2026-80777",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "futex/pi: Plug private futex exec() race",
"summary": "In the Linux kernel, the following vulnerability has been resolved: futex/pi: Plug private futex exec() race The check for private futexes whether the waiter's mm, which is stored in the futex_key and copied into the pi_state, is the same as the owner's mm is not sufficient for exec(). exec() has a gap where the mm check fails to give the correct answer: exec() ... exec_release_mm() futex_exec_release() tsk::futex::exit_state = EXITING; cleanup_robust_list(); 1) tsk::futex::exit_state = OK; ... old_mm = tsk::mm; 2) tsk::mm = ->mm; Between #1 and #2 the check for the mm is wrong as that mm is about to be swapped out and eventually freed. Plug this gap by: 1) Setting tsk::futex::exit_state to FUTEX_STATE_DEAD in futex_exec_release() 2) Setting tsk::futex::exit_state to FUTEX_STATE_OK after the mm has been switched. From a futex point of view the task is dead after it finished the robust list cleanup up to the point where it sets the state to OK again.",
"evidence": "osv:CVE-2026-80777",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.18.47",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.11",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.1",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-80777",
"aliases": [
"CVE-2026-80777"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "80367ad01d93ac781b0e1df246edaf006928002f"
},
{
"fixed": "fdf538b2e69653ff740e84042245018e5680cd7b"
},
{
"fixed": "0478bc6bf197629fea0331d65b39eeea043c6cf0"
},
{
"fixed": "d7944cee62ec6cca1c90780a766960a57d3b4bb8"
},
{
"fixed": "c5f0bc9fd1cec4a00400cc727fcde03e0fde17cc"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80777.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.16.0"
},
{
"fixed": "6.18.47"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.1.11"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "7.2.0"
},
{
"fixed": "7.2.1"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80777.json"
}
}
],
"modified": "2026-10-28T02:30:36.592494289Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/0478bc6bf197629fea0331d65b39eeea043c6cf0",
"https://git.kernel.org/stable/c/c5f0bc9fd1cec4a00400cc727fcde03e0fde17cc",
"https://git.kernel.org/stable/c/d7944cee62ec6cca1c90780a766960a57d3b4bb8",
"https://git.kernel.org/stable/c/fdf538b2e69653ff740e84042245018e5680cd7b",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80777.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-80777",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80777.json"
}
},
"related_cves": [
{
"value": "CVE-2026-80777",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 503947,
"published_at": "2026-09-04T15:12:49.215+00:00"
}