ufs: validate cylinder group metadata before caching it
- 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.271, 5.15.222, 6.1.189, 6.6.158, 6.12.111, 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
Summary
In the Linux kernel, the following vulnerability has been resolved: ufs: validate cylinder group metadata before caching it ufs_read_cylinder() copies the cylinder group index and the rotor positions straight from the on-disk group and caches them without any check: ucpi->c_cgx = fs32_to_cpu(sb, ucg->cg_cgx); ucpi->c_rotor = fs32_to_cpu(sb, ucg->cg_rotor); ucpi->c_frotor = fs32_to_cpu(sb, ucg->cg_frotor); ucpi->c_irotor = fs32_to_cpu(sb, ucg->cg_irotor); They are then used as indices during allocation and free: • c_cgx indexes the cylinder summary array as UFS_SB(sb)->fs_cs(ucpi->c_cgx), so a value past s_ncg writes a 32 bit count outside the s_csp allocation. • c_frotor becomes a bitmap scan start, start = c_frotor >> 3, and then length = ((s_fpg + 7) >> 3) - start. A start beyond the block bitmap wraps the unsigned length to a huge value, so ubh_scanc() walks far past the cylinder group buffers. c_irotor drives the inode bitmap the same way. A crafted image can set any of these freely, turning an ordinary allocation into an out of bounds access. Reject a cylinder group whose recorded index does not match the group being read, or whose rotors fall outside the group, before the metadata is cached. Valid filesystems keep cg_cgx equal to the group number and the rotors within the group, so only malformed images are rejected.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in 88cccb6beba136b73f0caf80e59457e1b3c0ca1e; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in f560a9e33365c460827c735fd86435f9213f1aed; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in e4c5cc9688c3e69d07d888853388549ae26c0521; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in 58c0c414b2b8d099d33da494a354fa836ca6c10b; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in 5902a95066883cf96fa15b2680694fc5dd0c7d11; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in 87b12dc360a002eb2d498aa4f01e84347019612d; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in abde9eb33106850dfa367ad3965d3588bb8558d5; From 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 · fixed in c9d263be26806d388129fab8c6904bed197fc6af
- Linux Linux
2.6.12
- KernelLinux
From 2.6.12 · fixed in 5.10.271; From 5.11.0 · fixed in 5.15.222; From 5.16.0 · fixed in 6.1.189; From 6.2.0 · fixed in 6.6.158; From 6.7.0 · fixed in 6.12.111; From 6.13.0 · fixed in 6.18.53; From 6.19.0 · fixed in 7.2.7
References 8
git.kernel.org
- stable/c/88cccb6beba136b73f0caf80e59457e1b3c0ca1e
- stable/c/f560a9e33365c460827c735fd86435f9213f1aed
- stable/c/e4c5cc9688c3e69d07d888853388549ae26c0521
- stable/c/58c0c414b2b8d099d33da494a354fa836ca6c10b
- stable/c/5902a95066883cf96fa15b2680694fc5dd0c7d11
- stable/c/87b12dc360a002eb2d498aa4f01e84347019612d
- stable/c/abde9eb33106850dfa367ad3965d3588bb8558d5
- stable/c/c9d263be26806d388129fab8c6904bed197fc6af