WARNING in refcount_inc (2)

21 views
Skip to first unread message

syzbot

unread,
Dec 19, 2017, 3:38:05 AM12/19/17
to da...@davemloft.net, her...@gondor.apana.org.au, linux-...@vger.kernel.org, net...@vger.kernel.org, steffen....@secunet.com, syzkall...@googlegroups.com
Hello,

syzkaller hit the following crash on
6084b576dca2e898f5c101baef151f7bfdbb606d
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.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.


binder: release 623:630 transaction 328 out, still active
binder: undelivered TRANSACTION_COMPLETE
binder: send failed reply for transaction 328, target dead
------------[ cut here ]------------
refcount_t: increment on 0; use-after-free.
WARNING: CPU: 0 PID: 703 at lib/refcount.c:153 refcount_inc+0x47/0x50
lib/refcount.c:153
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 703 Comm: syz-executor3 Not tainted 4.15.0-rc3-next-20171214+
#67
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0xe9/0x14b lib/dump_stack.c:53
panic+0x10e/0x2f8 kernel/panic.c:183
__warn+0x14e/0x150 kernel/panic.c:547
report_bug+0x11e/0x1a0 lib/bug.c:184
fixup_bug.part.11+0x17/0x30 arch/x86/kernel/traps.c:177
fixup_bug arch/x86/kernel/traps.c:246 [inline]
do_error_trap+0x14a/0x180 arch/x86/kernel/traps.c:295
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
RIP: 0010:refcount_inc+0x47/0x50 lib/refcount.c:153
RSP: 0018:ffffc90000dc7aa8 EFLAGS: 00010292
RAX: 000000000000002b RBX: ffff8801e08c5c38 RCX: ffffffff8123dede
RDX: 0000000000004525 RSI: ffffc90003c1b000 RDI: 0000000000000216
RBP: ffffc90000dc7ab0 R08: ffff88021fc1bda8 R09: 0000000000000000
R10: ffffc90000dc7a30 R11: 0000000000000000 R12: 000000000000006c
R13: ffff8801e08c5c38 R14: 0000000000000000 R15: ffff8801e0330100
xfrm_state_hold include/net/xfrm.h:858 [inline]
xfrm_state_flush+0x185/0x2b0 net/xfrm/xfrm_state.c:719
pfkey_flush+0x6f/0xd0 net/key/af_key.c:1753
pfkey_process+0x255/0x290 net/key/af_key.c:2809
pfkey_sendmsg+0x193/0x310 net/key/af_key.c:3648
sock_sendmsg_nosec net/socket.c:636 [inline]
sock_sendmsg+0x51/0x70 net/socket.c:646
___sys_sendmsg+0x35e/0x3b0 net/socket.c:2026
__sys_sendmsg+0x50/0x90 net/socket.c:2060
SYSC_sendmsg net/socket.c:2071 [inline]
SyS_sendmsg+0x2d/0x50 net/socket.c:2067
entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x452a39
RSP: 002b:00007f6bbd99dc58 EFLAGS: 00000212 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: cccccccccccccccd RCX: 0000000000452a39
RDX: 0000000000000080 RSI: 000000002019d000 RDI: 0000000000000016
RBP: 00000000000005be R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f6a70
R13: 00000000ffffffff R14: 00007f6bbd99e6d4 R15: 0000000000000000
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
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 merged into any tree, 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

syzbot

unread,
Dec 19, 2017, 2:26:03 PM12/19/17
to ak...@linux-foundation.org, da...@davemloft.net, deepa....@gmail.com, gscr...@redhat.com, her...@gondor.apana.org.au, linux-...@vger.kernel.org, luc.vano...@gmail.com, mi...@kernel.org, net...@vger.kernel.org, s...@canb.auug.org.au, steffen....@secunet.com, syzkall...@googlegroups.com, vi...@zeniv.linux.org.uk, xiyou.w...@gmail.com
syzkaller has found reproducer for the following crash on
6084b576dca2e898f5c101baef151f7bfdbb606d
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.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


audit: type=1400 audit(1513711436.700:7): avc: denied { map } for
pid=3124 comm="syzkaller396275" path="/root/syzkaller396275826" dev="sda1"
ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1
------------[ cut here ]------------
refcount_t: increment on 0; use-after-free.
WARNING: CPU: 1 PID: 3125 at lib/refcount.c:153 refcount_inc+0x47/0x50
lib/refcount.c:153
Kernel panic - not syncing: panic_on_warn set ...

CPU: 1 PID: 3125 Comm: syzkaller396275 Not tainted
4.15.0-rc3-next-20171214+ #67
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0xe9/0x14b lib/dump_stack.c:53
panic+0x10e/0x2f8 kernel/panic.c:183
__warn+0x14e/0x150 kernel/panic.c:547
report_bug+0x11e/0x1a0 lib/bug.c:184
fixup_bug.part.11+0x17/0x30 arch/x86/kernel/traps.c:177
fixup_bug arch/x86/kernel/traps.c:246 [inline]
do_error_trap+0x14a/0x180 arch/x86/kernel/traps.c:295
do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:314
invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1079
RIP: 0010:refcount_inc+0x47/0x50 lib/refcount.c:153
RSP: 0018:ffffc9000186bb90 EFLAGS: 00010282
RAX: 000000000000002b RBX: ffff880214e2f800 RCX: ffffffff8123dede
RDX: 0000000000000000 RSI: ffff880214d5f018 RDI: 0000000000000293
RBP: ffffc9000186bb98 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc9000186bb18 R11: 0000000000000000 R12: ffffffff8162ef10
R13: ffff8802156d2578 R14: ffff8802156d2600 R15: 0000000000000001
get_ipc_ns include/linux/ipc_namespace.h:129 [inline]
__get_ns_from_inode ipc/mqueue.c:110 [inline]
get_ns_from_inode ipc/mqueue.c:118 [inline]
mqueue_evict_inode+0x69/0x340 ipc/mqueue.c:402
evict+0x102/0x230 fs/inode.c:552
iput_final fs/inode.c:1514 [inline]
iput+0x32b/0x400 fs/inode.c:1541
dentry_unlink_inode+0x1ab/0x1e0 fs/dcache.c:375
__dentry_kill+0x12d/0x210 fs/dcache.c:572
shrink_dentry_list+0x140/0x660 fs/dcache.c:1019
shrink_dcache_parent+0x2f/0x90 fs/dcache.c:1453
do_one_tree+0x15/0x50 fs/dcache.c:1484
shrink_dcache_for_umount+0x37/0xb0 fs/dcache.c:1501
generic_shutdown_super+0x2d/0x170 fs/super.c:424
kill_anon_super fs/super.c:987 [inline]
kill_litter_super+0x36/0x50 fs/super.c:997
deactivate_locked_super+0x4d/0x80 fs/super.c:312
deactivate_super+0x61/0x90 fs/super.c:343
cleanup_mnt+0x49/0x90 fs/namespace.c:1173
__cleanup_mnt+0x16/0x20 fs/namespace.c:1180
task_work_run+0xa3/0xe0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x3e6/0x1050 kernel/exit.c:869
do_group_exit+0x60/0x100 kernel/exit.c:972
SYSC_exit_group kernel/exit.c:983 [inline]
SyS_exit_group+0x18/0x20 kernel/exit.c:981
entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x4406f9
RSP: 002b:00007ffde12b8798 EFLAGS: 00000206 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0030656c69662f2e RCX: 00000000004406f9
RDX: 00000000004406f9 RSI: 00000000004406f9 RDI: 0000000000000001
RBP: 00000000006cb018 R08: 0000000000000000 R09: 00000000004002c8
R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000401bc0
R13: 0000000000401c50 R14: 0000000000000000 R15: 0000000000000000
config.txt
raw.log
repro.txt
repro.c

Eric Biggers

unread,
Jan 31, 2018, 2:27:54 AM1/31/18
to syzbot, ak...@linux-foundation.org, da...@davemloft.net, deepa....@gmail.com, gscr...@redhat.com, her...@gondor.apana.org.au, linux-...@vger.kernel.org, luc.vano...@gmail.com, mi...@kernel.org, net...@vger.kernel.org, s...@canb.auug.org.au, steffen....@secunet.com, syzkall...@googlegroups.com, vi...@zeniv.linux.org.uk, xiyou.w...@gmail.com
I'm not able to reproduce this anymore. Looks like it was another report of the
bug in the patch "ipc, mqueue: lazy call kern_mount_data in new namespaces"
which was present in linux-next for a while but was replaced by "mqueue: switch
to on-demand creation of internal mount" which no longer has the bug.

This report was also on the linux-next version where KASAN had accidentally
gotten disabled in the syzbot config.

So, I'm invalidating this bug so that syzbot can report similar crashes again:

#syz invalid

Also Dmitry, syzbot seems to be grouping together unrelated bugs under the
refcount_t WARNINGs; maybe those should be on a blacklist?

- Eric

Andrey Konovalov

unread,
Feb 1, 2018, 9:34:57 AM2/1/18
to Eric Biggers, syzbot, Andrew Morton, David S. Miller, Deepa Dinamani, gscr...@redhat.com, Herbert Xu, LKML, luc.vano...@gmail.com, Ingo Molnar, netdev, Stephen Rothwell, Steffen Klassert, syzkall...@googlegroups.com, Alexander Viro, Cong Wang
On Wed, Jan 31, 2018 at 8:27 AM, Eric Biggers <ebig...@gmail.com> wrote:
>
> Also Dmitry, syzbot seems to be grouping together unrelated bugs under the
> refcount_t WARNINGs; maybe those should be on a blacklist?

Not a blacklist, we need a proper way of extracting the offending
caller like it's done for reports from __this_cpu_* [1].

[1] https://github.com/google/syzkaller/blob/master/pkg/report/linux.go#L579

Dmitry Vyukov

unread,
Feb 1, 2018, 11:24:35 AM2/1/18
to Andrey Konovalov, Eric Biggers, syzbot, Andrew Morton, David S. Miller, Deepa Dinamani, Giuseppe Scrivano, Herbert Xu, LKML, luc.vano...@gmail.com, Ingo Molnar, netdev, Stephen Rothwell, Steffen Klassert, syzkall...@googlegroups.com, Alexander Viro, Cong Wang
Thanks, I've added this as a test case:
https://github.com/google/syzkaller/commit/e525e980eaed440e278614b9e887270ca67d2dde

We mishandle __this_cpu_* as well:
https://github.com/google/syzkaller/blob/master/pkg/report/testdata/linux/report/136
https://github.com/google/syzkaller/blob/master/pkg/report/testdata/linux/report/137
It does not seem that regexps can sustain this anymore (we also
mishandle rcu stalls and some other cases), I guess we need manual
parsing of stack traces that can handle all these cases.
Reply all
Reply to author
Forward
0 new messages