NFSv4/flexfiles: reject zero filehandle version count
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.261, 5.15.212, 6.1.178, 6.6.145, 6.12.96, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: yes
- Technical impact: partial
Summary
In the Linux kernel, the following vulnerability has been resolved: NFSv4/flexfiles: reject zero filehandle version count ff_layout_alloc_lseg() decodes the filehandle-version array count from the flexfiles layout body. The value is used as the count for kzalloc_objs(), and the current code only rejects NULL. A zero count yields ZERO_SIZE_PTR, which can be stored in dss_info->fh_versions even though later flexfiles paths assume that at least one filehandle version exists. Reject fh_count == 0 before the allocation, matching the existing zero version_count validation in the flexfiles GETDEVICEINFO parser. A QEMU/KASAN run with a malformed flexfiles layout hit: KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:ff_layout_encode_ff_layoutupdate.isra.0+0x15f/0x750 ff_layout_encode_layoutreturn+0x683/0x970 nfs4_xdr_enc_layoutreturn+0x278/0x3a0 Kernel panic - not syncing: Fatal exception The patched kernel rejects the malformed layout without KASAN/oops/panic, and a valid fh_count=1 regression still opens, reads, and unmounts cleanly.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: yes · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
From d67ae825a59d639e4d8b82413af84d854617a87e · fixed in 9033591535c066726f5b505126ccb4068b98fa4f; From d67ae825a59d639e4d8b82413af84d854617a87e · fixed in 18cc6d57a14fa65ab2a2b52279f549041c4bc9cf; From d67ae825a59d639e4d8b82413af84d854617a87e · fixed in be7829715e341b42846437dd9e721005db59f0cc; From d67ae825a59d639e4d8b82413af84d854617a87e · fixed in eeabb9020721db6bc132e68eeae380b8d4fb4b04; From d67ae825a59d639e4d8b82413af84d854617a87e · fixed in 7779c85028a0676fb190cde4f0c540f4f8e97761; From d67ae825a59d639e4d8b82413af84d854617a87e · fixed in d8c90c7cc061265d5f2813a1f5c82ef2f4707e67; From d67ae825a59d639e4d8b82413af84d854617a87e · fixed in 2131ed64b767ffa8bcdb3677d90f3964e39aabc8; From d67ae825a59d639e4d8b82413af84d854617a87e · fixed in 2c6bb3c40bc24f6aa8dfbe6fe98c3ad6389203f2
- Linux Linux
4.0
- KernelLinux
From 4.0.0 · fixed in 5.10.261; From 5.11.0 · fixed in 5.15.212; From 5.16.0 · fixed in 6.1.178; From 6.2.0 · fixed in 6.6.145; From 6.7.0 · fixed in 6.12.96; From 6.13.0 · fixed in 6.18.38; From 6.19.0 · fixed in 7.1.3
References 8
git.kernel.org
- stable/c/9033591535c066726f5b505126ccb4068b98fa4f
- stable/c/18cc6d57a14fa65ab2a2b52279f549041c4bc9cf
- stable/c/be7829715e341b42846437dd9e721005db59f0cc
- stable/c/eeabb9020721db6bc132e68eeae380b8d4fb4b04
- stable/c/7779c85028a0676fb190cde4f0c540f4f8e97761
- stable/c/d8c90c7cc061265d5f2813a1f5c82ef2f4707e67
- stable/c/2131ed64b767ffa8bcdb3677d90f3964e39aabc8
- stable/c/2c6bb3c40bc24f6aa8dfbe6fe98c3ad6389203f2