CVE-2024-49958

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: reserve space for inline xattr before attaching reflink tree<br /> <br /> One of our customers reported a crash and a corrupted ocfs2 filesystem. <br /> The crash was due to the detection of corruption. Upon troubleshooting,<br /> the fsck -fn output showed the below corruption<br /> <br /> [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,<br /> but fsck believes the largest valid value is 227. Clamp the next record value? n<br /> <br /> The stat output from the debugfs.ocfs2 showed the following corruption<br /> where the "Next Free Rec:" had overshot the "Count:" in the root metadata<br /> block.<br /> <br /> Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856)<br /> FS Generation: 904309833 (0x35e6ac49)<br /> CRC32: 00000000 ECC: 0000<br /> Type: Regular Attr: 0x0 Flags: Valid<br /> Dynamic Features: (0x16) HasXattr InlineXattr Refcounted<br /> Extended Attributes Block: 0 Extended Attributes Inline Size: 256<br /> User: 0 (root) Group: 0 (root) Size: 281320357888<br /> Links: 1 Clusters: 141738<br /> ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024<br /> atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024<br /> mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024<br /> dtime: 0x0 -- Wed Dec 31 17:00:00 1969<br /> Refcount Block: 2777346<br /> Last Extblk: 2886943 Orphan Slot: 0<br /> Sub Alloc Slot: 0 Sub Alloc Bit: 14<br /> Tree Depth: 1 Count: 227 Next Free Rec: 230<br /> ## Offset Clusters Block#<br /> 0 0 2310 2776351<br /> 1 2310 2139 2777375<br /> 2 4449 1221 2778399<br /> 3 5670 731 2779423<br /> 4 6401 566 2780447<br /> ....... .... .......<br /> ....... .... .......<br /> <br /> The issue was in the reflink workfow while reserving space for inline<br /> xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the<br /> time this function is called the reflink tree is already recreated at the<br /> destination inode from the source inode. At this point, this function<br /> reserves space for inline xattrs at the destination inode without even<br /> checking if there is space at the root metadata block. It simply reduces<br /> the l_count from 243 to 227 thereby making space of 256 bytes for inline<br /> xattr whereas the inode already has extents beyond this index (in this<br /> case up to 230), thereby causing corruption.<br /> <br /> The fix for this is to reserve space for inline metadata at the destination<br /> inode before the reflink tree gets recreated. The customer has verified the<br /> fix.