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
Impacted products
Vendor Product Version
Linux Linux Affected: ed5d583a88a9207b866c14ba834984c6f3c51d23 , < b9b97e6aeb534315f9646b2090d1a5024c6a4e82 (git)
Affected: ed5d583a88a9207b866c14ba834984c6f3c51d23 , < cbc03ce3e6ce7e21214c3f02218213574c1a2d08 (git)
Affected: ed5d583a88a9207b866c14ba834984c6f3c51d23 , < b5cbacd7f86f4f62b8813688c8e73be94e8e1951 (git)
Create a notification for this product.
    Linux Linux Affected: 6.11
Unaffected: 0 , < 6.11 (semver)
Unaffected: 6.12.70 , ≤ 6.12.* (semver)
Unaffected: 6.18.10 , ≤ 6.18.* (semver)
Unaffected: 6.19 , ≤ * (original_commit_for_fix)
Create a notification for this product.
Show details on NVD website

{
  "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\"}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

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…

Detection rules are retrieved from Rulezet.

Loading…

Loading…