CVE-2023-52933

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: fix handling and sanity checking of xattr_ids count<br /> <br /> A Sysbot [1] corrupted filesystem exposes two flaws in the handling and<br /> sanity checking of the xattr_ids count in the filesystem. Both of these<br /> flaws cause computation overflow due to incorrect typing.<br /> <br /> In the corrupted filesystem the xattr_ids value is 4294967071, which<br /> stored in a signed variable becomes the negative number -225.<br /> <br /> Flaw 1 (64-bit systems only):<br /> <br /> The signed integer xattr_ids variable causes sign extension.<br /> <br /> This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The<br /> variable is first multiplied by sizeof(struct squashfs_xattr_id) where the<br /> type of the sizeof operator is "unsigned long".<br /> <br /> On a 64-bit system this is 64-bits in size, and causes the negative number<br /> to be sign extended and widened to 64-bits and then become unsigned. This<br /> produces the very large number 18446744073709548016 or 2^64 - 3600. This<br /> number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and<br /> divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0<br /> (stored in len).<br /> <br /> Flaw 2 (32-bit systems only):<br /> <br /> On a 32-bit system the integer variable is not widened by the unsigned<br /> long type of the sizeof operator (32-bits), and the signedness of the<br /> variable has no effect due it always being treated as unsigned.<br /> <br /> The above corrupted xattr_ids value of 4294967071, when multiplied<br /> overflows and produces the number 4294963696 or 2^32 - 3400. This number<br /> when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by<br /> SQUASHFS_METADATA_SIZE overflows again and produces a length of 0.<br /> <br /> The effect of the 0 length computation:<br /> <br /> In conjunction with the corrupted xattr_ids field, the filesystem also has<br /> a corrupted xattr_table_start value, where it matches the end of<br /> filesystem value of 850.<br /> <br /> This causes the following sanity check code to fail because the<br /> incorrectly computed len of 0 matches the incorrect size of the table<br /> reported by the superblock (0 bytes).<br /> <br /> len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids);<br /> indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids);<br /> <br /> /*<br /> * The computed size of the index table (len bytes) should exactly<br /> * match the table start and end points<br /> */<br /> start = table_start + sizeof(*id_table);<br /> end = msblk-&gt;bytes_used;<br /> <br /> if (len != (end - start))<br /> return ERR_PTR(-EINVAL);<br /> <br /> Changing the xattr_ids variable to be "usigned int" fixes the flaw on a<br /> 64-bit system. This relies on the fact the computation is widened by the<br /> unsigned long type of the sizeof operator.<br /> <br /> Casting the variable to u64 in the above macro fixes this flaw on a 32-bit<br /> system.<br /> <br /> It also means 64-bit systems do not implicitly rely on the type of the<br /> sizeof operator to widen the computation.<br /> <br /> [1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/