VulnerabilityPublished 4 Dec 2025Updated 31 Jul 2026

CVE-2025-40246: Linux kernel · xfs: fix out of bounds memory read error in symlink repair

Affects Linux kernelSource GCVE Database

Not known to be exploited · fixed in 6.17.0-1009.9~24.04.2 : update Linux kernel when convenient.

Data as of 26 Oct 2026, 14:05 UTC

Severity

Medium

Rated by Threat Radar · No CVSS score from NVD or the CNA

EPSS: 0.1% chance of exploitation in 30 days – higher than 9% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch: Available – fixed in 6.17.0-1009.9~24.04.2, 6.17.0-1010.10~24.04.1, 6.17.0-1009.9~24.04.3 +11

Exploitation evidence

Disclosed: evidence found.
CVE published 4 Dec 2025
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

Disclosed: The CVE record is public on cve.org. Its publication is t = 0.
Detectable: A public nuclei template can find exposed instances, for defenders and attackers alike.
Weaponised: Public exploit code exists in Metasploit or Exploit-DB, or CISA SSVC or the CVSS exploit maturity reports a public proof of concept.
Exploited in the wild: CISA KEV lists it, CISA SSVC rates exploitation active, or a source reports attacks.
Observed by OffSeq Mirage: OffSeq Mirage honeypot sensors recorded attack traffic for this CVE, or found exposed hosts without attack traffic.

Moments are spaced evenly, not to scale; a dashed line marks a gap of six months or more. Deltas count from t = 0. Sources that give only a date (CISA KEV, Exploit-DB, or a time of exactly 00:00Z) read “same day” rather than hours. Metasploit modules carry the flaw’s disclosure date, not their release date, and nuclei templates carry no date, so both appear above but not on the timeline.

What to do

Upgrade to a fixed release listed under Affected software.

Patches and advisories

Affected software

Product	Affected	Fixed in
Ubuntu 25.10linux`pkg:deb/ubuntu/linux?arch=source&distro=questing`Other threats	Affected <6.17.0-19.19	Fixed in 6.17.0-19.19
Ubuntu 25.10linux-aws`pkg:deb/ubuntu/linux-aws?arch=source&distro=questing`Other threats	Affected <6.17.0-1009.9	Fixed in 6.17.0-1009.9
Ubuntu 25.10linux-azure`pkg:deb/ubuntu/linux-azure?arch=source&distro=questing`Other threats	Affected <6.17.0-1010.10	Fixed in 6.17.0-1010.10
Ubuntu 25.10linux-azure-fde`pkg:deb/ubuntu/linux-azure-fde?arch=source&distro=questing`Other threats	Affected 6.17.0-1003.3 – 6.17.0-1017.17 10 affected builds	Fixed in–
Ubuntu 25.10linux-gcp`pkg:deb/ubuntu/linux-gcp?arch=source&distro=questing`Other threats	Affected <6.17.0-1009.9	Fixed in 6.17.0-1009.9
Ubuntu 25.10linux-oracle`pkg:deb/ubuntu/linux-oracle?arch=source&distro=questing`Other threats	Affected <6.17.0-1009.9	Fixed in 6.17.0-1009.9

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

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

References

Community reviews

Loading reviews…