CVE-2026-23199 (GCVE-0-2026-23199)
Vulnerability from cvelistv5 – Published: 2026-02-14 16:27 – Updated: 2026-02-14 16:27
VLAI?
Title
procfs: avoid fetching build ID while holding VMA lock
Summary
In the Linux kernel, the following vulnerability has been resolved:
procfs: avoid fetching build ID while holding VMA lock
Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock
or per-VMA lock, whichever was used to lock VMA under question, to avoid
deadlock reported by syzbot:
-> #1 (&mm->mmap_lock){++++}-{4:4}:
__might_fault+0xed/0x170
_copy_to_iter+0x118/0x1720
copy_page_to_iter+0x12d/0x1e0
filemap_read+0x720/0x10a0
blkdev_read_iter+0x2b5/0x4e0
vfs_read+0x7f4/0xae0
ksys_read+0x12a/0x250
do_syscall_64+0xcb/0xf80
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}:
__lock_acquire+0x1509/0x26d0
lock_acquire+0x185/0x340
down_read+0x98/0x490
blkdev_read_iter+0x2a7/0x4e0
__kernel_read+0x39a/0xa90
freader_fetch+0x1d5/0xa80
__build_id_parse.isra.0+0xea/0x6a0
do_procmap_query+0xd75/0x1050
procfs_procmap_ioctl+0x7a/0xb0
__x64_sys_ioctl+0x18e/0x210
do_syscall_64+0xcb/0xf80
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(&mm->mmap_lock);
lock(&sb->s_type->i_mutex_key#8);
lock(&mm->mmap_lock);
rlock(&sb->s_type->i_mutex_key#8);
*** DEADLOCK ***
This seems to be exacerbated (as we haven't seen these syzbot reports
before that) by the recent:
777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")
To make this safe, we need to grab file refcount while VMA is still locked, but
other than that everything is pretty straightforward. Internal build_id_parse()
API assumes VMA is passed, but it only needs the underlying file reference, so
just add another variant build_id_parse_file() that expects file passed
directly.
[akpm@linux-foundation.org: fix up kerneldoc]
Severity ?
No CVSS data available.
Assigner
References
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Linux | Linux |
Affected:
ed5d583a88a9207b866c14ba834984c6f3c51d23 , < b9b97e6aeb534315f9646b2090d1a5024c6a4e82
(git)
Affected: ed5d583a88a9207b866c14ba834984c6f3c51d23 , < cbc03ce3e6ce7e21214c3f02218213574c1a2d08 (git) Affected: ed5d583a88a9207b866c14ba834984c6f3c51d23 , < b5cbacd7f86f4f62b8813688c8e73be94e8e1951 (git) |
||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/proc/task_mmu.c",
"include/linux/buildid.h",
"lib/buildid.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b9b97e6aeb534315f9646b2090d1a5024c6a4e82",
"status": "affected",
"version": "ed5d583a88a9207b866c14ba834984c6f3c51d23",
"versionType": "git"
},
{
"lessThan": "cbc03ce3e6ce7e21214c3f02218213574c1a2d08",
"status": "affected",
"version": "ed5d583a88a9207b866c14ba834984c6f3c51d23",
"versionType": "git"
},
{
"lessThan": "b5cbacd7f86f4f62b8813688c8e73be94e8e1951",
"status": "affected",
"version": "ed5d583a88a9207b866c14ba834984c6f3c51d23",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/proc/task_mmu.c",
"include/linux/buildid.h",
"lib/buildid.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.11"
},
{
"lessThan": "6.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.70",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.70",
"versionStartIncluding": "6.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.10",
"versionStartIncluding": "6.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "6.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nprocfs: avoid fetching build ID while holding VMA lock\n\nFix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock\nor per-VMA lock, whichever was used to lock VMA under question, to avoid\ndeadlock reported by syzbot:\n\n -\u003e #1 (\u0026mm-\u003emmap_lock){++++}-{4:4}:\n __might_fault+0xed/0x170\n _copy_to_iter+0x118/0x1720\n copy_page_to_iter+0x12d/0x1e0\n filemap_read+0x720/0x10a0\n blkdev_read_iter+0x2b5/0x4e0\n vfs_read+0x7f4/0xae0\n ksys_read+0x12a/0x250\n do_syscall_64+0xcb/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n -\u003e #0 (\u0026sb-\u003es_type-\u003ei_mutex_key#8){++++}-{4:4}:\n __lock_acquire+0x1509/0x26d0\n lock_acquire+0x185/0x340\n down_read+0x98/0x490\n blkdev_read_iter+0x2a7/0x4e0\n __kernel_read+0x39a/0xa90\n freader_fetch+0x1d5/0xa80\n __build_id_parse.isra.0+0xea/0x6a0\n do_procmap_query+0xd75/0x1050\n procfs_procmap_ioctl+0x7a/0xb0\n __x64_sys_ioctl+0x18e/0x210\n do_syscall_64+0xcb/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n other info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n rlock(\u0026mm-\u003emmap_lock);\n lock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\n lock(\u0026mm-\u003emmap_lock);\n rlock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\n\n *** DEADLOCK ***\n\nThis seems to be exacerbated (as we haven\u0027t seen these syzbot reports\nbefore that) by the recent:\n\n\t777a8560fd29 (\"lib/buildid: use __kernel_read() for sleepable context\")\n\nTo make this safe, we need to grab file refcount while VMA is still locked, but\nother than that everything is pretty straightforward. Internal build_id_parse()\nAPI assumes VMA is passed, but it only needs the underlying file reference, so\njust add another variant build_id_parse_file() that expects file passed\ndirectly.\n\n[akpm@linux-foundation.org: fix up kerneldoc]"
}
],
"providerMetadata": {
"dateUpdated": "2026-02-14T16:27:24.326Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b9b97e6aeb534315f9646b2090d1a5024c6a4e82"
},
{
"url": "https://git.kernel.org/stable/c/cbc03ce3e6ce7e21214c3f02218213574c1a2d08"
},
{
"url": "https://git.kernel.org/stable/c/b5cbacd7f86f4f62b8813688c8e73be94e8e1951"
}
],
"title": "procfs: avoid fetching build ID while holding VMA lock",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23199",
"datePublished": "2026-02-14T16:27:24.326Z",
"dateReserved": "2026-01-13T15:37:45.985Z",
"dateUpdated": "2026-02-14T16:27:24.326Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2026-23199\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-02-14T17:15:57.743\",\"lastModified\":\"2026-02-18T17:52:22.253\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nprocfs: avoid fetching build ID while holding VMA lock\\n\\nFix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock\\nor per-VMA lock, whichever was used to lock VMA under question, to avoid\\ndeadlock reported by syzbot:\\n\\n -\u003e #1 (\u0026mm-\u003emmap_lock){++++}-{4:4}:\\n __might_fault+0xed/0x170\\n _copy_to_iter+0x118/0x1720\\n copy_page_to_iter+0x12d/0x1e0\\n filemap_read+0x720/0x10a0\\n blkdev_read_iter+0x2b5/0x4e0\\n vfs_read+0x7f4/0xae0\\n ksys_read+0x12a/0x250\\n do_syscall_64+0xcb/0xf80\\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\\n\\n -\u003e #0 (\u0026sb-\u003es_type-\u003ei_mutex_key#8){++++}-{4:4}:\\n __lock_acquire+0x1509/0x26d0\\n lock_acquire+0x185/0x340\\n down_read+0x98/0x490\\n blkdev_read_iter+0x2a7/0x4e0\\n __kernel_read+0x39a/0xa90\\n freader_fetch+0x1d5/0xa80\\n __build_id_parse.isra.0+0xea/0x6a0\\n do_procmap_query+0xd75/0x1050\\n procfs_procmap_ioctl+0x7a/0xb0\\n __x64_sys_ioctl+0x18e/0x210\\n do_syscall_64+0xcb/0xf80\\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\\n\\n other info that might help us debug this:\\n\\n Possible unsafe locking scenario:\\n\\n CPU0 CPU1\\n ---- ----\\n rlock(\u0026mm-\u003emmap_lock);\\n lock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\\n lock(\u0026mm-\u003emmap_lock);\\n rlock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\\n\\n *** DEADLOCK ***\\n\\nThis seems to be exacerbated (as we haven\u0027t seen these syzbot reports\\nbefore that) by the recent:\\n\\n\\t777a8560fd29 (\\\"lib/buildid: use __kernel_read() for sleepable context\\\")\\n\\nTo make this safe, we need to grab file refcount while VMA is still locked, but\\nother than that everything is pretty straightforward. Internal build_id_parse()\\nAPI assumes VMA is passed, but it only needs the underlying file reference, so\\njust add another variant build_id_parse_file() that expects file passed\\ndirectly.\\n\\n[akpm@linux-foundation.org: fix up kerneldoc]\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\\n\\nprocfs: evitar la obtenci\u00f3n del ID de compilaci\u00f3n mientras se mantiene el bloqueo VMA\\n\\nCorregir PROCMAP_QUERY para obtener el ID de compilaci\u00f3n opcional solo despu\u00e9s de liberar mmap_lock o el bloqueo por VMA, el que se haya utilizado para bloquear el VMA en cuesti\u00f3n, para evitar el interbloqueo informado por syzbot:\\n\\n -\u0026gt; #1 (\u0026amp;mm-\u0026gt;mmap_lock){++++}-{4:4}:\\n __might_fault+0xed/0x170\\n _copy_to_iter+0x118/0x1720\\n copy_page_to_iter+0x12d/0x1e0\\n filemap_read+0x720/0x10a0\\n blkdev_read_iter+0x2b5/0x4e0\\n vfs_read+0x7f4/0xae0\\n ksys_read+0x12a/0x250\\n do_syscall_64+0xcb/0xf80\\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\\n\\n -\u0026gt; #0 (\u0026amp;sb-\u0026gt;s_type-\u0026gt;i_mutex_key#8){++++}-{4:4}:\\n __lock_acquire+0x1509/0x26d0\\n lock_acquire+0x185/0x340\\n down_read+0x98/0x490\\n blkdev_read_iter+0x2a7/0x4e0\\n __kernel_read+0x39a/0xa90\\n freader_fetch+0x1d5/0xa80\\n __build_id_parse.isra.0+0xea/0x6a0\\n do_procmap_query+0xd75/0x1050\\n procfs_procmap_ioctl+0x7a/0xb0\\n __x64_sys_ioctl+0x18e/0x210\\n do_syscall_64+0xcb/0xf80\\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\\n\\n otra informaci\u00f3n que podr\u00eda ayudarnos a depurar esto:\\n\\n Posible escenario de bloqueo inseguro:\\n\\n CPU0 CPU1\\n ---- ----\\n rlock(\u0026amp;mm-\u0026gt;mmap_lock);\\n lock(\u0026amp;sb-\u0026gt;s_type-\u0026gt;i_mutex_key#8);\\n lock(\u0026amp;mm-\u0026gt;mmap_lock);\\n rlock(\u0026amp;sb-\u0026gt;s_type-\u0026gt;i_mutex_key#8);\\n\\n * INTERBLOQUEO *\\n\\nEsto parece exacerbarse (ya que no hab\u00edamos visto estos informes de syzbot antes de eso) por el reciente:\\n\\n\\t777a8560fd29 (\\\"lib/buildid: use __kernel_read() for sleepable context\\\")\\n\\nPara que esto sea seguro, necesitamos tomar el recuento de referencias del archivo mientras el VMA a\u00fan est\u00e1 bloqueado, pero aparte de eso, todo es bastante sencillo. La API interna build_id_parse() asume que se pasa el VMA, pero solo necesita la referencia de archivo subyacente, as\u00ed que solo hay que a\u00f1adir otra variante build_id_parse_file() que espera que el archivo se pase directamente.\\n\\n[akpm@linux-foundation.org: corregir kerneldoc]\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/b5cbacd7f86f4f62b8813688c8e73be94e8e1951\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/b9b97e6aeb534315f9646b2090d1a5024c6a4e82\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/cbc03ce3e6ce7e21214c3f02218213574c1a2d08\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…