This is probably due to mismatch in types between userspace API struct and the kernel's internal struct, which leads to offset being overflowed after getting converted from __u64 (unsigned long long) to loff_t (signed long long), resulting in ridiculously negative offset value. #syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master --- include/uapi/linux/loop.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/uapi/linux/loop.h b/include/uapi/linux/loop.h index 6f63527dd2ed..33c07c467da4 100644 --- a/include/uapi/linux/loop.h +++ b/include/uapi/linux/loop.h @@ -53,12 +53,12 @@ struct loop_info64 { __u64 lo_device; /* ioctl r/o */ __u64 lo_inode; /* ioctl r/o */ __u64 lo_rdevice; /* ioctl r/o */ - __u64 lo_offset; - __u64 lo_sizelimit;/* bytes, 0 == max available */ - __u32 lo_number; /* ioctl r/o */ - __u32 lo_encrypt_type; /* obsolete, ignored */ - __u32 lo_encrypt_key_size; /* ioctl w/o */ - __u32 lo_flags; + __s64 lo_offset; + __s64 lo_sizelimit; /* bytes, 0 == max available */ + __s32 lo_number; /* ioctl r/o */ + __s32 lo_encrypt_type; /* obsolete, ignored */ + __s32 lo_encrypt_key_size; /* ioctl w/o */ + __s32 lo_flags; __u8 lo_file_name[LO_NAME_SIZE]; __u8 lo_crypt_name[LO_NAME_SIZE]; __u8 lo_encrypt_key[LO_KEY_SIZE]; /* ioctl w/o */ -- 2.35.1
