CVE-2026-93269 in Linux
Summary
by MITRE • 09/24/2026
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix circular lock dependency in ext4_ext_migrate
Move iput(tmp_inode) after ext4_writepages_up_write() to avoid a circular lock dependency between s_writepages_rwsem and sb_internal (freeze protection).
The deadlock scenario:
CPU0 (EXT4_IOC_MIGRATE) CPU1 (orphan cleanup during mount) ---- ---- ext4_ext_migrate() ext4_writepages_down_write() s_writepages_rwsem (write) ext4_evict_inode() sb_start_intwrite() [sb_internal]
... ext4_writepages() s_writepages_rwsem (read) [BLOCKED]
iput(tmp_inode) ext4_evict_inode() sb_start_intwrite() [BLOCKED]
The tmp_inode is a temporary inode with nlink=0 created solely for building the extent tree. Its eviction does not require s_writepages_rwsem protection, so deferring iput() until after releasing the rwsem is safe.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/24/2026
The Linux kernel ext4 filesystem driver contains a concurrency flaw within the file extent migration logic that can lead to a circular lock dependency deadlock. This vulnerability arises from an incorrect ordering of semaphore acquisitions during inode eviction and writeback operations, specifically involving the s_writepages_rwsem read-write semaphore and the sb_internal freeze protection lock. The issue is triggered when executing the EXT4_IOC_MIGRATE ioctl command while another thread performs orphan cleanup or mount-time operations that require writing to disk pages.
The technical root cause lies in the sequence of locking calls within ext4_ext_migrate. When migrating extents, a temporary inode with zero link count is created solely for constructing the new extent tree structure. The original code path invokes iput on this temporary inode before calling ext4_writepages_up_write. This ordering creates a dangerous lock inversion scenario because iput can trigger evict operations that attempt to acquire sb_start_intwrite, which protects against filesystem freezes and requires holding sb_internal. Simultaneously, the writeback thread holds s_writepages_rwsem in read mode while attempting to call sb_start_intwrite. Since one CPU holds s_writepages_rwsem and waits for sb_internal, while another CPU holds sb_internal (via freeze protection) and waits for s_writepages_rwsem, a classic deadlock occurs where neither process can proceed.
This vulnerability impacts system stability by causing kernel hangs or panics under specific concurrent workloads involving file extent migration and background writeback activities such as orphan cleanup during mount operations. The operational impact includes denial of service through system freeze, requiring manual intervention to reboot the affected machine. Although the temporary inode eviction does not strictly require s_writepages_rwsem protection for data integrity, the current implementation incorrectly assumes that releasing this semaphore before evicting the inode is safe without considering the nested lock dependencies introduced by filesystem freeze mechanisms.
The resolution involves reordering the operations within ext4_ext_migrate to defer the iput call until after ext4_writepages_up_write has released the s_writepages_rwsem read-write semaphore. This ensures that sb_start_intwrite is not called while holding or competing for writeback locks, thereby eliminating the circular dependency. From a classification perspective, this issue aligns with CWE-833 Lock Inversion and CWE-674 Uncontrolled Recursion in terms of concurrency control failures. It also relates to ATT&CK technique T1059 Command and Scripting Interpreter if exploited via local privilege escalation through crafted ioctl calls, though primarily it represents a stability flaw rather than an exploitable security breach for data exfiltration or persistence.
Mitigation strategies include applying the upstream kernel patch that corrects the lock ordering in ext4_ext_migrate. System administrators should ensure their Linux kernels are updated to versions containing this fix. For environments where immediate patching is not feasible, avoiding concurrent execution of file extent migration operations and heavy writeback workloads during mount or orphan cleanup phases can reduce the likelihood of triggering the deadlock condition. Regular monitoring for kernel lockdep warnings in system logs can help identify potential lock inversion issues before they result in full system hangs.