BUG: KASAN: global-out-of-bounds in strscpy+0x807/0x970

From: Jakub Kicinski <kubakici@wp.pl>
To: Tyler Hicks <tyhicks@canonical.com>, Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: BUG: KASAN: global-out-of-bounds in strscpy+0x807/0x970
Date: Tue, 10 Oct 2017 18:28:05 -0700	[thread overview]
Message-ID: <20171010182805.52b9b2af@cakuba.netronome.com> (raw)

I'm hitting this on sysctl -a with net-next (4.14-rc4).

I saw that seccomp_actions_logged_handler was introduced
not-so-long-ago by Tyler, is there a fix for this?

[  753.503760] BUG: KASAN: global-out-of-bounds in strscpy+0x807/0x970
[  753.510892] Read of size 8 at addr ffffffffa96b97c8 by task sysctl/1787
[  753.518416] 
[  753.520198] CPU: 1 PID: 1787 Comm: sysctl Not tainted 4.14.0-rc4-debug-00822-g07ec06ef312a #316
[  753.538598] Call Trace:
[  753.541449]  dump_stack+0xb3/0x140
[  753.545372]  ? _atomic_dec_and_lock+0x2b0/0x2b0
[  753.550564]  ? show_regs_print_info+0x6d/0x6d
[  753.555562]  print_address_description+0x25f/0x440
[  753.561044]  ? strscpy+0x807/0x970
[  753.564967]  kasan_report+0x1b8/0x430
[  753.569182]  ? strscpy+0x807/0x970
[  753.573107]  strscpy+0x807/0x970
[  753.576838]  ? strncpy+0xf0/0xf0
[  753.580576]  ? sched_clock_cpu+0x18/0x290
[  753.585185]  seccomp_actions_logged_handler+0x384/0x8d0
[  753.591157]  ? seccomp_send_sigsys+0xa0/0xa0
[  753.596046]  ? lock_downgrade+0x740/0x740
[  753.600648]  ? get_lock_stats+0x18/0x160
[  753.605159]  ? sysctl_head_grab+0x1b/0xc0
[  753.609766]  ? lock_contended+0x1130/0x1130
[  753.614566]  ? lock_release+0x14e0/0x14e0
[  753.619171]  ? do_raw_spin_trylock+0x1c0/0x1c0
[  753.624261]  ? lock_downgrade+0x660/0x740
[  753.628858]  ? do_raw_spin_lock+0x1f0/0x1f0
[  753.633657]  proc_sys_call_handler+0x216/0x3c0
[  753.638752]  ? proc_sys_permission+0x250/0x250
[  753.643847]  ? do_mmap+0x622/0xf50
[  753.647772]  __vfs_read+0xea/0x9a0
[  753.651696]  ? vfs_copy_file_range+0xc60/0xc60
[  753.656787]  ? security_mmap_file+0x66/0x1d0
[  753.661686]  ? common_file_perm+0x1e0/0x6b0
[  753.666485]  ? vm_mmap_pgoff+0x1b6/0x250
[  753.670993]  ? fsnotify+0x1c80/0x1c80
[  753.675209]  ? apparmor_task_setrlimit+0x690/0x690
[  753.680687]  ? vma_is_stack_for_current+0xb0/0xb0
[  753.686073]  vfs_read+0x109/0x3e0
[  753.689900]  SyS_read+0xcc/0x1d0
[  753.693628]  ? kernel_write+0x1a0/0x1a0
[  753.698034]  ? trace_hardirqs_on_caller+0x3cb/0x680
[  753.703610]  ? trace_hardirqs_on_thunk+0x1a/0x1c
[  753.708898]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  753.714180] RIP: 0033:0x7f62c82296b0
[  753.718294] RSP: 002b:00007ffc2d6726c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[  753.726919] RAX: ffffffffffffffda RBX: 0000000000000046 RCX: 00007f62c82296b0
[  753.735028] RDX: 0000000000000400 RSI: 00007f62c8722000 RDI: 0000000000000006
[  753.743138] RBP: 0000000000000000 R08: 00000000ffffffff R09: 0000000000000000
[  753.751246] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000
[  753.759355] R13: 0000000001d63650 R14: 00007f62c87186a0 R15: 0000000000000028
[  753.767478] 
[  753.769256] The buggy address belongs to the variable:
[  753.775125]  kprobes_seq_ops+0x1268/0x15c0
[  753.779820] 
[  753.781595] Memory state around the buggy address:
[  753.787075]  ffffffffa96b9680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  753.795301]  ffffffffa96b9700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  753.803526] >ffffffffa96b9780: 07 fa fa fa fa fa fa fa 00 05 fa fa fa fa fa fa
[  753.811751]                                               ^
[  753.818105]  ffffffffa96b9800: 02 fa fa fa fa fa fa fa 00 00 04 fa fa fa fa fa
[  753.826330]  ffffffffa96b9880: 00 00 00 01 fa fa fa fa 00 00 00 00 01 fa fa fa
[  753.834554] ==================================================================