CVE-2026-93269: ext4: fix circular lock dependency in ext4_ext_migrate
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix circular lock dependency in ext4extmigrate
Move iput(tmpinode) after ext4writepagesupwrite() to avoid a circular lock dependency between swritepagesrwsem and sbinternal (freeze protection).
The deadlock scenario:
CPU0 (EXT4IOCMIGRATE) CPU1 (orphan cleanup during mount) ---- ---- ext4extmigrate() ext4writepagesdownwrite() swritepagesrwsem (write) ext4evictinode() sbstartintwrite() [sbinternal] ... ext4writepages() swritepagesrwsem (read) [BLOCKED] iput(tmpinode) ext4evictinode() sbstartintwrite() [BLOCKED]
The tmpinode is a temporary inode with nlink=0 created solely for building the extent tree. Its eviction does not require swritepagesrwsem protection, so deferring iput() until after releasing the rwsem is safe.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to trigger the deadlock?
One CPU must run the EXT4_IOC_MIGRATE path in ext4_ext_migrate while another performs orphan cleanup during mount. The lock inversion involves ext4's s_writepages_rwsem and the filesystem freeze-protection lock, sb_internal.
Is this an exposure to untrusted remote attackers?
The provided information describes a kernel deadlock caused by concurrent filesystem operations, not a remote attack path. It does not identify any network-facing trigger, required privileges, or attacker-controlled input.
What is the practical impact if the issue occurs?
The affected operations can block each other in a circular lock dependency: migration waits for writepages locking while temporary inode eviction waits for freeze protection. This can result in a filesystem or kernel operation hang.
What does the fix change?
The fix defers iput(tmp_inode) until after ext4_writepages_up_write() releases s_writepages_rwsem. The temporary inode has no links and is used only to build the extent tree, so its eviction can safely occur after that lock is released.