CVE-2025-21942 (GCVE-0-2025-21942)
Vulnerability from cvelistv5
Published
2025-04-01 15:41
Modified
2025-07-06 09:08
Severity ?
Summary
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix extent range end unlock in cow_file_range() Running generic/751 on the for-next branch often results in a hang like below. They are both stack by locking an extent. This suggests someone forget to unlock an extent. INFO: task kworker/u128:1:12 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u128:1 state:D stack:0 pid:12 tgid:12 ppid:2 flags:0x00004000 Workqueue: btrfs-fixup btrfs_work_helper [btrfs] Call Trace: <TASK> __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs] btrfs_work_helper+0xff/0x480 [btrfs] ? lock_release+0x178/0x2c0 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> INFO: task kworker/u134:0:184 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000 Workqueue: writeback wb_workfn (flush-btrfs-4) Call Trace: <TASK> __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 find_lock_delalloc_range+0xdb/0x260 [btrfs] writepage_delalloc+0x12f/0x500 [btrfs] ? srso_return_thunk+0x5/0x5f extent_write_cache_pages+0x232/0x840 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xe7/0x260 ? srso_return_thunk+0x5/0x5f ? lock_acquire+0xd2/0x300 ? srso_return_thunk+0x5/0x5f ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 __writeback_single_inode+0x5c/0x4b0 writeback_sb_inodes+0x22d/0x550 __writeback_inodes_wb+0x4c/0xe0 wb_writeback+0x2f6/0x3f0 wb_workfn+0x32a/0x510 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> This happens because we have another success path for the zoned mode. When there is no active zone available, btrfs_reserve_extent() returns -EAGAIN. In this case, we have two reactions. (1) If the given range is never allocated, we can only wait for someone to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry afterward. (2) Or, if some allocations are already done, we must bail out and let the caller to send IOs for the allocation. This is because these IOs may be necessary to finish a zone. The commit 06f364284794 ("btrfs: do proper folio cleanup when cow_file_range() failed") moved the unlock code from the inside of the loop to the outside. So, previously, the allocated extents are unlocked just after the allocation and so before returning from the function. However, they are no longer unlocked on the case (2) above. That caused the hang issue. Fix the issue by modifying the 'end' to the end of the allocated range. Then, we can exit the loop and the same unlock code can properly handle the case.
References
Impacted products
Vendor Product Version
Linux Linux Version: 10b3772292bf1be45604ba83fd9650eb94382e78
Version: 692cf71173bb41395c855acbbbe197d3aedfa5d4
Version: 06f364284794f149d2abc167c11d556cf20c954b
 Create a notification for this product.
Show details on NVD website

To clipboard 

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/inode.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "5f4863cfb29a7b4fe7625ce148d0b9000b75b802",
              "status": "affected",
              "version": "10b3772292bf1be45604ba83fd9650eb94382e78",
              "versionType": "git"
            },
            {
              "lessThan": "3fcff2f55389306482ab049b4321bda49495e546",
              "status": "affected",
              "version": "692cf71173bb41395c855acbbbe197d3aedfa5d4",
              "versionType": "git"
            },
            {
              "lessThan": "5a4041f2c47247575a6c2e53ce14f7b0ac946c33",
              "status": "affected",
              "version": "06f364284794f149d2abc167c11d556cf20c954b",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/btrfs/inode.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "6.13.7",
              "status": "affected",
              "version": "6.13.2",
              "versionType": "semver"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.13.7",
                  "versionStartIncluding": "6.13.2",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: fix extent range end unlock in cow_file_range()\n\nRunning generic/751 on the for-next branch often results in a hang like\nbelow. They are both stack by locking an extent. This suggests someone\nforget to unlock an extent.\n\n  INFO: task kworker/u128:1:12 blocked for more than 323 seconds.\n        Not tainted 6.13.0-BTRFS-ZNS+ #503\n  \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:kworker/u128:1  state:D stack:0     pid:12    tgid:12    ppid:2      flags:0x00004000\n  Workqueue: btrfs-fixup btrfs_work_helper [btrfs]\n  Call Trace:\n   \u003cTASK\u003e\n   __schedule+0x534/0xdd0\n   schedule+0x39/0x140\n   __lock_extent+0x31b/0x380 [btrfs]\n   ? __pfx_autoremove_wake_function+0x10/0x10\n   btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs]\n   btrfs_work_helper+0xff/0x480 [btrfs]\n   ? lock_release+0x178/0x2c0\n   process_one_work+0x1ee/0x570\n   ? srso_return_thunk+0x5/0x5f\n   worker_thread+0x1d1/0x3b0\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x10b/0x230\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x30/0x50\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   \u003c/TASK\u003e\n  INFO: task kworker/u134:0:184 blocked for more than 323 seconds.\n        Not tainted 6.13.0-BTRFS-ZNS+ #503\n  \"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:kworker/u134:0  state:D stack:0     pid:184   tgid:184   ppid:2      flags:0x00004000\n  Workqueue: writeback wb_workfn (flush-btrfs-4)\n  Call Trace:\n   \u003cTASK\u003e\n   __schedule+0x534/0xdd0\n   schedule+0x39/0x140\n   __lock_extent+0x31b/0x380 [btrfs]\n   ? __pfx_autoremove_wake_function+0x10/0x10\n   find_lock_delalloc_range+0xdb/0x260 [btrfs]\n   writepage_delalloc+0x12f/0x500 [btrfs]\n   ? srso_return_thunk+0x5/0x5f\n   extent_write_cache_pages+0x232/0x840 [btrfs]\n   btrfs_writepages+0x72/0x130 [btrfs]\n   do_writepages+0xe7/0x260\n   ? srso_return_thunk+0x5/0x5f\n   ? lock_acquire+0xd2/0x300\n   ? srso_return_thunk+0x5/0x5f\n   ? find_held_lock+0x2b/0x80\n   ? wbc_attach_and_unlock_inode.part.0+0x102/0x250\n   ? wbc_attach_and_unlock_inode.part.0+0x102/0x250\n   __writeback_single_inode+0x5c/0x4b0\n   writeback_sb_inodes+0x22d/0x550\n   __writeback_inodes_wb+0x4c/0xe0\n   wb_writeback+0x2f6/0x3f0\n   wb_workfn+0x32a/0x510\n   process_one_work+0x1ee/0x570\n   ? srso_return_thunk+0x5/0x5f\n   worker_thread+0x1d1/0x3b0\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x10b/0x230\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x30/0x50\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   \u003c/TASK\u003e\n\nThis happens because we have another success path for the zoned mode. When\nthere is no active zone available, btrfs_reserve_extent() returns\n-EAGAIN. In this case, we have two reactions.\n\n(1) If the given range is never allocated, we can only wait for someone\n    to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry\n    afterward.\n\n(2) Or, if some allocations are already done, we must bail out and let\n    the caller to send IOs for the allocation. This is because these IOs\n    may be necessary to finish a zone.\n\nThe commit 06f364284794 (\"btrfs: do proper folio cleanup when\ncow_file_range() failed\") moved the unlock code from the inside of the\nloop to the outside. So, previously, the allocated extents are unlocked\njust after the allocation and so before returning from the function.\nHowever, they are no longer unlocked on the case (2) above. That caused\nthe hang issue.\n\nFix the issue by modifying the \u0027end\u0027 to the end of the allocated\nrange. Then, we can exit the loop and the same unlock code can properly\nhandle the case."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2025-07-06T09:08:50.894Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/5f4863cfb29a7b4fe7625ce148d0b9000b75b802"
        },
        {
          "url": "https://git.kernel.org/stable/c/3fcff2f55389306482ab049b4321bda49495e546"
        },
        {
          "url": "https://git.kernel.org/stable/c/5a4041f2c47247575a6c2e53ce14f7b0ac946c33"
        }
      ],
      "title": "btrfs: zoned: fix extent range end unlock in cow_file_range()",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2025-21942",
    "datePublished": "2025-04-01T15:41:06.977Z",
    "dateReserved": "2024-12-29T08:45:45.789Z",
    "dateUpdated": "2025-07-06T09:08:50.894Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "nvd": "{\"cve\":{\"id\":\"CVE-2025-21942\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-04-01T16:15:25.100\",\"lastModified\":\"2025-10-30T19:43:56.270\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbtrfs: zoned: fix extent range end unlock in cow_file_range()\\n\\nRunning generic/751 on the for-next branch often results in a hang like\\nbelow. They are both stack by locking an extent. This suggests someone\\nforget to unlock an extent.\\n\\n  INFO: task kworker/u128:1:12 blocked for more than 323 seconds.\\n        Not tainted 6.13.0-BTRFS-ZNS+ #503\\n  \\\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\\\" disables this message.\\n  task:kworker/u128:1  state:D stack:0     pid:12    tgid:12    ppid:2      flags:0x00004000\\n  Workqueue: btrfs-fixup btrfs_work_helper [btrfs]\\n  Call Trace:\\n   \u003cTASK\u003e\\n   __schedule+0x534/0xdd0\\n   schedule+0x39/0x140\\n   __lock_extent+0x31b/0x380 [btrfs]\\n   ? __pfx_autoremove_wake_function+0x10/0x10\\n   btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs]\\n   btrfs_work_helper+0xff/0x480 [btrfs]\\n   ? lock_release+0x178/0x2c0\\n   process_one_work+0x1ee/0x570\\n   ? srso_return_thunk+0x5/0x5f\\n   worker_thread+0x1d1/0x3b0\\n   ? __pfx_worker_thread+0x10/0x10\\n   kthread+0x10b/0x230\\n   ? __pfx_kthread+0x10/0x10\\n   ret_from_fork+0x30/0x50\\n   ? __pfx_kthread+0x10/0x10\\n   ret_from_fork_asm+0x1a/0x30\\n   \u003c/TASK\u003e\\n  INFO: task kworker/u134:0:184 blocked for more than 323 seconds.\\n        Not tainted 6.13.0-BTRFS-ZNS+ #503\\n  \\\"echo 0 \u003e /proc/sys/kernel/hung_task_timeout_secs\\\" disables this message.\\n  task:kworker/u134:0  state:D stack:0     pid:184   tgid:184   ppid:2      flags:0x00004000\\n  Workqueue: writeback wb_workfn (flush-btrfs-4)\\n  Call Trace:\\n   \u003cTASK\u003e\\n   __schedule+0x534/0xdd0\\n   schedule+0x39/0x140\\n   __lock_extent+0x31b/0x380 [btrfs]\\n   ? __pfx_autoremove_wake_function+0x10/0x10\\n   find_lock_delalloc_range+0xdb/0x260 [btrfs]\\n   writepage_delalloc+0x12f/0x500 [btrfs]\\n   ? srso_return_thunk+0x5/0x5f\\n   extent_write_cache_pages+0x232/0x840 [btrfs]\\n   btrfs_writepages+0x72/0x130 [btrfs]\\n   do_writepages+0xe7/0x260\\n   ? srso_return_thunk+0x5/0x5f\\n   ? lock_acquire+0xd2/0x300\\n   ? srso_return_thunk+0x5/0x5f\\n   ? find_held_lock+0x2b/0x80\\n   ? wbc_attach_and_unlock_inode.part.0+0x102/0x250\\n   ? wbc_attach_and_unlock_inode.part.0+0x102/0x250\\n   __writeback_single_inode+0x5c/0x4b0\\n   writeback_sb_inodes+0x22d/0x550\\n   __writeback_inodes_wb+0x4c/0xe0\\n   wb_writeback+0x2f6/0x3f0\\n   wb_workfn+0x32a/0x510\\n   process_one_work+0x1ee/0x570\\n   ? srso_return_thunk+0x5/0x5f\\n   worker_thread+0x1d1/0x3b0\\n   ? __pfx_worker_thread+0x10/0x10\\n   kthread+0x10b/0x230\\n   ? __pfx_kthread+0x10/0x10\\n   ret_from_fork+0x30/0x50\\n   ? __pfx_kthread+0x10/0x10\\n   ret_from_fork_asm+0x1a/0x30\\n   \u003c/TASK\u003e\\n\\nThis happens because we have another success path for the zoned mode. When\\nthere is no active zone available, btrfs_reserve_extent() returns\\n-EAGAIN. In this case, we have two reactions.\\n\\n(1) If the given range is never allocated, we can only wait for someone\\n    to finish a zone, so wait on BTRFS_FS_NEED_ZONE_FINISH bit and retry\\n    afterward.\\n\\n(2) Or, if some allocations are already done, we must bail out and let\\n    the caller to send IOs for the allocation. This is because these IOs\\n    may be necessary to finish a zone.\\n\\nThe commit 06f364284794 (\\\"btrfs: do proper folio cleanup when\\ncow_file_range() failed\\\") moved the unlock code from the inside of the\\nloop to the outside. So, previously, the allocated extents are unlocked\\njust after the allocation and so before returning from the function.\\nHowever, they are no longer unlocked on the case (2) above. That caused\\nthe hang issue.\\n\\nFix the issue by modifying the \u0027end\u0027 to the end of the allocated\\nrange. Then, we can exit the loop and the same unlock code can properly\\nhandle the case.\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs: zoned: fix extent range end unlock in cow_file_range(). Ejecutar generic/751 en la rama for-next suele provocar un bloqueo como el que se muestra a continuaci\u00f3n. Ambas se acumulan bloqueando una extensi\u00f3n. Esto sugiere que alguien olvid\u00f3 desbloquear una extensi\u00f3n. INFORMACI\u00d3N: La tarea kworker/u128:1:12 se bloque\u00f3 durante m\u00e1s de 323 segundos. No contaminada. 6.13.0-BTRFS-ZNS+ #503 \\\"echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\\\" desactiva este mensaje. tarea:kworker/u128:1 estado:D pila:0 pid:12 tgid:12 ppid:2 indicadores:0x00004000 Cola de trabajo: btrfs-fixup btrfs_work_helper [btrfs] Rastreo de llamadas:  __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 btrfs_writepage_fixup_worker+0xf1/0x3a0 [btrfs] btrfs_work_helper+0xff/0x480 [btrfs] ? lock_release+0x178/0x2c0 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30  INFO: task kworker/u134:0:184 blocked for more than 323 seconds. Not tainted 6.13.0-BTRFS-ZNS+ #503 \\\"echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\\\" disables this message. task:kworker/u134:0 state:D stack:0 pid:184 tgid:184 ppid:2 flags:0x00004000 Workqueue: writeback wb_workfn (flush-btrfs-4) Call Trace:  __schedule+0x534/0xdd0 schedule+0x39/0x140 __lock_extent+0x31b/0x380 [btrfs] ? __pfx_autoremove_wake_function+0x10/0x10 find_lock_delalloc_range+0xdb/0x260 [btrfs] writepage_delalloc+0x12f/0x500 [btrfs] ? srso_return_thunk+0x5/0x5f extent_write_cache_pages+0x232/0x840 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xe7/0x260 ? srso_return_thunk+0x5/0x5f ? lock_acquire+0xd2/0x300 ? srso_return_thunk+0x5/0x5f ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 ? wbc_attach_and_unlock_inode.part.0+0x102/0x250 __writeback_single_inode+0x5c/0x4b0 writeback_sb_inodes+0x22d/0x550 __writeback_inodes_wb+0x4c/0xe0 wb_writeback+0x2f6/0x3f0 wb_workfn+0x32a/0x510 process_one_work+0x1ee/0x570 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d1/0x3b0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10b/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30  Esto sucede porque tenemos otra ruta de \u00e9xito para el modo zonificado. Cuando no hay ninguna zona activa disponible, btrfs_reserve_extent() devuelve -EAGAIN. En este caso, tenemos dos reacciones. (1) Si el rango dado nunca se asigna, solo podemos esperar a que alguien complete una zona, por lo que esperamos el bit BTRFS_FS_NEED_ZONE_FINISH y reintentamos despu\u00e9s. (2) O bien, si ya se han realizado algunas asignaciones, debemos abandonar y dejar que el llamador env\u00ede E/S para la asignaci\u00f3n. Esto se debe a que estas E/S pueden ser necesarias para completar una zona. El commit 06f364284794 (\\\"btrfs: realizar la limpieza de folio correcta cuando cow_file_range() falla\\\") movi\u00f3 el c\u00f3digo de desbloqueo del interior del bucle al exterior. Por lo tanto, antes, las extensiones asignadas se desbloqueaban justo despu\u00e9s de la asignaci\u00f3n y, por lo tanto, antes de regresar de la funci\u00f3n. Sin embargo, ya no se desbloquean en el caso (2) mencionado. Esto caus\u00f3 el bloqueo. Para solucionar el problema, modifique \\\"end\\\" al final del rango asignado. De esta manera, podemos salir del bucle y el mismo c\u00f3digo de desbloqueo puede gestionar el caso correctamente.\"}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-835\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.13.2\",\"versionEndExcluding\":\"6.13.7\",\"matchCriteriaId\":\"29216D30-0F8D-48B2-8F91-77DB6C23D506\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"186716B6-2B66-4BD0-852E-D48E71C0C85F\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"0D3E781C-403A-498F-9DA9-ECEE50F41E75\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"66619FB8-0AAF-4166-B2CF-67B24143261D\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"D3D6550E-6679-4560-902D-AF52DCFE905B\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:*\",\"matchCriteriaId\":\"45B90F6B-BEC7-4D4E-883A-9DBADE021750\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/3fcff2f55389306482ab049b4321bda49495e546\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/5a4041f2c47247575a6c2e53ce14f7b0ac946c33\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/5f4863cfb29a7b4fe7625ce148d0b9000b75b802\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]}]}}"
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.