CVE-2025-68264

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: refresh inline data size before write operations<br /> <br /> The cached ei-&gt;i_inline_size can become stale between the initial size<br /> check and when ext4_update_inline_data()/ext4_create_inline_data() use<br /> it. Although ext4_get_max_inline_size() reads the correct value at the<br /> time of the check, concurrent xattr operations can modify i_inline_size<br /> before ext4_write_lock_xattr() is acquired.<br /> <br /> This causes ext4_update_inline_data() and ext4_create_inline_data() to<br /> work with stale capacity values, leading to a BUG_ON() crash in<br /> ext4_write_inline_data():<br /> <br /> kernel BUG at fs/ext4/inline.c:1331!<br /> BUG_ON(pos + len &gt; EXT4_I(inode)-&gt;i_inline_size);<br /> <br /> The race window:<br /> 1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)<br /> 2. Size check passes for 50-byte write<br /> 3. [Another thread adds xattr, i_inline_size changes to 40]<br /> 4. ext4_write_lock_xattr() acquires lock<br /> 5. ext4_update_inline_data() uses stale i_inline_size = 60<br /> 6. Attempts to write 50 bytes but only 40 bytes actually available<br /> 7. BUG_ON() triggers<br /> <br /> Fix this by recalculating i_inline_size via ext4_find_inline_data_nolock()<br /> immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()<br /> and ext4_create_inline_data() work with current values that are protected<br /> from concurrent modifications.<br /> <br /> This is similar to commit a54c4613dac1 ("ext4: fix race writing to an<br /> inline_data file while its xattrs are changing") which fixed i_inline_off<br /> staleness. This patch addresses the related i_inline_size staleness issue.