Hello,
syzbot found the following issue on:
HEAD commit: 457391b03803 Linux 6.3
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13226cf0280000
kernel config: https://syzkaller.appspot.com/x/.config?x=8c81c9a3d360ebcf
dashboard link: https://syzkaller.appspot.com/bug?extid=702361cf7e3d95758761
compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/6438dcb1c42d/disk-457391b0.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/20596c249e47/vmlinux-457391b0.xz
kernel image: https://storage.googleapis.com/syzbot-assets/cb715366a3e5/bzImage-457391b0.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
==================================================================
BUG: KCSAN: data-race in generic_fillattr / shmem_mknod
read-write to 0xffff8881049a9408 of 8 bytes by task 3383 on cpu 0:
shmem_mknod+0xdd/0x180 mm/shmem.c:2942
shmem_create+0x34/0x40 mm/shmem.c:2994
lookup_open fs/namei.c:3416 [inline]
open_last_lookups fs/namei.c:3484 [inline]
path_openat+0xd96/0x1d00 fs/namei.c:3712
do_filp_open+0xf6/0x200 fs/namei.c:3742
do_sys_openat2+0xb5/0x2a0 fs/open.c:1348
do_sys_open fs/open.c:1364 [inline]
__do_sys_openat fs/open.c:1380 [inline]
__se_sys_openat fs/open.c:1375 [inline]
__x64_sys_openat+0xf3/0x120 fs/open.c:1375
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffff8881049a9408 of 8 bytes by task 4291 on cpu 1:
i_size_read include/linux/fs.h:866 [inline]
generic_fillattr+0x13f/0x1e0 fs/stat.c:58
shmem_getattr+0x32a/0x3b0 mm/shmem.c:1068
vfs_getattr_nosec+0x1e3/0x3c0 fs/stat.c:133
vfs_getattr fs/stat.c:170 [inline]
vfs_statx+0x156/0x300 fs/stat.c:242
vfs_fstatat fs/stat.c:276 [inline]
__do_sys_newfstatat fs/stat.c:446 [inline]
__se_sys_newfstatat+0x8a/0x2a0 fs/stat.c:440
__x64_sys_newfstatat+0x55/0x60 fs/stat.c:440
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x0000000000001644 -> 0x0000000000001658
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 4291 Comm: udevd Not tainted 6.3.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
==================================================================
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
On Mon, 24 Apr 2023 at 09:58, syzbot
<[email protected]> wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 457391b03803 Linux 6.3
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13226cf0280000
> kernel config: https://syzkaller.appspot.com/x/.config?x=8c81c9a3d360ebcf
> dashboard link: https://syzkaller.appspot.com/bug?extid=702361cf7e3d95758761
> compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/6438dcb1c42d/disk-457391b0.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/20596c249e47/vmlinux-457391b0.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/cb715366a3e5/bzImage-457391b0.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
I think shmem_mknod() needs to use i_size_write() to update the size.
Writes to i_size are not assumed to be atomic throughout the kernel
code.
> ==================================================================
> BUG: KCSAN: data-race in generic_fillattr / shmem_mknod
>
> read-write to 0xffff8881049a9408 of 8 bytes by task 3383 on cpu 0:
> shmem_mknod+0xdd/0x180 mm/shmem.c:2942
> shmem_create+0x34/0x40 mm/shmem.c:2994
> lookup_open fs/namei.c:3416 [inline]
> open_last_lookups fs/namei.c:3484 [inline]
> path_openat+0xd96/0x1d00 fs/namei.c:3712
> do_filp_open+0xf6/0x200 fs/namei.c:3742
> do_sys_openat2+0xb5/0x2a0 fs/open.c:1348
> do_sys_open fs/open.c:1364 [inline]
> __do_sys_openat fs/open.c:1380 [inline]
> __se_sys_openat fs/open.c:1375 [inline]
> __x64_sys_openat+0xf3/0x120 fs/open.c:1375
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> read to 0xffff8881049a9408 of 8 bytes by task 4291 on cpu 1:
> i_size_read include/linux/fs.h:866 [inline]
> generic_fillattr+0x13f/0x1e0 fs/stat.c:58
> shmem_getattr+0x32a/0x3b0 mm/shmem.c:1068
> vfs_getattr_nosec+0x1e3/0x3c0 fs/stat.c:133
> vfs_getattr fs/stat.c:170 [inline]
> vfs_statx+0x156/0x300 fs/stat.c:242
> vfs_fstatat fs/stat.c:276 [inline]
> __do_sys_newfstatat fs/stat.c:446 [inline]
> __se_sys_newfstatat+0x8a/0x2a0 fs/stat.c:440
> __x64_sys_newfstatat+0x55/0x60 fs/stat.c:440
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> value changed: 0x0000000000001644 -> 0x0000000000001658
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 1 PID: 4291 Comm: udevd Not tainted 6.3.0-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023
> ==================================================================
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at [email protected].
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/0000000000007337c705fa1060e2%40google.com.
On 2023/04/24 17:26, Dmitry Vyukov wrote:
>> HEAD commit: 457391b03803 Linux 6.3
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=13226cf0280000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=8c81c9a3d360ebcf
>> dashboard link: https://syzkaller.appspot.com/bug?extid=702361cf7e3d95758761
>> compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
>
> I think shmem_mknod() needs to use i_size_write() to update the size.
> Writes to i_size are not assumed to be atomic throughout the kernel
> code.
>
I don't think that using i_size_{read,write}() alone is sufficient,
for I think that i_size_{read,write}() needs data_race() annotation.
include/linux/fs.h | 13 +++++++++++--
mm/shmem.c | 12 ++++++------
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 21a981680856..0d067bbe3ee9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -860,6 +860,13 @@ void filemap_invalidate_unlock_two(struct address_space *mapping1,
* the read or for example on x86 they can be still implemented as a
* cmpxchg8b without the need of the lock prefix). For SMP compiles
* and 64bit archs it makes no difference if preempt is enabled or not.
+ *
+ * However, when KCSAN is enabled, CPU being capable of reading/updating
+ * naturally aligned 8 bytes of memory atomically is not sufficient for
+ * avoiding KCSAN warning, for KCSAN checks whether value has changed between
+ * before and after of a read operation. But since we don't want to introduce
+ * seqcount overhead only for suppressing KCSAN warning, tell KCSAN that data
+ * race on accessing i_size field is acceptable.
*/
static inline loff_t i_size_read(const struct inode *inode)
{
@@ -880,7 +887,8 @@ static inline loff_t i_size_read(const struct inode *inode)
preempt_enable();
return i_size;
#else
- return inode->i_size;
+ /* See comment above. */
+ return data_race(inode->i_size);
#endif
}
@@ -902,7 +910,8 @@ static inline void i_size_write(struct inode *inode, loff_t i_size)
inode->i_size = i_size;
preempt_enable();
#else
- inode->i_size = i_size;
+ /* See comment above. */
+ data_race(inode->i_size = i_size);
#endif
}
diff --git a/mm/shmem.c b/mm/shmem.c
index e40a08c5c6d7..a2f20297fb59 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2951,7 +2951,7 @@ shmem_mknod(struct mnt_idmap *idmap, struct inode *dir,
goto out_iput;
error = 0;
- dir->i_size += BOGO_DIRENT_SIZE;
+ i_size_write(dir, i_size_read(dir) + BOGO_DIRENT_SIZE);
dir->i_ctime = dir->i_mtime = current_time(dir);
inode_inc_iversion(dir);
d_instantiate(dentry, inode);
@@ -3027,7 +3027,7 @@ static int shmem_link(struct dentry *old_dentry, struct inode *dir, struct dentr
goto out;
}
- dir->i_size += BOGO_DIRENT_SIZE;
+ i_size_write(dir, i_size_read(dir) + BOGO_DIRENT_SIZE);
inode->i_ctime = dir->i_ctime = dir->i_mtime = current_time(inode);
inode_inc_iversion(dir);
inc_nlink(inode);
@@ -3045,7 +3045,7 @@ static int shmem_unlink(struct inode *dir, struct dentry *dentry)
if (inode->i_nlink > 1 && !S_ISDIR(inode->i_mode))
shmem_free_inode(inode->i_sb);
- dir->i_size -= BOGO_DIRENT_SIZE;
+ i_size_write(dir, i_size_read(dir) - BOGO_DIRENT_SIZE);
inode->i_ctime = dir->i_ctime = dir->i_mtime = current_time(inode);
inode_inc_iversion(dir);
drop_nlink(inode);
@@ -3132,8 +3132,8 @@ static int shmem_rename2(struct mnt_idmap *idmap,
inc_nlink(new_dir);
}
- old_dir->i_size -= BOGO_DIRENT_SIZE;
- new_dir->i_size += BOGO_DIRENT_SIZE;
+ i_size_write(old_dir, i_size_read(old_dir) - BOGO_DIRENT_SIZE);
+ i_size_write(new_dir, i_size_read(new_dir) + BOGO_DIRENT_SIZE);
old_dir->i_ctime = old_dir->i_mtime =
new_dir->i_ctime = new_dir->i_mtime =
inode->i_ctime = current_time(old_dir);
@@ -3189,7 +3189,7 @@ static int shmem_symlink(struct mnt_idmap *idmap, struct inode *dir,
folio_unlock(folio);
folio_put(folio);
}
- dir->i_size += BOGO_DIRENT_SIZE;
+ i_size_write(dir, i_size_read(dir) + BOGO_DIRENT_SIZE);
dir->i_ctime = dir->i_mtime = current_time(dir);
inode_inc_iversion(dir);
d_instantiate(dentry, inode);
Maybe we want i_size_add() ?
Also, there was a similar report on updating i_{ctime,mtime} to current_time()
which means that i_size is not the only field that is causing data race.
https://syzkaller.appspot.com/bug?id=067d40ab9ab23a6fa0a8156857ed54e295062a29
Hmm, where is the serialization that avoids concurrent
shmem_mknod()/shmem_mknod() or shmem_mknod()/shmem_unlink() ?
i_size_write() says "need locking around it (normally i_mutex)"...
On 2023/05/01 14:15, Tetsuo Handa wrote:
> Hmm, where is the serialization that avoids concurrent
> shmem_mknod()/shmem_mknod() or shmem_mknod()/shmem_unlink() ?
> i_size_write() says "need locking around it (normally i_mutex)"...
>
Since filename_create() calls inode_lock_nested(path->dentry->d_inode, I_MUTEX_PARENT)
and done_path_create() calls inode_unlock(path->dentry->d_inode), serialization looks OK.
Just the name is no longer i_mutex ?
> Also, there was a similar report on updating i_{ctime,mtime} to current_time()
> which means that i_size is not the only field that is causing data race.
> https://syzkaller.appspot.com/bug?id=067d40ab9ab23a6fa0a8156857ed54e295062a29
Do we want to as well wrap i_{ctime,mtime} using data_race() ?
On Mon, 1 May 2023 at 07:16, Tetsuo Handa
<[email protected]> wrote:
>
> On 2023/04/24 17:26, Dmitry Vyukov wrote:
> >> HEAD commit: 457391b03803 Linux 6.3
> >> git tree: upstream
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=13226cf0280000
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=8c81c9a3d360ebcf
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=702361cf7e3d95758761
> >> compiler: Debian clang version 15.0.7, GNU ld (GNU Binutils for Debian) 2.35.2
> >
> > I think shmem_mknod() needs to use i_size_write() to update the size.
> > Writes to i_size are not assumed to be atomic throughout the kernel
> > code.
> >
>
> I don't think that using i_size_{read,write}() alone is sufficient,
> for I think that i_size_{read,write}() needs data_race() annotation.
Agree. Or better proper READ/WRITE_ONCE.
data_race() is just an annotation, it does not fix the actual data
race bug that is present there.
I see there are lots of uses of i_size_read() in complex scenarios
that involve comparisons of the size. All such racy uses are subject
to the TOCTOU bug at least.
> include/linux/fs.h | 13 +++++++++++--
> mm/shmem.c | 12 ++++++------
> 2 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 21a981680856..0d067bbe3ee9 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -860,6 +860,13 @@ void filemap_invalidate_unlock_two(struct address_space *mapping1,
> * the read or for example on x86 they can be still implemented as a
> * cmpxchg8b without the need of the lock prefix). For SMP compiles
> * and 64bit archs it makes no difference if preempt is enabled or not.
> + *
> + * However, when KCSAN is enabled, CPU being capable of reading/updating
> + * naturally aligned 8 bytes of memory atomically is not sufficient for
> + * avoiding KCSAN warning, for KCSAN checks whether value has changed between
> + * before and after of a read operation. But since we don't want to introduce
> + * seqcount overhead only for suppressing KCSAN warning, tell KCSAN that data
> + * race on accessing i_size field is acceptable.
> */
> static inline loff_t i_size_read(const struct inode *inode)
> {
> @@ -880,7 +887,8 @@ static inline loff_t i_size_read(const struct inode *inode)
> preempt_enable();
> return i_size;
> #else
> - return inode->i_size;
> + /* See comment above. */
> + return data_race(inode->i_size);
> #endif
> }
>
> @@ -902,7 +910,8 @@ static inline void i_size_write(struct inode *inode, loff_t i_size)
> inode->i_size = i_size;
> preempt_enable();
> #else
> - inode->i_size = i_size;
> + /* See comment above. */
> + data_race(inode->i_size = i_size);
> #endif
> }
>
> diff --git a/mm/shmem.c b/mm/shmem.c
> index e40a08c5c6d7..a2f20297fb59 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -2951,7 +2951,7 @@ shmem_mknod(struct mnt_idmap *idmap, struct inode *dir,
> goto out_iput;
>
> error = 0;
> - dir->i_size += BOGO_DIRENT_SIZE;
> + i_size_write(dir, i_size_read(dir) + BOGO_DIRENT_SIZE);
> dir->i_ctime = dir->i_mtime = current_time(dir);
> inode_inc_iversion(dir);
> d_instantiate(dentry, inode);
> @@ -3027,7 +3027,7 @@ static int shmem_link(struct dentry *old_dentry, struct inode *dir, struct dentr
> goto out;
> }
>
> - dir->i_size += BOGO_DIRENT_SIZE;
> + i_size_write(dir, i_size_read(dir) + BOGO_DIRENT_SIZE);
> inode->i_ctime = dir->i_ctime = dir->i_mtime = current_time(inode);
> inode_inc_iversion(dir);
> inc_nlink(inode);
> @@ -3045,7 +3045,7 @@ static int shmem_unlink(struct inode *dir, struct dentry *dentry)
> if (inode->i_nlink > 1 && !S_ISDIR(inode->i_mode))
> shmem_free_inode(inode->i_sb);
>
> - dir->i_size -= BOGO_DIRENT_SIZE;
> + i_size_write(dir, i_size_read(dir) - BOGO_DIRENT_SIZE);
> inode->i_ctime = dir->i_ctime = dir->i_mtime = current_time(inode);
> inode_inc_iversion(dir);
> drop_nlink(inode);
> @@ -3132,8 +3132,8 @@ static int shmem_rename2(struct mnt_idmap *idmap,
> inc_nlink(new_dir);
> }
>
> - old_dir->i_size -= BOGO_DIRENT_SIZE;
> - new_dir->i_size += BOGO_DIRENT_SIZE;
> + i_size_write(old_dir, i_size_read(old_dir) - BOGO_DIRENT_SIZE);
> + i_size_write(new_dir, i_size_read(new_dir) + BOGO_DIRENT_SIZE);
> old_dir->i_ctime = old_dir->i_mtime =
> new_dir->i_ctime = new_dir->i_mtime =
> inode->i_ctime = current_time(old_dir);
> @@ -3189,7 +3189,7 @@ static int shmem_symlink(struct mnt_idmap *idmap, struct inode *dir,
> folio_unlock(folio);
> folio_put(folio);
> }
> - dir->i_size += BOGO_DIRENT_SIZE;
> + i_size_write(dir, i_size_read(dir) + BOGO_DIRENT_SIZE);
> dir->i_ctime = dir->i_mtime = current_time(dir);
> inode_inc_iversion(dir);
> d_instantiate(dentry, inode);
>
> Maybe we want i_size_add() ?
>
> Also, there was a similar report on updating i_{ctime,mtime} to current_time()
> which means that i_size is not the only field that is causing data race.
> https://syzkaller.appspot.com/bug?id=067d40ab9ab23a6fa0a8156857ed54e295062a29
>
> Hmm, where is the serialization that avoids concurrent
> shmem_mknod()/shmem_mknod() or shmem_mknod()/shmem_unlink() ?
> i_size_write() says "need locking around it (normally i_mutex)"...
>
On 2023/05/01 23:05, Tetsuo Handa wrote:
>> Also, there was a similar report on updating i_{ctime,mtime} to current_time()
>> which means that i_size is not the only field that is causing data race.
>> https://syzkaller.appspot.com/bug?id=067d40ab9ab23a6fa0a8156857ed54e295062a29
>
> Do we want to as well wrap i_{ctime,mtime} using data_race() ?
>
I think we need to use inode_lock_shared()/inode_unlock_shared() when calling
generic_fillattr(), for i_{ctime,mtime} (128bits) are too large to copy atomically.
Is it safe to call inode_lock_shared()/inode_unlock_shared() from generic_fillattr()?
Is some filesystem already holding inode lock before calling generic_fillattr()?
syzbot has found a reproducer for the following issue on:
HEAD commit: 70d201a40823 Merge tag 'f2fs-for-6.8-rc1' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16e391f5e80000
kernel config: https://syzkaller.appspot.com/x/.config?x=31b069fcee8f481d
dashboard link: https://syzkaller.appspot.com/bug?extid=702361cf7e3d95758761
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=147a56a3e80000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/4446464b507c/disk-70d201a4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/578f39e16cac/vmlinux-70d201a4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/5fffd404e095/bzImage-70d201a4.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
==================================================================
BUG: KCSAN: data-race in generic_fillattr / shmem_mknod
write to 0xffff88810427aa10 of 8 bytes by task 3467 on cpu 1:
inode_set_mtime_to_ts include/linux/fs.h:1571 [inline]
shmem_mknod+0x132/0x180 mm/shmem.c:3259
shmem_create+0x34/0x40 mm/shmem.c:3313
lookup_open fs/namei.c:3486 [inline]
open_last_lookups fs/namei.c:3555 [inline]
path_openat+0xdc2/0x1d30 fs/namei.c:3785
do_filp_open+0xf6/0x200 fs/namei.c:3815
do_sys_openat2+0xab/0x110 fs/open.c:1404
do_sys_open fs/open.c:1419 [inline]
__do_sys_openat fs/open.c:1435 [inline]
__se_sys_openat fs/open.c:1430 [inline]
__x64_sys_openat+0xf3/0x120 fs/open.c:1430
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x59/0x120 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
read to 0xffff88810427aa10 of 8 bytes by task 3068 on cpu 0:
inode_get_mtime include/linux/fs.h:1565 [inline]
generic_fillattr+0x1a6/0x2f0 fs/stat.c:61
shmem_getattr+0x17b/0x200 mm/shmem.c:1139
vfs_getattr_nosec fs/stat.c:135 [inline]
vfs_getattr+0x198/0x1e0 fs/stat.c:176
vfs_statx+0x140/0x320 fs/stat.c:248
vfs_fstatat+0xcd/0x100 fs/stat.c:304
__do_sys_newfstatat fs/stat.c:468 [inline]
__se_sys_newfstatat+0x58/0x260 fs/stat.c:462
__x64_sys_newfstatat+0x55/0x60 fs/stat.c:462
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x59/0x120 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
value changed: 0x00000000366f1c62 -> 0x000000003707b2e3
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 3068 Comm: udevd Not tainted 6.7.0-syzkaller-06264-g70d201a40823 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
==================================================================
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.