sctp: kernel memory overwrite attempt detected in sctp_getsockopt_assoc_stats
154 views
Skip to first unread message
Dmitry Vyukov
Jan 15, 2017, 12:30:20 PM1/15/17
to Vladislav Yasevich, Neil Horman, David Miller, linux...@vger.kernel.org, netdev, LKML, Kees Cook, syzkaller
Hello,
I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and
now I am seeing lots of:
usercopy: kernel memory overwrite attempt detected to ffff8801a74f6f10
(<spans multiple pages>) (256 bytes)
kernel BUG at mm/usercopy.c:75!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 15686 Comm: syz-executor3 Not tainted 4.9.0 #1
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
task: ffff8801c89b2500 task.stack: ffff8801a74f0000
RIP: 0010:[<ffffffff81a1b041>] [<ffffffff81a1b041>] report_usercopy
mm/usercopy.c:67 [inline]
RIP: 0010:[<ffffffff81a1b041>] [<ffffffff81a1b041>]
__check_object_size+0x2d1/0x9ec mm/usercopy.c:278
RSP: 0018:ffff8801a74f6cd0 EFLAGS: 00010286
RAX: 000000000000006b RBX: ffffffff84500120 RCX: 0000000000000000
RDX: 000000000000006b RSI: ffffffff815a7791 RDI: ffffed0034e9ed8c
RBP: ffff8801a74f6e48 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff8801a74f6f10
R13: 0000000000000100 R14: ffffffff845000e0 R15: ffff8801a74f700f
FS: 00007f80918de700(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020058ffc CR3: 00000001cc1cc000 CR4: 00000000001406e0
Stack:
ffffffff8598fcc8 0000000000000000 000077ff80000000 ffffea0005c99608
ffffffff844fff40 ffffffff844fff40 0000000041b58ab3 ffffffff84ae0fa0
ffffffff81a1ad70 ffff8801c89b2500 dead000000000100 ffffffff814d4425
Call Trace:
[<ffffffff83e4ece9>] check_object_size include/linux/thread_info.h:129 [inline]
[<ffffffff83e4ece9>] copy_from_user arch/x86/include/asm/uaccess.h:692 [inline]
[<ffffffff83e4ece9>] sctp_getsockopt_assoc_stats+0x169/0xa10
net/sctp/socket.c:6182
[<ffffffff83e5cc52>] sctp_getsockopt+0x1af2/0x66a0 net/sctp/socket.c:6556
[<ffffffff834f92c5>] sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2649
[<ffffffff834f4910>] SYSC_getsockopt net/socket.c:1788 [inline]
[<ffffffff834f4910>] SyS_getsockopt+0x240/0x380 net/socket.c:1770
[<ffffffff81009798>] do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:280
[<ffffffff84370a49>] entry_SYSCALL64_slow_path+0x25/0x25
Code: b0 fe ff ff e8 e1 25 ce ff 48 8b 85 b0 fe ff ff 4d 89 e9 4c 89
e1 4c 89 f2 48 89 de 48 c7 c7 a0 01 50 84 49 89 c0 e8 51 d9 e0 ff <0f>
0b e8 b8 25 ce ff 4c 89 f2 4c 89 ee 4c 89 e7 e8 6a 1b fc ff
RIP [<ffffffff81a1b041>] report_usercopy mm/usercopy.c:67 [inline]
RIP [<ffffffff81a1b041>] __check_object_size+0x2d1/0x9ec mm/usercopy.c:278
RSP <ffff8801a74f6cd0>
---[ end trace 5e438996b2c0b35d ]---
I am not sure why check_object_size flags this an a bug,
copy_from_user copies into a stack object:
static int sctp_getsockopt_assoc_stats(struct sock *sk, int len,
char __user *optval,
int __user *optlen)
{
struct sctp_assoc_stats sas;
len = min_t(size_t, len, sizeof(sas));
if (copy_from_user(&sas, optval, len))
return -EFAULT;
Kees, can this be a false positive?
On commit f4d3935e4f4884ba80561db5549394afb8eef8f7.
I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and
now I am seeing lots of:
usercopy: kernel memory overwrite attempt detected to ffff8801a74f6f10
(<spans multiple pages>) (256 bytes)
kernel BUG at mm/usercopy.c:75!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
(ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 15686 Comm: syz-executor3 Not tainted 4.9.0 #1
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
task: ffff8801c89b2500 task.stack: ffff8801a74f0000
RIP: 0010:[<ffffffff81a1b041>] [<ffffffff81a1b041>] report_usercopy
mm/usercopy.c:67 [inline]
RIP: 0010:[<ffffffff81a1b041>] [<ffffffff81a1b041>]
__check_object_size+0x2d1/0x9ec mm/usercopy.c:278
RSP: 0018:ffff8801a74f6cd0 EFLAGS: 00010286
RAX: 000000000000006b RBX: ffffffff84500120 RCX: 0000000000000000
RDX: 000000000000006b RSI: ffffffff815a7791 RDI: ffffed0034e9ed8c
RBP: ffff8801a74f6e48 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff8801a74f6f10
R13: 0000000000000100 R14: ffffffff845000e0 R15: ffff8801a74f700f
FS: 00007f80918de700(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020058ffc CR3: 00000001cc1cc000 CR4: 00000000001406e0
Stack:
ffffffff8598fcc8 0000000000000000 000077ff80000000 ffffea0005c99608
ffffffff844fff40 ffffffff844fff40 0000000041b58ab3 ffffffff84ae0fa0
ffffffff81a1ad70 ffff8801c89b2500 dead000000000100 ffffffff814d4425
Call Trace:
[<ffffffff83e4ece9>] check_object_size include/linux/thread_info.h:129 [inline]
[<ffffffff83e4ece9>] copy_from_user arch/x86/include/asm/uaccess.h:692 [inline]
[<ffffffff83e4ece9>] sctp_getsockopt_assoc_stats+0x169/0xa10
net/sctp/socket.c:6182
[<ffffffff83e5cc52>] sctp_getsockopt+0x1af2/0x66a0 net/sctp/socket.c:6556
[<ffffffff834f92c5>] sock_common_getsockopt+0x95/0xd0 net/core/sock.c:2649
[<ffffffff834f4910>] SYSC_getsockopt net/socket.c:1788 [inline]
[<ffffffff834f4910>] SyS_getsockopt+0x240/0x380 net/socket.c:1770
[<ffffffff81009798>] do_syscall_64+0x2e8/0x930 arch/x86/entry/common.c:280
[<ffffffff84370a49>] entry_SYSCALL64_slow_path+0x25/0x25
Code: b0 fe ff ff e8 e1 25 ce ff 48 8b 85 b0 fe ff ff 4d 89 e9 4c 89
e1 4c 89 f2 48 89 de 48 c7 c7 a0 01 50 84 49 89 c0 e8 51 d9 e0 ff <0f>
0b e8 b8 25 ce ff 4c 89 f2 4c 89 ee 4c 89 e7 e8 6a 1b fc ff
RIP [<ffffffff81a1b041>] report_usercopy mm/usercopy.c:67 [inline]
RIP [<ffffffff81a1b041>] __check_object_size+0x2d1/0x9ec mm/usercopy.c:278
RSP <ffff8801a74f6cd0>
---[ end trace 5e438996b2c0b35d ]---
I am not sure why check_object_size flags this an a bug,
copy_from_user copies into a stack object:
static int sctp_getsockopt_assoc_stats(struct sock *sk, int len,
char __user *optval,
int __user *optlen)
{
struct sctp_assoc_stats sas;
len = min_t(size_t, len, sizeof(sas));
if (copy_from_user(&sas, optval, len))
return -EFAULT;
Kees, can this be a false positive?
On commit f4d3935e4f4884ba80561db5549394afb8eef8f7.
Dmitry Vyukov
Jan 16, 2017, 2:12:01 AM1/16/17
to Neil Horman, Vladislav Yasevich, David Miller, linux...@vger.kernel.org, netdev, LKML, Kees Cook, syzkaller
On Sun, Jan 15, 2017 at 9:35 PM, Neil Horman <nho...@tuxdriver.com> wrote:
> the Kconfig:
> onfig HARDENED_USERCOPY_PAGESPAN
> bool "Refuse to copy allocations that span multiple pages"
> depends on HARDENED_USERCOPY
> depends on EXPERT
> help
> When a multi-page allocation is done without __GFP_COMP,
> hardened usercopy will reject attempts to copy it. There are,
> however, several cases of this in the kernel that have not all
> been removed. This config is intended to be used only while
> trying to find such users.
>
> So, if the fuzzer does a setsockopt and the data it passes crosses a page
> boundary, it seems like this will get triggered. Based on the fact that its
> only used to find users that do this, it seems like not the sort of thing that
> you want enabled while running a fuzzer that might do it arbitrarily.
The code also takes into account compound pages. As far as I
understand the intention of the check is to effectively find
out-of-bounds copies (e.g. goes beyond the current heap allocation). I
would expect that stacks are allocated as compound pages and don't
trigger this check. I don't see it is firing in other similar places.
> On Sun, Jan 15, 2017 at 06:29:59PM +0100, Dmitry Vyukov wrote:
>> Hello,
>>
>> I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and
>> now I am seeing lots of:
>>
> If I'm not mistaken, its because thats specifically what that option does. From
>> Hello,
>>
>> I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and
>> now I am seeing lots of:
>>
> the Kconfig:
> onfig HARDENED_USERCOPY_PAGESPAN
> bool "Refuse to copy allocations that span multiple pages"
> depends on HARDENED_USERCOPY
> depends on EXPERT
> help
> When a multi-page allocation is done without __GFP_COMP,
> hardened usercopy will reject attempts to copy it. There are,
> however, several cases of this in the kernel that have not all
> been removed. This config is intended to be used only while
> trying to find such users.
>
> So, if the fuzzer does a setsockopt and the data it passes crosses a page
> boundary, it seems like this will get triggered. Based on the fact that its
> only used to find users that do this, it seems like not the sort of thing that
> you want enabled while running a fuzzer that might do it arbitrarily.
The code also takes into account compound pages. As far as I
understand the intention of the check is to effectively find
out-of-bounds copies (e.g. goes beyond the current heap allocation). I
would expect that stacks are allocated as compound pages and don't
trigger this check. I don't see it is firing in other similar places.
Dmitry Vyukov
Jan 16, 2017, 9:04:05 AM1/16/17
to Neil Horman, Vladislav Yasevich, David Miller, linux...@vger.kernel.org, netdev, LKML, Kees Cook, syzkaller
On Mon, Jan 16, 2017 at 2:57 PM, Neil Horman <nho...@tuxdriver.com> wrote:
> Honestly, I'm not overly familiar with stack page allocation, at least not so
> far as compound vs. single page allocation is concerned. I suppose the question
> your really asking here is: Have you found a case in which the syscall fuzzer
> has forced the allocation of an insecure non-compound page on the stack, or is
> this a false positive warning. I can't provide the answer to that.
Yes. I added Kees, author of CONFIG_HARDENED_USERCOPY_PAGESPAN, to To line.
Kees, is this a false positive?
> far as compound vs. single page allocation is concerned. I suppose the question
> your really asking here is: Have you found a case in which the syscall fuzzer
> has forced the allocation of an insecure non-compound page on the stack, or is
> this a false positive warning. I can't provide the answer to that.
Yes. I added Kees, author of CONFIG_HARDENED_USERCOPY_PAGESPAN, to To line.
Kees, is this a false positive?
David Laight
Jan 16, 2017, 9:50:53 AM1/16/17
to Dmitry Vyukov, Neil Horman, Vladislav Yasevich, David Miller, linux...@vger.kernel.org, netdev, LKML, Kees Cook, syzkaller
From: Dmitry Vyukov
> Sent: 16 January 2017 14:04
rather than by a single multi-page allocate.
Or maybe vmalloc() isn't setting the required flag??
David
> Sent: 16 January 2017 14:04
> >> >> I've enabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzkaller fuzzer and
...
> >> The code also takes into account compound pages. As far as I
> >> understand the intention of the check is to effectively find
> >> out-of-bounds copies (e.g. goes beyond the current heap allocation). I
> >> would expect that stacks are allocated as compound pages and don't
> >> trigger this check. I don't see it is firing in other similar places.
> >>
> > Honestly, I'm not overly familiar with stack page allocation, at least not so
> > far as compound vs. single page allocation is concerned. I suppose the question
> > your really asking here is: Have you found a case in which the syscall fuzzer
> > has forced the allocation of an insecure non-compound page on the stack, or is
> > this a false positive warning. I can't provide the answer to that.
>
> Yes. I added Kees, author of CONFIG_HARDENED_USERCOPY_PAGESPAN, to To line.
> Kees, is this a false positive?
I'd guess that the kernel stack is (somehow) allocated page by page
> >> understand the intention of the check is to effectively find
> >> out-of-bounds copies (e.g. goes beyond the current heap allocation). I
> >> would expect that stacks are allocated as compound pages and don't
> >> trigger this check. I don't see it is firing in other similar places.
> >>
> > Honestly, I'm not overly familiar with stack page allocation, at least not so
> > far as compound vs. single page allocation is concerned. I suppose the question
> > your really asking here is: Have you found a case in which the syscall fuzzer
> > has forced the allocation of an insecure non-compound page on the stack, or is
> > this a false positive warning. I can't provide the answer to that.
>
> Yes. I added Kees, author of CONFIG_HARDENED_USERCOPY_PAGESPAN, to To line.
> Kees, is this a false positive?
rather than by a single multi-page allocate.
Or maybe vmalloc() isn't setting the required flag??
David
Dmitry Vyukov
Jan 16, 2017, 9:56:28 AM1/16/17
to David Laight, Neil Horman, Vladislav Yasevich, David Miller, linux...@vger.kernel.org, netdev, LKML, Kees Cook, syzkaller
If it is a generic issue, then CONFIG_HARDENED_USERCOPY_PAGESPAN looks
considerably broken as there are tons of copies onto stack. I don't
see what's special in this particular case.
Kees Cook
Jan 17, 2017, 12:19:06 PM1/17/17
to Dmitry Vyukov, David Laight, Neil Horman, Vladislav Yasevich, David Miller, linux...@vger.kernel.org, netdev, LKML, syzkaller, Rik van Riel
is known not to be quite right, that I'll probably just remove it
entirely. It clearly needs much more work before it'll be useful, so
there's no reason to leave it in the kernel to confuse people. :)
-Kees
--
Kees Cook
Nexus Security
Reply all
Reply to author
Forward
0 new messages