FKIE_CVE-2026-23267

Vulnerability from fkie_nvd - Published: 2026-03-18 18:16 - Updated: 2026-06-17 10:21
Severity
5.5 (Medium) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Summary
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes During SPO tests, when mounting F2FS, an -EINVAL error was returned from f2fs_recover_inode_page. The issue occurred under the following scenario Thread A Thread B f2fs_ioc_commit_atomic_write - f2fs_do_sync_file // atomic = true - f2fs_fsync_node_pages : last_folio = inode folio : schedule before folio_lock(last_folio) f2fs_write_checkpoint - block_operations// writeback last_folio - schedule before f2fs_flush_nat_entries : set_fsync_mark(last_folio, 1) : set_dentry_mark(last_folio, 1) : folio_mark_dirty(last_folio) - __write_node_folio(last_folio) : f2fs_down_read(&sbi->node_write)//block - f2fs_flush_nat_entries : {struct nat_entry}->flag |= BIT(IS_CHECKPOINTED) - unblock_operations : f2fs_up_write(&sbi->node_write) f2fs_write_checkpoint//return : f2fs_do_write_node_page() f2fs_ioc_commit_atomic_write//return SPO Thread A calls f2fs_need_dentry_mark(sbi, ino), and the last_folio has already been written once. However, the {struct nat_entry}->flag did not have the IS_CHECKPOINTED set, causing set_dentry_mark(last_folio, 1) and write last_folio again after Thread B finishes f2fs_write_checkpoint. After SPO and reboot, it was detected that {struct node_info}->blk_addr was not NULL_ADDR because Thread B successfully write the checkpoint. This issue only occurs in atomic write scenarios. For regular file fsync operations, the folio must be dirty. If block_operations->f2fs_sync_node_pages successfully submit the folio write, this path will not be executed. Otherwise, the f2fs_write_checkpoint will need to wait for the folio write submission to complete, as sbi->nr_pages[F2FS_DIRTY_NODES] > 0. Therefore, the situation where f2fs_need_dentry_mark checks that the {struct nat_entry}->flag /wo the IS_CHECKPOINTED flag, but the folio write has already been submitted, will not occur. Therefore, for atomic file fsync, sbi->node_write should be acquired through __write_node_folio to ensure that the IS_CHECKPOINTED flag correctly indicates that the checkpoint write has been completed.
References
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/32bc3c9fe18881d50dd51fd5f26d19fe1190dc0dPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/75e19da068adf0dc5dd269dd157392434b9117d4Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/7633a7387eb4d0259d6bea945e1d3469cd135bbcPatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/962c167b0f262b9962207fbeaa531721d55ea00ePatch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/bd66b4c487d5091d2a65d6089e0de36f0c26a4c7Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67https://git.kernel.org/stable/c/ed81bc5885460905f9160e7b463e5708fd056324Patch
Impacted products
Vendor Product Version
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
linux linux_kernel *
To clipboard 

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "fs/f2fs/node.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "32bc3c9fe18881d50dd51fd5f26d19fe1190dc0d",
              "status": "affected",
              "version": "608514deba38c8611ad330d6a3c8e2b9a1f68e4b",
              "versionType": "git"
            },
            {
              "lessThan": "75e19da068adf0dc5dd269dd157392434b9117d4",
              "status": "affected",
              "version": "608514deba38c8611ad330d6a3c8e2b9a1f68e4b",
              "versionType": "git"
            },
            {
              "lessThan": "962c167b0f262b9962207fbeaa531721d55ea00e",
              "status": "affected",
              "version": "608514deba38c8611ad330d6a3c8e2b9a1f68e4b",
              "versionType": "git"
            },
            {
              "lessThan": "bd66b4c487d5091d2a65d6089e0de36f0c26a4c7",
              "status": "affected",
              "version": "608514deba38c8611ad330d6a3c8e2b9a1f68e4b",
              "versionType": "git"
            },
            {
              "lessThan": "ed81bc5885460905f9160e7b463e5708fd056324",
              "status": "affected",
              "version": "608514deba38c8611ad330d6a3c8e2b9a1f68e4b",
              "versionType": "git"
            },
            {
              "lessThan": "7633a7387eb4d0259d6bea945e1d3469cd135bbc",
              "status": "affected",
              "version": "608514deba38c8611ad330d6a3c8e2b9a1f68e4b",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "fs/f2fs/node.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.7"
            },
            {
              "lessThan": "4.7",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.164",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.127",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.74",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.13",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.19.*",
              "status": "unaffected",
              "version": "6.19.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.0",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "BE35EE84-2282-476E-BE47-D8C91A42BD5C",
              "versionEndExcluding": "6.1.164",
              "versionStartIncluding": "4.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "4A9F36A3-A685-48A0-84B4-6217052BD058",
              "versionEndExcluding": "6.6.127",
              "versionStartIncluding": "6.2",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "C2968F55-D03F-42BE-A694-F0A37BC8CBE3",
              "versionEndExcluding": "6.12.74",
              "versionStartIncluding": "6.7",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "6BDEF9FB-423E-49F6-991B-9277CC3AF400",
              "versionEndExcluding": "6.18.13",
              "versionStartIncluding": "6.13",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "7853A337-FB2A-4E19-AB47-4E38343532AA",
              "versionEndExcluding": "6.19.3",
              "versionStartIncluding": "6.19",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes\n\nDuring SPO tests, when mounting F2FS, an -EINVAL error was returned from\nf2fs_recover_inode_page. The issue occurred under the following scenario\n\nThread A                                     Thread B\nf2fs_ioc_commit_atomic_write\n - f2fs_do_sync_file // atomic = true\n  - f2fs_fsync_node_pages\n    : last_folio = inode folio\n    : schedule before folio_lock(last_folio) f2fs_write_checkpoint\n                                              - block_operations// writeback last_folio\n                                              - schedule before f2fs_flush_nat_entries\n    : set_fsync_mark(last_folio, 1)\n    : set_dentry_mark(last_folio, 1)\n    : folio_mark_dirty(last_folio)\n    - __write_node_folio(last_folio)\n      : f2fs_down_read(\u0026sbi-\u003enode_write)//block\n                                              - f2fs_flush_nat_entries\n                                                : {struct nat_entry}-\u003eflag |= BIT(IS_CHECKPOINTED)\n                                              - unblock_operations\n                                                : f2fs_up_write(\u0026sbi-\u003enode_write)\n                                             f2fs_write_checkpoint//return\n      : f2fs_do_write_node_page()\nf2fs_ioc_commit_atomic_write//return\n                                             SPO\n\nThread A calls f2fs_need_dentry_mark(sbi, ino), and the last_folio has\nalready been written once. However, the {struct nat_entry}-\u003eflag did not\nhave the IS_CHECKPOINTED set, causing set_dentry_mark(last_folio, 1) and\nwrite last_folio again after Thread B finishes f2fs_write_checkpoint.\n\nAfter SPO and reboot, it was detected that {struct node_info}-\u003eblk_addr\nwas not NULL_ADDR because Thread B successfully write the checkpoint.\n\nThis issue only occurs in atomic write scenarios. For regular file\nfsync operations, the folio must be dirty. If\nblock_operations-\u003ef2fs_sync_node_pages successfully submit the folio\nwrite, this path will not be executed. Otherwise, the\nf2fs_write_checkpoint will need to wait for the folio write submission\nto complete, as sbi-\u003enr_pages[F2FS_DIRTY_NODES] \u003e 0. Therefore, the\nsituation where f2fs_need_dentry_mark checks that the {struct\nnat_entry}-\u003eflag /wo the IS_CHECKPOINTED flag, but the folio write has\nalready been submitted, will not occur.\n\nTherefore, for atomic file fsync, sbi-\u003enode_write should be acquired\nthrough __write_node_folio to ensure that the IS_CHECKPOINTED flag\ncorrectly indicates that the checkpoint write has been completed."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nf2fs: corrige el problema de inconsistencia del flag IS_CHECKPOINTED causado por escrituras concurrentes de commit at\u00f3mico y checkpoint\n\nDurante las pruebas SPO, al montar F2FS, se devolvi\u00f3 un error -EINVAL desde\nf2fs_recover_inode_page. El problema ocurri\u00f3 bajo el siguiente escenario\n\nHilo A                                     Hilo B\nf2fs_ioc_commit_atomic_write\n - f2fs_do_sync_file // at\u00f3mico = true\n  - f2fs_fsync_node_pages\n    : last_folio = inode folio\n    : schedule before folio_lock(last_folio) f2fs_write_checkpoint\n                                              - block_operations// writeback last_folio\n                                              - schedule before f2fs_flush_nat_entries\n    : set_fsync_mark(last_folio, 1)\n    : set_dentry_mark(last_folio, 1)\n    : folio_mark_dirty(last_folio)\n    - __write_node_folio(last_folio)\n      : f2fs_down_read(\u0026amp;sbi-\u0026gt;node_write)//bloquea\n                                              - f2fs_flush_nat_entries\n                                                : {struct nat_entry}-\u0026gt;flag |= BIT(IS_CHECKPOINTED)\n                                              - unblock_operations\n                                                : f2fs_up_write(\u0026amp;sbi-\u0026gt;node_write)\n                                             f2fs_write_checkpoint//retorna\n      : f2fs_do_write_node_page()\nf2fs_ioc_commit_atomic_write//retorna\n                                             SPO\n\nEl Hilo A llama a f2fs_need_dentry_mark(sbi, ino), y el last_folio ya ha\nsido escrito una vez. Sin embargo, el {struct nat_entry}-\u0026gt;flag no ten\u00eda\nel IS_CHECKPOINTED establecido, causando que set_dentry_mark(last_folio, 1) y\nse escriba last_folio de nuevo despu\u00e9s de que el Hilo B termine f2fs_write_checkpoint.\n\nDespu\u00e9s de SPO y el reinicio, se detect\u00f3 que {struct node_info}-\u0026gt;blk_addr\nno era NULL_ADDR porque el Hilo B escribi\u00f3 exitosamente el checkpoint.\n\nEste problema solo ocurre en escenarios de escritura at\u00f3mica. Para operaciones\nfsync de archivos regulares, el folio debe estar sucio. Si\nblock_operations-\u0026gt;f2fs_sync_node_pages env\u00eda exitosamente la escritura del folio,\nesta ruta no se ejecutar\u00e1. De lo contrario, f2fs_write_checkpoint deber\u00e1 esperar\na que se complete el env\u00edo de la escritura del folio, ya que\nsbi-\u0026gt;nr_pages[F2FS_DIRTY_NODES] \u0026gt; 0. Por lo tanto, la situaci\u00f3n en la que\nf2fs_need_dentry_mark verifica que el {struct nat_entry}-\u0026gt;flag sin el flag\nIS_CHECKPOINTED, pero la escritura del folio ya ha sido enviada, no ocurrir\u00e1.\n\nPor lo tanto, para fsync de archivos at\u00f3micos, sbi-\u0026gt;node_write debe adquirirse\na trav\u00e9s de __write_node_folio para asegurar que el flag IS_CHECKPOINTED\nindique correctamente que la escritura del checkpoint ha sido completada."
    }
  ],
  "id": "CVE-2026-23267",
  "lastModified": "2026-06-17T10:21:13.140",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ]
  },
  "published": "2026-03-18T18:16:25.573",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/32bc3c9fe18881d50dd51fd5f26d19fe1190dc0d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/75e19da068adf0dc5dd269dd157392434b9117d4"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/7633a7387eb4d0259d6bea945e1d3469cd135bbc"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/962c167b0f262b9962207fbeaa531721d55ea00e"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/bd66b4c487d5091d2a65d6089e0de36f0c26a4c7"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/ed81bc5885460905f9160e7b463e5708fd056324"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "NVD-CWE-noinfo"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.