GHSA-X6G9-37J8-7QH9
Vulnerability from github – Published: 2025-12-04 18:30 – Updated: 2025-12-04 18:30In the Linux kernel, the following vulnerability has been resolved:
xfs: fix out of bounds memory read error in symlink repair
xfs/286 produced this report on my test fleet:
================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110
Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128
allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ==================================================================
On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because:
(a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8.
Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long.
In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that.
{
"affected": [],
"aliases": [
"CVE-2025-40246"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-04T16:16:17Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfs: fix out of bounds memory read error in symlink repair\n\nxfs/286 produced this report on my test fleet:\n\n ==================================================================\n BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110\n\n Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184):\n memcpy_orig+0x54/0x110\n xrep_symlink_salvage_inline+0xb3/0xf0 [xfs]\n xrep_symlink_salvage+0x100/0x110 [xfs]\n xrep_symlink+0x2e/0x80 [xfs]\n xrep_attempt+0x61/0x1f0 [xfs]\n xfs_scrub_metadata+0x34f/0x5c0 [xfs]\n xfs_ioc_scrubv_metadata+0x387/0x560 [xfs]\n xfs_file_ioctl+0xe23/0x10e0 [xfs]\n __x64_sys_ioctl+0x76/0xc0\n do_syscall_64+0x4e/0x1e0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128\n\n allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago):\n xfs_init_local_fork+0x79/0xe0 [xfs]\n xfs_iformat_local+0xa4/0x170 [xfs]\n xfs_iformat_data_fork+0x148/0x180 [xfs]\n xfs_inode_from_disk+0x2cd/0x480 [xfs]\n xfs_iget+0x450/0xd60 [xfs]\n xfs_bulkstat_one_int+0x6b/0x510 [xfs]\n xfs_bulkstat_iwalk+0x1e/0x30 [xfs]\n xfs_iwalk_ag_recs+0xdf/0x150 [xfs]\n xfs_iwalk_run_callbacks+0xb9/0x190 [xfs]\n xfs_iwalk_ag+0x1dc/0x2f0 [xfs]\n xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs]\n xfs_iwalk+0xa4/0xd0 [xfs]\n xfs_bulkstat+0xfa/0x170 [xfs]\n xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs]\n xfs_file_ioctl+0xbf2/0x10e0 [xfs]\n __x64_sys_ioctl+0x76/0xc0\n do_syscall_64+0x4e/0x1e0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014\n ==================================================================\n\nOn further analysis, I realized that the second parameter to min() is\nnot correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data\nbuffer. if_bytes can be smaller than the data fork size because:\n\n(a) the forkoff code tries to keep the data area as large as possible\n(b) for symbolic links, if_bytes is the ondisk file size + 1\n(c) forkoff is always a multiple of 8.\n\nCase in point: for a single-byte symlink target, forkoff will be\n8 but the buffer will only be 2 bytes long.\n\nIn other words, the logic here is wrong and we walk off the end of the\nincore buffer. Fix that.",
"id": "GHSA-x6g9-37j8-7qh9",
"modified": "2025-12-04T18:30:52Z",
"published": "2025-12-04T18:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40246"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/678e1cc2f482e0985a0613ab4a5bf89c497e5acc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c2d68e091584149fe89bcbaf9b99b3162d46ee7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/81a8685cac4bf081c93a7df591644f4f80240bb9"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.