GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-CR67-QF5C-CF5W

Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2026-06-01 18:31
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode

w/ "mode=lfs" mount option, generic/299 will cause system panic as below:

------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2835! Call Trace: f2fs_allocate_data_block+0x6f4/0xc50 f2fs_map_blocks+0x970/0x1550 f2fs_iomap_begin+0xb2/0x1e0 iomap_iter+0x1d6/0x430 __iomap_dio_rw+0x208/0x9a0 f2fs_file_write_iter+0x6b3/0xfa0 aio_write+0x15d/0x2e0 io_submit_one+0x55e/0xab0 __x64_sys_io_submit+0xa5/0x230 do_syscall_64+0x84/0x2f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0010:new_curseg+0x70f/0x720

The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may trigger foreground gc only if it allocates any physical block, it will be a little bit later when there is multiple threads writing data w/ aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so f2fs_map_blocks() does block allocations aggressively.

In order to fix this issue, let's give a chance to trigger foreground gc in prior to block allocation in f2fs_map_blocks().

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38626"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-22T16:15:36Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode\n\nw/ \"mode=lfs\" mount option, generic/299 will cause system panic as below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/segment.c:2835!\nCall Trace:\n \u003cTASK\u003e\n f2fs_allocate_data_block+0x6f4/0xc50\n f2fs_map_blocks+0x970/0x1550\n f2fs_iomap_begin+0xb2/0x1e0\n iomap_iter+0x1d6/0x430\n __iomap_dio_rw+0x208/0x9a0\n f2fs_file_write_iter+0x6b3/0xfa0\n aio_write+0x15d/0x2e0\n io_submit_one+0x55e/0xab0\n __x64_sys_io_submit+0xa5/0x230\n do_syscall_64+0x84/0x2f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0010:new_curseg+0x70f/0x720\n\nThe root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may\ntrigger foreground gc only if it allocates any physical block, it will be\na little bit later when there is multiple threads writing data w/\naio/dio/bufio method in parallel, since we always use OPU in lfs mode, so\nf2fs_map_blocks() does block allocations aggressively.\n\nIn order to fix this issue, let\u0027s give a chance to trigger foreground\ngc in prior to block allocation in f2fs_map_blocks().",
  "id": "GHSA-cr67-qf5c-cf5w",
  "modified": "2026-06-01T18:31:21Z",
  "published": "2025-08-22T18:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38626"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/1005a3ca28e90c7a64fa43023f866b960a60f791"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/264ede8a52f18647ed5bb5f2bd9bf54f556ad8f5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/385e64a0744584397b4b52b27c96703516f39968"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/82765ce5c7a56f9309ee45328e763610eaf11253"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c737047f4665232d1e26b3620bc62df334545451"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d2f280f43a2a9d918fd23169ff3a6f3b65c7cec5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f289690f50a01c3e085d87853392d5b7436a4cee"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

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.


Loading…