Re: KASAN: use-after-free Read in ax25_fillin_cb
Hi, Joerg On Sat, Dec 29, 2018 at 2:06 PM Joerg Reuter wrote: > Unfortunately, I'm on a low bandwidth connection right now. I'd be > grateful if someone could create a patch. This is likely not a high > impact issue (unpriviliged users can't set up or tear down interfaces), > still it may cause hard to find memory corruptions. I already sent a patch: http://patchwork.ozlabs.org/patch/1019386/ Sorry for forgetting to Cc more people. Thanks.
KASAN: stack-out-of-bounds Write in ax25_getname
Hello, syzbot found the following crash on: HEAD commit:8fe28cb58bcb Linux 4.20 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1604d02d40 kernel config: https://syzkaller.appspot.com/x/.config?x=7d581260bae0899a dashboard link: https://syzkaller.appspot.com/bug?extid=6a29097222b4d3b8617c compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=114a9ec340 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+6a29097222b4d3b86...@syzkaller.appspotmail.com IPv6: ADDRCONF(NETDEV_UP): veth1: link is not ready IPv6: ADDRCONF(NETDEV_CHANGE): veth1: link becomes ready IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready 8021q: adding VLAN 0 to HW filter on device team0 == BUG: KASAN: stack-out-of-bounds in memset include/linux/string.h:337 [inline] BUG: KASAN: stack-out-of-bounds in ax25_getname+0x58/0x790 net/ax25/af_ax25.c:1399 Write of size 72 at addr 8881d8547b80 by task syz-executor0/8181 CPU: 0 PID: 8181 Comm: syz-executor0 Not tainted 4.20.0 #166 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113 print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412 check_memory_region_inline mm/kasan/kasan.c:260 [inline] check_memory_region+0x13e/0x1b0 mm/kasan/kasan.c:267 memset+0x23/0x40 mm/kasan/kasan.c:285 memset include/linux/string.h:337 [inline] ax25_getname+0x58/0x790 net/ax25/af_ax25.c:1399 get_raw_socket drivers/vhost/net.c:1397 [inline] get_socket drivers/vhost/net.c:1453 [inline] vhost_net_set_backend drivers/vhost/net.c:1488 [inline] vhost_net_ioctl+0x139c/0x1bf0 drivers/vhost/net.c:1679 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0x1de/0x1790 fs/ioctl.c:696 ksys_ioctl+0xa9/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x457759 Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f25cd3fbc78 EFLAGS: 0246 ORIG_RAX: 0010 RAX: ffda RBX: 0003 RCX: 00457759 RDX: 20f1dff8 RSI: 4008af30 RDI: 0004 RBP: 0073bf00 R08: R09: R10: R11: 0246 R12: 7f25cd3fc6d4 R13: 004c1dd4 R14: 004d40e0 R15: The buggy address belongs to the page: page:ea00076151c0 count:0 mapcount:0 mapping: index:0x0 flags: 0x2fffc00() raw: 02fffc00 07610101 raw: page dumped because: kasan: bad access detected Memory state around the buggy address: 8881d8547a80: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2 8881d8547b00: 00 f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2 8881d8547b80: 00 00 00 00 00 00 04 f2 00 00 00 00 00 00 00 00 ^ 8881d8547c00: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 8881d8547c80: f2 f2 f2 f2 f2 f2 00 00 00 f2 f2 f2 f2 f2 00 00 == --- This bug 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 syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: KASAN: use-after-free Read in ax25_fillin_cb
On Fri, Dec 28, 2018 at 02:51:04PM -0800, syzbot wrote:
> BUG: KASAN: use-after-free in ax25_fillin_cb_from_dev net/ax25/af_ax25.c:450
> [inline]
> BUG: KASAN: use-after-free in ax25_fillin_cb+0x6d5/0x810
> net/ax25/af_ax25.c:477
> Read of size 4 at addr 8881ccecc438 by task syz-executor5/11370
Not good... Why do things like this always pop up when I'm traveling?
> ax25_fillin_cb_from_dev net/ax25/af_ax25.c:450 [inline]
> ax25_fillin_cb+0x6d5/0x810 net/ax25/af_ax25.c:477
> ax25_setsockopt+0x92a/0xa20 net/ax25/af_ax25.c:663
That's here:
// ...
case SO_BINDTODEVICE:
// ...
dev = dev_get_by_name(&init_net, devname);
if (!dev) {
res = -ENODEV;
break;
}
ax25->ax25_dev = ax25_dev_ax25dev(dev);
ax25_fillin_cb(ax25, ax25->ax25_dev);
dev_put(dev);
break;
Thus, dev is not NULL, and neither is dev->ax25_ptr.
> Freed by task 11339:
> [..]
> ax25_dev_device_down+0x164/0x2f0 net/ax25/ax25_dev.c:129
> ax25_device_event+0x1f6/0x2e0 net/ax25/af_ax25.c:131
> notifier_call_chain+0x17e/0x380 kernel/notifier.c:93
ax25_dev_device_down() has this:
if ((s = ax25_dev_list) == ax25_dev) {
ax25_dev_list = s->next;
spin_unlock_bh(&ax25_dev_lock);
dev_put(dev);
kfree(ax25_dev);
return;
}
while (s != NULL && s->next != NULL) {
if (s->next == ax25_dev) {
s->next = ax25_dev->next;
spin_unlock_bh(&ax25_dev_lock);
dev_put(dev);
kfree(ax25_dev); // < here
return;
}
s = s->next;
}
spin_unlock_bh(&ax25_dev_lock);
dev->ax25_ptr = NULL;
I hope I didn't write this... *shudders*
Anyway, we are indeed missing to set dev->ax25_ptr to NULL if we're at
the head or somewhere on the ax25_dev_list, probably because it will be
cleaned up on removal of dev anyway. Unfortunately, in the meantime
either someone could call setsockopt() on an existing socket, or the
setsockopt() call got interrupted. From my POV the SO_BINDTODEVICE needs
to get protected by this:
spin_lock_bh(&ax25_dev_lock);
ax25->ax25_dev = ax25_dev_ax25dev(dev);
if (ax25->ax25_dev != NULL) {
ax25_fillin_cb(ax25, ax25->ax25_dev);
dev_put(dev);
}
spin_unlock_bh(&ax25_dev_lock);
and ax25_dev_device_down() needs to be rewritten and ensure
that dev->ax25_ptr gets set to NULL after each kfree(ax25_dev)
Unfortunately, I'm on a low bandwidth connection right now. I'd be
grateful if someone could create a patch. This is likely not a high
impact issue (unpriviliged users can't set up or tear down interfaces),
still it may cause hard to find memory corruptions.
- Joerg (yes, I'm still alive)
--
Joerg Reuterhttp://yaina.de/jreuter
And I make my way to where the warm scent of soil fills the evening air.
Everything is waiting quietly out there (Anne Clark)
inconsistent lock state in nr_find_socket
Hello,
syzbot found the following crash on:
HEAD commit:5694cecdb092 Merge tag 'arm64-upstream' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=129ee73f40
kernel config: https://syzkaller.appspot.com/x/.config?x=91a256823ef17263
dashboard link: https://syzkaller.appspot.com/bug?extid=f621cda8b7e598908efa
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13b2b42d40
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1220489f40
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f621cda8b7e598908...@syzkaller.appspotmail.com
WARNING: inconsistent lock state
4.20.0+ #389 Not tainted
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
syz-executor820/11913 [HC0[0]:SC0[0]:HE1:SE1] takes:
3a3617a7 (slock-AF_NETROM){+.?.}, at: spin_lock
include/linux/spinlock.h:329 [inline]
3a3617a7 (slock-AF_NETROM){+.?.}, at: nr_find_socket+0x113/0x160
net/netrom/af_netrom.c:177
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2d/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
nr_find_listener net/netrom/af_netrom.c:156 [inline]
nr_rx_frame+0x5f8/0x1db0 net/netrom/af_netrom.c:955
nr_loopback_timer+0x79/0x160 net/netrom/nr_loopback.c:62
call_timer_fn+0x272/0x920 kernel/time/timer.c:1325
expire_timers kernel/time/timer.c:1362 [inline]
__run_timers+0x7e5/0xc70 kernel/time/timer.c:1681
run_timer_softirq+0x52/0xb0 kernel/time/timer.c:1694
__do_softirq+0x30c/0xb2e kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x17f/0x1c0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
arch_local_irq_restore arch/x86/include/asm/paravirt.h:761 [inline]
lock_acquire+0x268/0x520 kernel/locking/lockdep.c:3847
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2d/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:329 [inline]
do_anonymous_page mm/memory.c:2947 [inline]
handle_pte_fault mm/memory.c:3763 [inline]
__handle_mm_fault+0x298c/0x5670 mm/memory.c:3889
handle_mm_fault+0x54f/0xc70 mm/memory.c:3926
do_user_addr_fault arch/x86/mm/fault.c:1423 [inline]
__do_page_fault+0x5e8/0xe60 arch/x86/mm/fault.c:1489
do_page_fault+0xf2/0x7e0 arch/x86/mm/fault.c:1520
page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1143
irq event stamp: 294
hardirqs last enabled at (292): []
trace_hardirqs_on_thunk+0x1a/0x1c
hardirqs last disabled at (293): []
__local_bh_enable_ip+0x120/0x260 kernel/softirq.c:171
softirqs last enabled at (294): [] spin_unlock_bh
include/linux/spinlock.h:374 [inline]
softirqs last enabled at (294): []
nr_find_socket+0x128/0x160 net/netrom/af_netrom.c:183
softirqs last disabled at (290): [] spin_lock_bh
include/linux/spinlock.h:334 [inline]
softirqs last disabled at (290): []
nr_find_socket+0x24/0x160 net/netrom/af_netrom.c:172
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(slock-AF_NETROM);
lock(slock-AF_NETROM);
*** DEADLOCK ***
1 lock held by syz-executor820/11913:
#0: 3a3617a7 (slock-AF_NETROM){+.?.}, at: spin_lock
include/linux/spinlock.h:329 [inline]
#0: 3a3617a7 (slock-AF_NETROM){+.?.}, at:
nr_find_socket+0x113/0x160 net/netrom/af_netrom.c:177
stack backtrace:
CPU: 0 PID: 11913 Comm: syz-executor820 Not tainted 4.20.0+ #389
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d3/0x2c6 lib/dump_stack.c:113
print_usage_bug.cold.59+0x320/0x41a kernel/locking/lockdep.c:2472
valid_state kernel/locking/lockdep.c:2485 [inline]
mark_lock_irq kernel/locking/lockdep.c:2679 [inline]
mark_lock+0x1114/0x1cc0 kernel/locking/lockdep.c:3059
mark_held_locks+0xc7/0x130 kernel/locking/lockdep.c:2737
__trace_hardirqs_on_caller kernel/locking/lockdep.c:2766 [inline]
lockdep_hardirqs_on+0x421/0x5c0 kernel/locking/lockdep.c:2811
trace_hardirqs_on+0xbd/0x310 kernel/trace/trace_preemptirq.c:30
__local_bh_enable_ip+0x160/0x260 kernel/softirq.c:194
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:176 [inline]
_raw_spin_unlock_bh+0x30/0x40 kernel/locking/spinlock.c:200
spin_unlock_bh include/linux/spinlock.h:374 [inline]
nr_find_socket+0x128/0x160 net/netrom/af_netrom.c:183
nr_find_next_circuit+0x71/0x90 net/netrom/af_netrom.c:225
nr_connect+0x6cb/0x1350 net/netrom/af_netrom.c:704
__sys_connect+0x37d/0x4c0 net/sock
