ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT
- 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 6.6.160, 6.12.97, 6.18.57, 7.1.5
- 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: ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT Reject the EXT4_IOC_MOVE_EXT ioctl early if the donor file does not belong to the same superblock as the original file. Currently, this validation is performed inside ext4_move_extents() by mext_check_validity(), but only after lock_two_nondirectories() has already acquired the inode locks. When the donor fd refers to a file on a different filesystem (e.g., overlayfs), this late validation creates a circular lock dependency: CPU0 (overlayfs write) CPU1 (ext4 ioctl) ---- ---- inode_lock(ovl_inode) mnt_want_write_file(filp) sb_start_write(ext4_sb) [sb_writers] backing_file_write_iter() vfs_iter_write(real_file) file_start_write(real_file) sb_start_write(ext4_sb) [blocked by freeze] lock_two_nondirectories() inode_lock(ovl_inode) [blocked] With a concurrent freeze operation holding sb_writers write side, this forms a deadlock cycle: CPU0 waits for freeze to complete, freeze waits for CPU1's sb_writers reader to exit, CPU1 waits for CPU0's inode lock. Since EXT4_IOC_MOVE_EXT exchanges physical extents between two files, it fundamentally requires both files to reside on the same ext4 filesystem. Moving the superblock check before any lock acquisition is both semantically correct and eliminates the circular dependency by ensuring that cross-filesystem donor fds are rejected before sb_writers or inode locks are taken.
Timeline
- CVE published
- Record last updated
Affected versions
- Linux Linux
From fcf6b1b729bcd23f2b49a84fb33ffbb44712ee6a · fixed in 663f184b51492093d408e518efc95ee13b5b4440; From fcf6b1b729bcd23f2b49a84fb33ffbb44712ee6a · fixed in 74796e886ca39fcb0d3fd36ea6a39c62784ab6fb; From fcf6b1b729bcd23f2b49a84fb33ffbb44712ee6a · fixed in 29e07ec352f0ad06c833a18bf47d82c81f55544f; From fcf6b1b729bcd23f2b49a84fb33ffbb44712ee6a · fixed in fb52013cad9e9b7d3a6a14ea1bcd841e41da7c6c; From fcf6b1b729bcd23f2b49a84fb33ffbb44712ee6a · fixed in c143957520c6c9b5cd72e0de8b52b814f0c576fe
- Linux Linux
3.18
- KernelLinux
From 3.18.0 · fixed in 6.6.160; From 6.7.0 · fixed in 6.12.97; From 6.13.0 · fixed in 6.18.57; From 6.19.0 · fixed in 7.1.5