general protection fault in __list_del_entry_valid (2)

37 views
Skip to first unread message

syzbot

unread,
Nov 21, 2017, 2:35:04ā€ÆAM11/21/17
to ak...@linux-foundation.org, han...@cmpxchg.org, hill...@alibaba-inc.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, mho...@suse.com, min...@kernel.org, sh...@fb.com, syzkall...@googlegroups.com, ying....@intel.com
Hello,

syzkaller hit the following crash on
ca91659962303d4fd5211a5e4e13df5cbb11e744
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.

Unfortunately, I don't have any reproducer for this bug yet.


kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
task: ffff8801d1dbe5c0 task.stack: ffff8801c9e38000
RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
RSP: 0018:ffff8801c9e3f108 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8801c53c6f98 RDI: ffff8801c53c6fa0
RBP: ffff8801c9e3f120 R08: 1ffff100393c7d55 R09: 0000000000000004
R10: ffff8801c9e3ef70 R11: 0000000000000000 R12: 0000000000000000
R13: dffffc0000000000 R14: 1ffff100393c7e45 R15: ffff8801c53c6f98
FS: 0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000dbc23000 CR3: 00000001c7269000 CR4: 00000000001406e0
DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
Call Trace:
__list_del_entry include/linux/list.h:117 [inline]
list_del include/linux/list.h:125 [inline]
unregister_shrinker+0x79/0x300 mm/vmscan.c:301
deactivate_locked_super+0x64/0xd0 fs/super.c:308
deactivate_super+0x141/0x1b0 fs/super.c:340
cleanup_mnt+0xb2/0x150 fs/namespace.c:1173
mntput_no_expire+0x6e0/0xa90 fs/namespace.c:1237
mntput fs/namespace.c:1247 [inline]
kern_unmount+0x9c/0xd0 fs/namespace.c:2999
mq_put_mnt+0x37/0x50 ipc/mqueue.c:1609
put_ipc_ns+0x4d/0x150 ipc/namespace.c:163
free_nsproxy+0xc0/0x1f0 kernel/nsproxy.c:180
switch_task_namespaces+0x9d/0xc0 kernel/nsproxy.c:229
exit_task_namespaces+0x17/0x20 kernel/nsproxy.c:234
do_exit+0x9b0/0x1ad0 kernel/exit.c:864
do_group_exit+0x149/0x400 kernel/exit.c:968
get_signal+0x73f/0x16d0 kernel/signal.c:2334
do_signal+0x94/0x1ee0 arch/x86/kernel/signal.c:809
exit_to_usermode_loop+0x214/0x310 arch/x86/entry/common.c:158
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:266 [inline]
do_syscall_32_irqs_on arch/x86/entry/common.c:335 [inline]
do_fast_syscall_32+0x83e/0xf05 arch/x86/entry/common.c:391
entry_SYSENTER_compat+0x51/0x60 arch/x86/entry/entry_64_compat.S:125
RIP: 0023:0xf7fb6c79
RSP: 002b:00000000f77b210c EFLAGS: 00000296 ORIG_RAX: 00000000000000f0
RAX: fffffffffffffe00 RBX: 000000000816803c RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Code: 00 00 00 00 ad de 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de 48 89
da 48 39 c3 74 65 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df <80> 3c 02 00
75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8
RIP: __list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51 RSP:
ffff8801c9e3f108
---[ end trace 9fc3c550f374f309 ]---


---
This bug is generated by a dumb bot. It may contain errors.
See https://goo.gl/tpsmEJ for details.
Direct all questions to syzk...@googlegroups.com.
Please credit me with: Reported-by: syzbot <syzk...@googlegroups.com>

syzbot will keep track of this bug report.
Once a fix for this bug is committed, please reply to this email with:
#syz fix: exact-commit-title
To mark this as a duplicate of another syzbot report, please reply with:
#syz dup: exact-subject-of-another-report
If it's a one-off invalid bug report, please reply with:
#syz invalid
Note: if the crash happens again, it will cause creation of a new bug
report.
Note: all commands must start from beginning of the line in the email body.
config.txt
raw.log

Tetsuo Handa

unread,
Nov 21, 2017, 6:11:51ā€ÆAM11/21/17
to syzbot, ak...@linux-foundation.org, han...@cmpxchg.org, hill...@alibaba-inc.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, mho...@suse.com, min...@kernel.org, sh...@fb.com, syzkall...@googlegroups.com, ying....@intel.com
On 2017/11/21 16:35, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on ca91659962303d4fd5211a5e4e13df5cbb11e744
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
>
> Unfortunately, I don't have any reproducer for this bug yet.

Fault injection found an unchecked register_shrinker() return code.
Wow, register_shrinker()/unregister_shinker() is possibly frequently called path?


struct super_block *sget_userns(struct file_system_type *type,
int (*test)(struct super_block *,void *),
int (*set)(struct super_block *,void *),
int flags, struct user_namespace *user_ns,
void *data)
{
(...snipped...)
spin_unlock(&sb_lock);
get_filesystem(type);
register_shrinker(&s->s_shrink); // Error check required.
return s;
}

[ 554.881422] FAULT_INJECTION: forcing a failure.
[ 554.881422] name failslab, interval 1, probability 0, space 0, times 0
[ 554.881438] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82
[ 554.881443] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 554.881445] Call Trace:
[ 554.881459] dump_stack+0x194/0x257
[ 554.881474] ? arch_local_irq_restore+0x53/0x53
[ 554.881486] ? find_held_lock+0x35/0x1d0
[ 554.881507] should_fail+0x8c0/0xa40
[ 554.881522] ? fault_create_debugfs_attr+0x1f0/0x1f0
[ 554.881537] ? check_noncircular+0x20/0x20
[ 554.881546] ? find_next_zero_bit+0x2c/0x40
[ 554.881560] ? ida_get_new_above+0x421/0x9d0
[ 554.881577] ? find_held_lock+0x35/0x1d0
[ 554.881594] ? __lock_is_held+0xb6/0x140
[ 554.881628] ? check_same_owner+0x320/0x320
[ 554.881634] ? lock_downgrade+0x990/0x990
[ 554.881649] ? find_held_lock+0x35/0x1d0
[ 554.881672] should_failslab+0xec/0x120
[ 554.881684] __kmalloc+0x63/0x760
[ 554.881692] ? lock_downgrade+0x990/0x990
[ 554.881712] ? register_shrinker+0x10e/0x2d0
[ 554.881721] ? trace_event_raw_event_module_request+0x320/0x320
[ 554.881737] register_shrinker+0x10e/0x2d0
[ 554.881747] ? prepare_kswapd_sleep+0x1f0/0x1f0
[ 554.881755] ? _down_write_nest_lock+0x120/0x120
[ 554.881765] ? memcpy+0x45/0x50
[ 554.881785] sget_userns+0xbcd/0xe20
[ 554.881792] ? set_anon_super+0x20/0x20
[ 554.881809] ? put_filp+0x90/0x90
[ 554.881822] ? __sb_start_write+0x2a0/0x2a0
[ 554.881829] ? alloc_pages_current+0xbe/0x1e0
[ 554.881846] ? free_pages+0x51/0x90
[ 554.881858] ? selinux_sb_copy_data+0x4a1/0x610
[ 554.881864] ? __lockdep_init_map+0xe4/0x650
[ 554.881882] ? selinux_quota_on+0x320/0x320
[ 554.881892] ? __lockdep_init_map+0xe4/0x650
[ 554.881906] ? lockdep_init_map+0x9/0x10
[ 554.881936] ? mqueue_get_inode+0xc60/0xc60
[ 554.881944] mount_ns+0x6d/0x190
[ 554.881960] mqueue_mount+0xbe/0xe0
[ 554.881975] mount_fs+0x66/0x2d0
[ 554.881991] vfs_kern_mount.part.26+0xc6/0x4a0
[ 554.882004] ? may_umount+0xa0/0xa0
[ 554.882013] ? compat_SyS_msgrcv+0x50/0x50
[ 554.882023] ? ida_remove+0x3e0/0x3e0
[ 554.882034] ? kmem_cache_alloc_trace+0x456/0x750
[ 554.882048] kern_mount_data+0x50/0xb0

[ 554.898693] kasan: CONFIG_KASAN_INLINE enabled
[ 554.898724] kasan: GPF could be caused by NULL-ptr deref or user memory access
[ 554.898732] general protection fault: 0000 [#1] SMP KASAN
[ 554.898737] Dumping ftrace buffer:
[ 554.898741] (ftrace buffer empty)
[ 554.898743] Modules linked in:
[ 554.898752] CPU: 1 PID: 13231 Comm: syz-executor1 Not tainted 4.14.0-rc8+ #82
[ 554.898755] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 554.898760] task: ffff8801d1dbe5c0 task.stack: ffff8801c9e38000
[ 554.898772] RIP: 0010:__list_del_entry_valid+0x7e/0x150
[ 554.898775] RSP: 0018:ffff8801c9e3f108 EFLAGS: 00010246
[ 554.898780] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
[ 554.898784] RDX: 0000000000000000 RSI: ffff8801c53c6f98 RDI: ffff8801c53c6fa0
[ 554.898788] RBP: ffff8801c9e3f120 R08: 1ffff100393c7d55 R09: 0000000000000004
[ 554.898791] R10: ffff8801c9e3ef70 R11: 0000000000000000 R12: 0000000000000000
[ 554.898795] R13: dffffc0000000000 R14: 1ffff100393c7e45 R15: ffff8801c53c6f98
[ 554.898800] FS: 0000000000000000(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
[ 554.898804] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 554.898807] CR2: 00000000dbc23000 CR3: 00000001c7269000 CR4: 00000000001406e0
[ 554.898813] DR0: 0000000020000000 DR1: 0000000020000000 DR2: 0000000000000000
[ 554.898816] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
[ 554.898818] Call Trace:
[ 554.898828] unregister_shrinker+0x79/0x300
[ 554.898837] ? perf_trace_mm_vmscan_writepage+0x750/0x750
[ 554.898844] ? down_write+0x87/0x120
[ 554.898851] ? deactivate_super+0x139/0x1b0
[ 554.898857] ? down_read+0x150/0x150
[ 554.898864] ? check_same_owner+0x320/0x320
[ 554.898875] deactivate_locked_super+0x64/0xd0
[ 554.898883] deactivate_super+0x141/0x1b0
[ 554.898893] ? mount_ns+0x190/0x190
[ 554.898901] ? dput.part.24+0x175/0x740
[ 554.898912] cleanup_mnt+0xb2/0x150
[ 554.898919] mntput_no_expire+0x6e0/0xa90
[ 554.898926] ? call_rcu_bh+0x20/0x20
[ 554.898934] ? mnt_get_count+0x150/0x150
[ 554.898942] ? trace_raw_output_rcu_utilization+0xb0/0xb0
[ 554.898954] ? __might_sleep+0x95/0x190
[ 554.898964] kern_unmount+0x9c/0xd0

Michal Hocko

unread,
Nov 21, 2017, 9:05:06ā€ÆAM11/21/17
to Tetsuo Handa, syzbot, ak...@linux-foundation.org, han...@cmpxchg.org, hill...@alibaba-inc.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, min...@kernel.org, sh...@fb.com, syzkall...@googlegroups.com, ying....@intel.com, Al Viro, Dave Chinner
[Cc Al and Dave - email thread starts http://lkml.kernel.org/r/001a113f996099...@google.com]

On Tue 21-11-17 20:11:26, Tetsuo Handa wrote:
> On 2017/11/21 16:35, syzbot wrote:
> > Hello,
> >
> > syzkaller hit the following crash on ca91659962303d4fd5211a5e4e13df5cbb11e744
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > compiler: gcc (GCC) 7.1.1 20170620
> > .config is attached
> > Raw console output is attached.
> >
> > Unfortunately, I don't have any reproducer for this bug yet.
>
> Fault injection found an unchecked register_shrinker() return code.
> Wow, register_shrinker()/unregister_shinker() is possibly frequently called path?
>
>
> struct super_block *sget_userns(struct file_system_type *type,
> int (*test)(struct super_block *,void *),
> int (*set)(struct super_block *,void *),
> int flags, struct user_namespace *user_ns,
> void *data)
> {
> (...snipped...)
> spin_unlock(&sb_lock);
> get_filesystem(type);
> register_shrinker(&s->s_shrink); // Error check required.
> return s;

Yes, this is the case since numa aware shrinkers were introduced. I have
a bit hard time to follow the code flow but why cannot we simply
register the shrinker when we allocate the new super block? We
still have the s_umount held so the shrinker cannot race with the
registration code.

Something like the totally untested and possibly wrong
---
diff --git a/fs/super.c b/fs/super.c
index 994db21f59bf..1eb850413fdf 100644
--- a/fs/super.c
+++ b/fs/super.c
@@ -506,6 +506,11 @@ struct super_block *sget_userns(struct file_system_type *type,
s = alloc_super(type, (flags & ~SB_SUBMOUNT), user_ns);
if (!s)
return ERR_PTR(-ENOMEM);
+ if (register_shrinker(&s->s_shrink)) {
+ up_write(&s->s_umount);
+ destroy_super(s);
+ return ERR_PTR(-ENOMEM);
+ }
goto retry;
}

@@ -522,7 +527,6 @@ struct super_block *sget_userns(struct file_system_type *type,
hlist_add_head(&s->s_instances, &type->fs_supers);
spin_unlock(&sb_lock);
get_filesystem(type);
- register_shrinker(&s->s_shrink);
return s;
}

--
Michal Hocko
SUSE Labs

Michal Hocko

unread,
Nov 21, 2017, 9:06:54ā€ÆAM11/21/17
to Tetsuo Handa, syzbot, ak...@linux-foundation.org, han...@cmpxchg.org, hill...@alibaba-inc.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, min...@kernel.org, sh...@fb.com, syzkall...@googlegroups.com, ying....@intel.com, Al Viro, Dave Chinner
On Tue 21-11-17 15:05:00, Michal Hocko wrote:
> [Cc Al and Dave - email thread starts http://lkml.kernel.org/r/001a113f996099...@google.com]
>
> On Tue 21-11-17 20:11:26, Tetsuo Handa wrote:
> > On 2017/11/21 16:35, syzbot wrote:
> > > Hello,
> > >
> > > syzkaller hit the following crash on ca91659962303d4fd5211a5e4e13df5cbb11e744
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
> > > compiler: gcc (GCC) 7.1.1 20170620
> > > .config is attached
> > > Raw console output is attached.
> > >
> > > Unfortunately, I don't have any reproducer for this bug yet.
> >
> > Fault injection found an unchecked register_shrinker() return code.
> > Wow, register_shrinker()/unregister_shinker() is possibly frequently called path?
> >
> >
> > struct super_block *sget_userns(struct file_system_type *type,
> > int (*test)(struct super_block *,void *),
> > int (*set)(struct super_block *,void *),
> > int flags, struct user_namespace *user_ns,
> > void *data)
> > {
> > (...snipped...)
> > spin_unlock(&sb_lock);
> > get_filesystem(type);
> > register_shrinker(&s->s_shrink); // Error check required.
> > return s;
>
> Yes, this is the case since numa aware shrinkers were introduced.

I meant 1d3d4437eae1 ("vmscan: per-node deferred work")

Michal Hocko

unread,
Nov 23, 2017, 6:26:59ā€ÆAM11/23/17
to Tetsuo Handa, syzbot, ak...@linux-foundation.org, han...@cmpxchg.org, hill...@alibaba-inc.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, min...@kernel.org, sh...@fb.com, syzkall...@googlegroups.com, ying....@intel.com, Al Viro, Dave Chinner
On Tue 21-11-17 15:05:00, Michal Hocko wrote:
> [Cc Al and Dave - email thread starts http://lkml.kernel.org/r/001a113f996099...@google.com]
[...]
> Something like the totally untested and possibly wrong
> ---
> diff --git a/fs/super.c b/fs/super.c
> index 994db21f59bf..1eb850413fdf 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -506,6 +506,11 @@ struct super_block *sget_userns(struct file_system_type *type,
> s = alloc_super(type, (flags & ~SB_SUBMOUNT), user_ns);
> if (!s)
> return ERR_PTR(-ENOMEM);
> + if (register_shrinker(&s->s_shrink)) {
> + up_write(&s->s_umount);
> + destroy_super(s);
> + return ERR_PTR(-ENOMEM);
> + }
> goto retry;
> }
>
> @@ -522,7 +527,6 @@ struct super_block *sget_userns(struct file_system_type *type,
> hlist_add_head(&s->s_instances, &type->fs_supers);
> spin_unlock(&sb_lock);
> get_filesystem(type);
> - register_shrinker(&s->s_shrink);
> return s;
> }

This is not complete. I thought we would unregister the shrinker
somewher in destroy_super path but this is not the case. I will send
another patch along with other shrinkers registration fixes in a
separate thread.

syzbot

unread,
Dec 17, 2017, 10:47:03ā€ÆAM12/17/17
to ak...@linux-foundation.org, da...@fromorbit.com, han...@cmpxchg.org, hill...@alibaba-inc.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, mho...@kernel.org, mho...@suse.com, min...@kernel.org, penguin...@i-love.sakura.ne.jp, shak...@google.com, sh...@fb.com, syzkall...@googlegroups.com, vi...@zeniv.linux.org.uk, ying....@intel.com
syzkaller has found reproducer for the following crash on
82bcf1def3b5f1251177ad47c44f7e17af039b4b
git://git.cmpxchg.org/linux-mmots.git/master
compiler: gcc (GCC) 7.1.1 20170620
.config is attached
Raw console output is attached.
C reproducer is attached
syzkaller reproducer is attached. See https://goo.gl/kgGztJ
for information about syzkaller reproducers


R13: 0000000000403940 R14: 0000000000000000 R15: 0000000000000000
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 3146 Comm: syzkaller259864 Not tainted 4.15.0-rc2-mm1+ #39
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
RSP: 0018:ffff8801c4d97b48 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff8801c4ac75d8 RDI: ffff8801c4ac75e0
RBP: ffff8801c4d97b60 R08: ffff8801c4d975c0 R09: ffff8801c5bd2180
R10: 000000000000000b R11: ffffed00389b2eba R12: 0000000000000000
R13: dffffc0000000000 R14: 1ffff100389b2f8d R15: ffff8801c4ac75d8
FS: 0000000001689940(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000207caf71 CR3: 00000001c5f99002 CR4: 00000000001606e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
__list_del_entry include/linux/list.h:117 [inline]
list_del include/linux/list.h:125 [inline]
unregister_shrinker+0x79/0x300 mm/vmscan.c:285
deactivate_locked_super+0x64/0xd0 fs/super.c:311
deactivate_super+0x141/0x1b0 fs/super.c:343
cleanup_mnt+0xb2/0x150 fs/namespace.c:1173
__cleanup_mnt+0x16/0x20 fs/namespace.c:1180
task_work_run+0x199/0x270 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:191 [inline]
exit_to_usermode_loop+0x275/0x2f0 arch/x86/entry/common.c:165
prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
entry_SYSCALL_64_fastpath+0x94/0x96
RIP: 0033:0x446679
RSP: 002b:00007ffccb258058 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffec RBX: 00007ffccb258000 RCX: 0000000000446679
RDX: 0000000020f9effa RSI: 00000000202b9000 RDI: 0000000020b85ff8
RBP: 0000000000000003 R08: 00000000207caf71 R09: 0000000000003531
R10: 0000000000000000 R11: 0000000000000246 R12: ffffffffffffffff
R13: 0000000000000006 R14: 0000000000000000 R15: 0000000000000000
Code: 00 00 00 00 ad de 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de 48 89
da 48 39 c3 74 65 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df <80> 3c 02 00
75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8
RIP: __list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51 RSP:
ffff8801c4d97b48
---[ end trace 422dd7d3477fece7 ]---
Kernel panic - not syncing: Fatal exception
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..

config.txt
raw.log
repro.txt
repro.c

Michal Hocko

unread,
Dec 18, 2017, 4:55:16ā€ÆAM12/18/17
to syzbot, ak...@linux-foundation.org, da...@fromorbit.com, han...@cmpxchg.org, hill...@alibaba-inc.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, min...@kernel.org, penguin...@i-love.sakura.ne.jp, shak...@google.com, sh...@fb.com, syzkall...@googlegroups.com, vi...@zeniv.linux.org.uk, ying....@intel.com
On Sun 17-12-17 07:47:01, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 82bcf1def3b5f1251177ad47c44f7e17af039b4b
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

This is an unhandled register_shrinker failure in sget_userns (thiggered
by the allocation fault injection).
There has been a fix proposed http://lkml.kernel.org/r/20171123145...@ZenIV.linux.org.uk
(this one depends on http://lkml.kernel.org/r/1511523385-6433-1-git-s...@I-love.SAKURA.ne.jp
or http://lkml.kernel.org/r/20171216192937.135...@gmail.com).

Eric Biggers

unread,
Jan 30, 2018, 3:55:23ā€ÆPM1/30/18
to syzbot, ak...@linux-foundation.org, da...@fromorbit.com, han...@cmpxchg.org, hill...@alibaba-inc.com, linux-...@vger.kernel.org, linu...@kvack.org, mgo...@techsingularity.net, mho...@kernel.org, mho...@suse.com, min...@kernel.org, penguin...@i-love.sakura.ne.jp, shak...@google.com, sh...@fb.com, syzkall...@googlegroups.com, vi...@zeniv.linux.org.uk, ying....@intel.com
Closing this bug since it seems to have been fixed by:

#syz fix: sget(): handle failures of register_shrinker()
Reply all
Reply to author
Forward
0 new messages