public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [syzbot] Re: [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify
@ 2024-04-16 10:47 Amir Goldstein
  2024-04-17  2:03 ` syzbot
  0 siblings, 1 reply; 14+ messages in thread
From: Amir Goldstein @ 2024-04-16 10:47 UTC (permalink / raw)
  To: Jan Kara
  Cc: Hillf Danton, syzbot, linux-fsdevel, syzkaller-bugs, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 6844 bytes --]

On Mon, Apr 15, 2024 at 5:47 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Mon, Apr 15, 2024 at 5:03 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Sat 13-04-24 12:32:32, Amir Goldstein wrote:
> > > On Sat, Apr 13, 2024 at 11:45 AM Hillf Danton <hdanton@sina.com> wrote:
> > > > On Fri, 12 Apr 2024 23:42:19 -0700 Amir Goldstein
> > > > > On Sat, Apr 13, 2024 at 4:41=E2=80=AFAM Hillf Danton <hdanton@sina.com> wrote:
> > > > > > On Thu, 11 Apr 2024 01:11:20 -0700
> > > > > > > syzbot found the following issue on:
> > > > > > >
> > > > > > > HEAD commit:    6ebf211bb11d Add linux-next specific files for 20240410
> > > > > > > git tree:       linux-next
> > > > > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=3D1621af9d180000
> > > > > >
> > > > > > #syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git  6ebf211bb11d
> > > > > >
> > > > > > --- x/fs/notify/fsnotify.c
> > > > > > +++ y/fs/notify/fsnotify.c
> > > > > > @@ -101,8 +101,8 @@ void fsnotify_sb_delete(struct super_blo
> > > > > >         wait_var_event(fsnotify_sb_watched_objects(sb),
> > > > > >                        !atomic_long_read(fsnotify_sb_watched_objects(sb)));
> > > > > >         WARN_ON(fsnotify_sb_has_priority_watchers(sb, FSNOTIFY_PRIO_CONTENT));
> > > > > > -       WARN_ON(fsnotify_sb_has_priority_watchers(sb,
> > > > > > -                                                 FSNOTIFY_PRIO_PRE_CONTENT));
> > > > > > +       WARN_ON(fsnotify_sb_has_priority_watchers(sb, FSNOTIFY_PRIO_PRE_CONTENT));
> > > > > > +       synchronize_srcu(&fsnotify_mark_srcu);
> > > > > >         kfree(sbinfo);
> > > > > >  }
> > > > > >
> > > > > > @@ -499,7 +499,7 @@ int fsnotify(__u32 mask, const void *dat
> > > > > >  {
> > > > > >         const struct path *path =3D fsnotify_data_path(data, data_type);
> > > > > >         struct super_block *sb =3D fsnotify_data_sb(data, data_type);
> > > > > > -       struct fsnotify_sb_info *sbinfo =3D fsnotify_sb_info(sb);
> > > > > > +       struct fsnotify_sb_info *sbinfo;
> > > > > >         struct fsnotify_iter_info iter_info = {};
> > > > > >         struct mount *mnt =3D NULL;
> > > > > >         struct inode *inode2 =3D NULL;
> > > > > > @@ -529,6 +529,8 @@ int fsnotify(__u32 mask, const void *dat
> > > > > >                 inode2_type =3D FSNOTIFY_ITER_TYPE_PARENT;
> > > > > >         }
> > > > > >
> > > > > > +       iter_info.srcu_idx =3D srcu_read_lock(&fsnotify_mark_srcu);
> > > > > > +       sbinfo =3D fsnotify_sb_info(sb);
> > > > > >         /*
> > > > > >          * Optimization: srcu_read_lock() has a memory barrier which can
> > > > > >          * be expensive.  It protects walking the *_fsnotify_marks lists.
> > > > >
> > > > >
> > > > > See comment above. This kills the optimization.
> > > > > It is not worth letting all the fsnotify hooks suffer the consequence
> > > > > for the edge case of calling fsnotify hook during fs shutdown.
> > > >
> > > > Say nothing before reading your fix.
> > > > >
> > > > > Also, fsnotify_sb_info(sb) in fsnotify_sb_has_priority_watchers()
> > > > > is also not protected and using srcu_read_lock() there completely
> > > > > nullifies the purpose of fsnotify_sb_info.
> > > > >
> > > > > Here is a simplified fix for fsnotify_sb_error() rebased on the
> > > > > pending mm fixes for this syzbot boot failure:
> > > > >
> > > > > #syz test: https://github.com/amir73il/linux fsnotify-fixes
> > > >
> > > > Feel free to post your patch at lore because not everyone has
> > > > access to sites like github.
> > > > >
> > > > > Jan,
> > > > >
> > > > > I think that all the functions called from fs shutdown context
> > > > > should observe that SB_ACTIVE is cleared but wasn't sure?
> > > >
> > > > If you composed fix based on SB_ACTIVE that is cleared in
> > > > generic_shutdown_super() with &sb->s_umount held for write,
> > > > I wonder what simpler serialization than srcu you could
> > > > find/create in fsnotify.
> > >
> > > As far as I can tell there is no need for serialisation.
> > >
> > > The problem is that fsnotify_sb_error() can be called from the
> > > context of ->put_super() call from generic_shutdown_super().
> > >
> > > It's true that in the repro the thread calling fsnotify_sb_error()
> > > in the worker thread running quota deferred work from put_super()
> > > but I think there are sufficient barriers for this worker thread to
> > > observer the cleared SB_ACTIVE flag.
> > >
> > > Anyway, according to syzbot, repro does not trigger the UAF
> > > with my last fix.
> > >
> > > To be clear, any fsnotify_sb_error() that is a result of a user operation
> > > would be holding an active reference to sb so cannot race with
> > > fsnotify_sb_delete(), but I am not sure that same is true for ext4
> > > worker threads.
> > >
> > > Jan,
> > >
> > > You wrote that "In theory these two calls can even run in parallel
> > > and fsnotify() can be holding fsnotify_sb_info pointer while
> > > fsnotify_sb_delete() is freeing".
> > >
> > > Can you give an example of this case?
> >
> > Yeah, basically what Hilf writes:
> >
> > Task 1                                  Task 2
> >   umount()                              some delayed work, transaction
> >                                           commit, whatever is still running
> >                                           before ext4_put_super() completes
> >     ...                                     ext4_error()
> >                                               fsnotify_sb_error()
> >                                                 fsnotify()
> >                                                   fetches fsnotify_sb_info
> >     generic_shutdown_super()
> >       fsnotify_sb_delete()
> >         frees fsnotify_sb_info
>
> OK, so what do you say about Hillf's fix patch?
>
> Maybe it is ok to let go of the optimization in fsnotify(), considering
> that we now have stronger optimizations in the inline hooks and
> in __fsnotify_parent()?
>
> I think that Hillf's patch is missing setting s_fsnotify_info to NULL?
>
>  @@ -101,8 +101,8 @@ void fsnotify_sb_delete(struct super_blo
>          wait_var_event(fsnotify_sb_watched_objects(sb),
>                         !atomic_long_read(fsnotify_sb_watched_objects(sb)));
>          WARN_ON(fsnotify_sb_has_priority_watchers(sb, FSNOTIFY_PRIO_CONTENT));
> +       WRITE_ONCE(sb->s_fsnotify_info, NULL);
> +       synchronize_srcu(&fsnotify_mark_srcu);
>          kfree(sbinfo);
>  }
>

I reworked Hillf's patch so it won't break the optimizations for
the common case and added setting s_fsnotify_info to NULL (attached).

Let's see what syzbot has to say:

#syz test: https://github.com/amir73il/linux fsnotify-fixes

Thanks,
Amir.

[-- Attachment #2: 0001-fsnotify-fix-UAF-from-FS_ERROR-event-on-a-shutting-d.patch --]
[-- Type: text/x-patch, Size: 3344 bytes --]

From 4e42e6b66c24e42b4089b1212f0eccb01b7b7eda Mon Sep 17 00:00:00 2001
From: Amir Goldstein <amir73il@gmail.com>
Date: Thu, 11 Apr 2024 18:59:08 +0300
Subject: [PATCH] fsnotify: fix UAF from FS_ERROR event on a shutting down
 filesystem

Protect against use after free when filesystem calls fsnotify_sb_error()
during fs shutdown.

fsnotify_sb_error() may be called without an s_active reference, so use
SRCU to synchronize access to fsnotify_sb_info() in this case.

Reported-by: syzbot+5e3f9b2a67b45f16d4e6@syzkaller.appspotmail.com
Suggested-by: Hillf Danton <hdanton@sina.com>
Link: https://lore.kernel.org/linux-fsdevel/20240413014033.1722-1-hdanton@sina.com/
Fixes: 07a3b8d0bf72 ("fsnotify: lazy attach fsnotify_sb_info state to sb")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 fs/notify/fsnotify.c             | 14 ++++++++++++--
 include/linux/fsnotify_backend.h |  3 +++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
index 2ae965ef37e8..ec9b535d333a 100644
--- a/fs/notify/fsnotify.c
+++ b/fs/notify/fsnotify.c
@@ -103,6 +103,8 @@ void fsnotify_sb_delete(struct super_block *sb)
 	WARN_ON(fsnotify_sb_has_priority_watchers(sb, FSNOTIFY_PRIO_CONTENT));
 	WARN_ON(fsnotify_sb_has_priority_watchers(sb,
 						  FSNOTIFY_PRIO_PRE_CONTENT));
+	WRITE_ONCE(sb->s_fsnotify_info, NULL);
+	synchronize_srcu(&fsnotify_mark_srcu);
 	kfree(sbinfo);
 }
 
@@ -506,6 +508,7 @@ int fsnotify(__u32 mask, const void *data, int data_type, struct inode *dir,
 	struct dentry *moved;
 	int inode2_type;
 	int ret = 0;
+	bool sb_active_ref = !(mask & FS_EVENTS_POSS_ON_SHUTDOWN);
 	__u32 test_mask, marks_mask;
 
 	if (path)
@@ -535,8 +538,10 @@ int fsnotify(__u32 mask, const void *data, int data_type, struct inode *dir,
 	 * However, if we do not walk the lists, we do not have to do
 	 * SRCU because we have no references to any objects and do not
 	 * need SRCU to keep them "alive".
+	 * We only need SRCU to keep sbinfo "alive" for events possible
+	 * during shutdown (e.g. FS_ERROR).
 	 */
-	if ((!sbinfo || !sbinfo->sb_marks) &&
+	if ((!sbinfo || (sb_active_ref && !sbinfo->sb_marks)) &&
 	    (!mnt || !mnt->mnt_fsnotify_marks) &&
 	    (!inode || !inode->i_fsnotify_marks) &&
 	    (!inode2 || !inode2->i_fsnotify_marks))
@@ -562,7 +567,12 @@ int fsnotify(__u32 mask, const void *data, int data_type, struct inode *dir,
 		return 0;
 
 	iter_info.srcu_idx = srcu_read_lock(&fsnotify_mark_srcu);
-
+	/*
+	 * For events possible during shutdown (e.g. FS_ERROR) we may not hold
+	 * an s_active reference on sb, so we need to re-fetch sbinfo with
+	 * srcu_read_lock() held.
+	 */
+	sbinfo = fsnotify_sb_info(sb);
 	if (sbinfo) {
 		iter_info.marks[FSNOTIFY_ITER_TYPE_SB] =
 			fsnotify_first_mark(&sbinfo->sb_marks);
diff --git a/include/linux/fsnotify_backend.h b/include/linux/fsnotify_backend.h
index 7f1ab8264e41..f10987662d1f 100644
--- a/include/linux/fsnotify_backend.h
+++ b/include/linux/fsnotify_backend.h
@@ -97,6 +97,9 @@
  */
 #define FS_EVENTS_POSS_TO_PARENT (FS_EVENTS_POSS_ON_CHILD)
 
+/* Events that could be generated while fs is shutting down */
+#define FS_EVENTS_POSS_ON_SHUTDOWN (FS_ERROR)
+
 /* Events that can be reported to backends */
 #define ALL_FSNOTIFY_EVENTS (ALL_FSNOTIFY_DIRENT_EVENTS | \
 			     FS_EVENTS_POSS_ON_CHILD | \
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 14+ messages in thread
[parent not found: <20240413014033.1722-1-hdanton@sina.com>]
* Re: [syzbot] Re: [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify
  2024-04-11  8:11 syzbot
@ 2024-04-13  6:42 syzbot
  2024-04-13  8:45 ` Hillf Danton
  0 siblings, 1 reply; 14+ messages in thread
From: syzbot @ 2024-04-13  6:42 UTC (permalink / raw)
  To: linux-kernel

For archival purposes, forwarding an incoming command email to
linux-kernel@vger.kernel.org.

***

Subject: Re: [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify
Author: amir73il@gmail.com

On Sat, Apr 13, 2024 at 4:41 AM Hillf Danton <hdanton@sina.com> wrote:
>
> On Thu, 11 Apr 2024 01:11:20 -0700
> > syzbot found the following issue on:
> >
> > HEAD commit:    6ebf211bb11d Add linux-next specific files for 20240410
> > git tree:       linux-next
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1621af9d180000
>
> #syz test https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git  6ebf211bb11d
>
> --- x/fs/notify/fsnotify.c
> +++ y/fs/notify/fsnotify.c
> @@ -101,8 +101,8 @@ void fsnotify_sb_delete(struct super_blo
>         wait_var_event(fsnotify_sb_watched_objects(sb),
>                        !atomic_long_read(fsnotify_sb_watched_objects(sb)));
>         WARN_ON(fsnotify_sb_has_priority_watchers(sb, FSNOTIFY_PRIO_CONTENT));
> -       WARN_ON(fsnotify_sb_has_priority_watchers(sb,
> -                                                 FSNOTIFY_PRIO_PRE_CONTENT));
> +       WARN_ON(fsnotify_sb_has_priority_watchers(sb, FSNOTIFY_PRIO_PRE_CONTENT));
> +       synchronize_srcu(&fsnotify_mark_srcu);
>         kfree(sbinfo);
>  }
>
> @@ -499,7 +499,7 @@ int fsnotify(__u32 mask, const void *dat
>  {
>         const struct path *path = fsnotify_data_path(data, data_type);
>         struct super_block *sb = fsnotify_data_sb(data, data_type);
> -       struct fsnotify_sb_info *sbinfo = fsnotify_sb_info(sb);
> +       struct fsnotify_sb_info *sbinfo;
>         struct fsnotify_iter_info iter_info = {};
>         struct mount *mnt = NULL;
>         struct inode *inode2 = NULL;
> @@ -529,6 +529,8 @@ int fsnotify(__u32 mask, const void *dat
>                 inode2_type = FSNOTIFY_ITER_TYPE_PARENT;
>         }
>
> +       iter_info.srcu_idx = srcu_read_lock(&fsnotify_mark_srcu);
> +       sbinfo = fsnotify_sb_info(sb);
>         /*
>          * Optimization: srcu_read_lock() has a memory barrier which can
>          * be expensive.  It protects walking the *_fsnotify_marks lists.


See comment above. This kills the optimization.
It is not worth letting all the fsnotify hooks suffer the consequence
for the edge case of calling fsnotify hook during fs shutdown.

Also, fsnotify_sb_info(sb) in fsnotify_sb_has_priority_watchers()
is also not protected and using srcu_read_lock() there completely
nullifies the purpose of fsnotify_sb_info.

Here is a simplified fix for fsnotify_sb_error() rebased on the
pending mm fixes for this syzbot boot failure:

#syz test: https://github.com/amir73il/linux fsnotify-fixes

Jan,

I think that all the functions called from fs shutdown context
should observe that SB_ACTIVE is cleared but wasn't sure?

Thanks,
Amir.

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify
@ 2024-04-11  8:11 syzbot
  2024-04-11 12:13 ` Jan Kara
  0 siblings, 1 reply; 14+ messages in thread
From: syzbot @ 2024-04-11  8:11 UTC (permalink / raw)
  To: amir73il, jack, linux-ext4, linux-fsdevel, linux-kernel, repnop,
	syzkaller-bugs

Hello,

syzbot found the following issue on:

HEAD commit:    6ebf211bb11d Add linux-next specific files for 20240410
git tree:       linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=12be955d180000
kernel config:  https://syzkaller.appspot.com/x/.config?x=16ca158ef7e08662
dashboard link: https://syzkaller.appspot.com/bug?extid=5e3f9b2a67b45f16d4e6
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=13c91175180000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1621af9d180000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b050f81f73ed/disk-6ebf211b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/412c9b9a536e/vmlinux-6ebf211b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/016527216c47/bzImage-6ebf211b.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/75ad050c9945/mount_0.gz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5e3f9b2a67b45f16d4e6@syzkaller.appspotmail.com

Quota error (device loop0): do_check_range: Getting block 0 out of range 1-5
EXT4-fs error (device loop0): ext4_release_dquot:6905: comm kworker/u8:4: Failed to release dquot type 1
==================================================================
BUG: KASAN: slab-use-after-free in fsnotify+0x2a4/0x1f70 fs/notify/fsnotify.c:539
Read of size 8 at addr ffff88802f1dce80 by task kworker/u8:4/62

CPU: 0 PID: 62 Comm: kworker/u8:4 Not tainted 6.9.0-rc3-next-20240410-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: events_unbound quota_release_workfn
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 fsnotify+0x2a4/0x1f70 fs/notify/fsnotify.c:539
 fsnotify_sb_error include/linux/fsnotify.h:456 [inline]
 __ext4_error+0x255/0x3b0 fs/ext4/super.c:843
 ext4_release_dquot+0x326/0x450 fs/ext4/super.c:6903
 quota_release_workfn+0x39f/0x650 fs/quota/dquot.c:840
 process_one_work kernel/workqueue.c:3218 [inline]
 process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3299
 worker_thread+0x86d/0xd70 kernel/workqueue.c:3380
 kthread+0x2f0/0x390 kernel/kthread.c:389
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 </TASK>

Allocated by task 5085:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
 __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
 kasan_kmalloc include/linux/kasan.h:211 [inline]
 kmalloc_trace_noprof+0x19c/0x2b0 mm/slub.c:4109
 kmalloc_noprof include/linux/slab.h:660 [inline]
 kzalloc_noprof include/linux/slab.h:775 [inline]
 fsnotify_attach_info_to_sb fs/notify/mark.c:600 [inline]
 fsnotify_add_mark_list fs/notify/mark.c:692 [inline]
 fsnotify_add_mark_locked+0x3b2/0xe60 fs/notify/mark.c:777
 fanotify_add_new_mark fs/notify/fanotify/fanotify_user.c:1267 [inline]
 fanotify_add_mark+0xbbd/0x1330 fs/notify/fanotify/fanotify_user.c:1334
 do_fanotify_mark+0xbcc/0xd90 fs/notify/fanotify/fanotify_user.c:1896
 __do_sys_fanotify_mark fs/notify/fanotify/fanotify_user.c:1919 [inline]
 __se_sys_fanotify_mark fs/notify/fanotify/fanotify_user.c:1915 [inline]
 __x64_sys_fanotify_mark+0xb5/0xd0 fs/notify/fanotify/fanotify_user.c:1915
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 5085:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2190 [inline]
 slab_free mm/slub.c:4393 [inline]
 kfree+0x149/0x350 mm/slub.c:4514
 fsnotify_sb_delete+0x686/0x6f0 fs/notify/fsnotify.c:106
 generic_shutdown_super+0xa5/0x2d0 fs/super.c:632
 kill_block_super+0x44/0x90 fs/super.c:1675
 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7323
 deactivate_locked_super+0xc4/0x130 fs/super.c:472
 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1267
 task_work_run+0x24f/0x310 kernel/task_work.c:180
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0xa1b/0x27e0 kernel/exit.c:878
 do_group_exit+0x207/0x2c0 kernel/exit.c:1027
 __do_sys_exit_group kernel/exit.c:1038 [inline]
 __se_sys_exit_group kernel/exit.c:1036 [inline]
 __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff88802f1dce80
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 0 bytes inside of
 freed 32-byte region [ffff88802f1dce80, ffff88802f1dcea0)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2f1dc
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
page_type: 0xffffefff(slab)
raw: 00fff80000000000 ffff888015041500 ffffea000096b540 dead000000000004
raw: 0000000000000000 0000000080400040 00000001ffffefff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x12cc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY), pid 1, tgid -625457465 (swapper/0), ts 1, free_ts 0
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1468
 prep_new_page mm/page_alloc.c:1476 [inline]
 get_page_from_freelist+0x2ce2/0x2d90 mm/page_alloc.c:3438
 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4696
 __alloc_pages_node_noprof include/linux/gfp.h:244 [inline]
 alloc_pages_node_noprof include/linux/gfp.h:271 [inline]
 alloc_slab_page+0x5f/0x120 mm/slub.c:2259
 allocate_slab+0x5a/0x2e0 mm/slub.c:2422
 new_slab mm/slub.c:2475 [inline]
 ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3624
 __slab_alloc+0x58/0xa0 mm/slub.c:3714
 __slab_alloc_node mm/slub.c:3767 [inline]
 slab_alloc_node mm/slub.c:3945 [inline]
 __do_kmalloc_node mm/slub.c:4077 [inline]
 kmalloc_node_track_caller_noprof+0x286/0x440 mm/slub.c:4098
 kstrdup+0x3a/0x80 mm/util.c:62
 kobject_set_name_vargs+0x61/0x120 lib/kobject.c:274
 kobject_add_varg lib/kobject.c:368 [inline]
 kobject_init_and_add+0xde/0x190 lib/kobject.c:457
 sysfs_slab_add+0x7a/0x290 mm/slub.c:6877
 slab_sysfs_init+0x66/0x170 mm/slub.c:6961
 do_one_initcall+0x248/0x880 init/main.c:1263
 do_initcall_level+0x157/0x210 init/main.c:1325
 do_initcalls+0x3f/0x80 init/main.c:1341
page_owner free stack trace missing

Memory state around the buggy address:
 ffff88802f1dcd80: 00 00 05 fc fc fc fc fc 00 00 00 00 fc fc fc fc
 ffff88802f1dce00: 00 00 00 06 fc fc fc fc fa fb fb fb fc fc fc fc
>ffff88802f1dce80: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
                   ^
 ffff88802f1dcf00: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
 ffff88802f1dcf80: fa fb fb fb fc fc fc fc 00 00 00 fc fc fc fc fc
==================================================================


---
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 syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

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.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-04-17  2:03 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <CAOQ4uxhJi_YT=AZOaJGH6tt9kM7kUoAF1uzVqfGBXjvc8S78Ug@mail.gmail.com>
2024-04-13  8:58 ` [syzbot] [ext4?] KASAN: slab-use-after-free Read in fsnotify syzbot
2024-04-16 10:47 [syzbot] " Amir Goldstein
2024-04-17  2:03 ` syzbot
     [not found] <20240413014033.1722-1-hdanton@sina.com>
2024-04-13  8:40 ` syzbot
  -- strict thread matches above, loose matches on Subject: below --
2024-04-13  6:42 [syzbot] " syzbot
2024-04-13  8:45 ` Hillf Danton
2024-04-13  9:32   ` Amir Goldstein
2024-04-13 12:04     ` Hillf Danton
2024-04-11  8:11 syzbot
2024-04-11 12:13 ` Jan Kara
2024-04-11 16:07   ` Amir Goldstein
2024-04-11 19:25     ` Gabriel Krisman Bertazi
2024-04-11 20:27       ` Khazhy Kumykov
2024-04-12 10:24         ` Amir Goldstein
2024-04-11 20:06     ` syzbot
2024-04-12  7:52       ` Amir Goldstein
2024-04-12 14:30         ` syzbot
2024-04-12 14:32           ` Aleksandr Nogikh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox