ghsa-p7jq-2wv5-rrmc
Vulnerability from github
Published
2025-08-30 12:30
Modified
2025-08-30 12:30
Details

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

f2fs: fix to avoid out-of-boundary access in dnode page

As Jiaming Zhang reported:

__dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x17e/0x800 mm/kasan/report.c:480 kasan_report+0x147/0x180 mm/kasan/report.c:593 data_blkaddr fs/f2fs/f2fs.h:3053 [inline] f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline] f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855 f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195 prepare_write_begin fs/f2fs/data.c:3395 [inline] f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594 generic_perform_write+0x2c7/0x910 mm/filemap.c:4112 f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline] f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x546/0xa90 fs/read_write.c:686 ksys_write+0x149/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The root cause is in the corrupted image, there is a dnode has the same node id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to access block address in dnode at offset 934, however it parses the dnode as inode node, so that get_dnode_addr() returns 360, then it tries to access page address from 360 + 934 * 4 = 4096 w/ 4 bytes.

To fix this issue, let's add sanity check for node id of all direct nodes during f2fs_get_dnode_of_data().

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-38677"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-30T10:15:36Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid out-of-boundary access in dnode page\n\nAs Jiaming Zhang reported:\n\n \u003cTASK\u003e\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x17e/0x800 mm/kasan/report.c:480\n kasan_report+0x147/0x180 mm/kasan/report.c:593\n data_blkaddr fs/f2fs/f2fs.h:3053 [inline]\n f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline]\n f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855\n f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195\n prepare_write_begin fs/f2fs/data.c:3395 [inline]\n f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594\n generic_perform_write+0x2c7/0x910 mm/filemap.c:4112\n f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline]\n f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x546/0xa90 fs/read_write.c:686\n ksys_write+0x149/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe root cause is in the corrupted image, there is a dnode has the same\nnode id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to\naccess block address in dnode at offset 934, however it parses the dnode\nas inode node, so that get_dnode_addr() returns 360, then it tries to\naccess page address from 360 + 934 * 4 = 4096 w/ 4 bytes.\n\nTo fix this issue, let\u0027s add sanity check for node id of all direct nodes\nduring f2fs_get_dnode_of_data().",
  "id": "GHSA-p7jq-2wv5-rrmc",
  "modified": "2025-08-30T12:30:28Z",
  "published": "2025-08-30T12:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38677"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6b7784ea07e6aa044f74b39d6b5af5e28746fc81"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/77de19b6867f2740cdcb6c9c7e50d522b47847a4"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/888aa660144bcb6ec07839da756ee46bfcf7fc53"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/901f62efd6e855f93d8b1175540f29f4dc45ba55"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/92ef491b506a0f4dd971a3a76f86f2d8f5370180"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a650654365c57407413e9b1f6ff4d539bf2e99ca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee4d13f5407cbdf1216cc258f45492075713889a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f1d5093d9fe9f3c74c123741c88666cc853b79c5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


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.
  • 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.