In the Linux kernel, the following vulnerability has been resolved:
ext4: refresh inline data size before write operations
The cached ei->iinlinesize can become stale between the initial size check and when ext4updateinlinedata()/ext4createinlinedata() use it. Although ext4getmaxinlinesize() reads the correct value at the time of the check, concurrent xattr operations can modify iinlinesize before ext4writelock_xattr() is acquired.
This causes ext4updateinlinedata() and ext4createinlinedata() to work with stale capacity values, leading to a BUGON() crash in ext4writeinlinedata():
kernel BUG at fs/ext4/inline.c:1331! BUGON(pos + len > EXT4I(inode)->iinlinesize);
The race window: 1. ext4getmaxinlinesize() reads iinlinesize = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, iinlinesize changes to 40] 4. ext4writelockxattr() acquires lock 5. ext4updateinlinedata() uses stale iinlinesize = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUG_ON() triggers
Fix this by recalculating iinlinesize via ext4findinlinedatanolock() immediately after acquiring xattrsem. This ensures ext4updateinlinedata() and ext4createinline_data() work with current values that are protected from concurrent modifications.
This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inlinedata file while its xattrs are changing") which fixed iinlineoff staleness. This patch addresses the related iinline_size staleness issue.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/68xxx/CVE-2025-68264.json"
}