On Mon, Nov 25, 2024 at 07:16:41PM +0800, Chao Yu wrote:
>
> I'm fine w/ this change, but I didn't get it, how did above commit introduce
> this bug?
Hello Chao,
The commit from the bisect didn't exactly introduce this bug, since it
would still be possible to make a different image that does the exact
same thing in the older code.
This commit was blamed in the bisect because it changes the layout of
struct f2fs_inode:
> @@ -271,6 +272,10 @@ struct f2fs_inode {
> __le32 i_inode_checksum;/* inode meta checksum */
> __le64 i_crtime; /* creation time */
> __le32 i_crtime_nsec; /* creation time in nano scale
> */
>+ __le64 i_compr_blocks; /* # of compressed blocks */
>+ __u8 i_compress_algorithm; /* compress algorithm */
>+ __u8 i_log_cluster_size; /* log of cluster size
>*/
>+ __le16 i_padding; /* padding */
> __le32 i_extra_end[0]; /* for attribute size
> calculation */
> } __packed;
> __le32 i_addr[DEF_ADDRS_PER_INODE]; /* Pointers to data
> blocks */
This changes F2FS_TOTAL_EXTRA_ATTR_SIZE, which allows the syzbot
reproducer's inode to pass the sanity check for corrupted i_extra_size.
Before this change, the inode gets rejected as corrupt:
>[ 62.794566][ T9662] F2FS-fs (loop0): sanity_check_inode: inode (ino=7) has
>corrupted i_extra_isize: 36, max: 24
Thanks,
Leo
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
