KASAN: stack-out-of-bounds Read in xfrm_state_find (4)

[syzbot]

Hello,

syzbot hit the following crash on upstream commit
72906f38934a49faf4d2d38ea9ae32adcf7d5d0c (Tue Jan 30 21:04:50 2018 +0000)
Merge branch 'x86-hyperv-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

So far this crash happened 4 times on net-next, upstream.
C reproducer is attached.
syzkaller reproducer is attached.
Raw console output is attached.
compiler: gcc (GCC) 7.1.1 20170620
.config is attached.
user-space arch: i386

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e1a157...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.

audit: type=1400 audit(1517389806.479:7): avc: denied { map } for
pid=4152 comm="syzkaller668857" path="/root/syzkaller668857449" 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
==================================================================
BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30de/0x3210
net/xfrm/xfrm_state.c:1051
Read of size 4 at addr ffff8801b37f7940 by task syzkaller668857/4152

CPU: 1 PID: 4152 Comm: syzkaller668857 Not tainted 4.15.0+ #197
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+0x194/0x257 lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x25b/0x340 mm/kasan/report.c:409
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:429
xfrm_state_find+0x30de/0x3210 net/xfrm/xfrm_state.c:1051
xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:1393 [inline]
xfrm_tmpl_resolve+0x2ee/0xc40 net/xfrm/xfrm_policy.c:1437
xfrm_resolve_and_create_bundle+0x172/0x2760 net/xfrm/xfrm_policy.c:1828
xfrm_lookup+0xfcb/0x25d0 net/xfrm/xfrm_policy.c:2158
xfrm_lookup_route+0x39/0x1a0 net/xfrm/xfrm_policy.c:2278
ip_route_output_flow+0x7c/0xa0 net/ipv4/route.c:2559
raw_sendmsg+0xcf2/0x3cf0 net/ipv4/raw.c:640
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
sock_sendmsg_nosec net/socket.c:638 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:648
SYSC_sendto+0x361/0x5c0 net/socket.c:1729
SyS_sendto+0x40/0x50 net/socket.c:1697
do_syscall_32_irqs_on arch/x86/entry/common.c:327 [inline]
do_fast_syscall_32+0x3ee/0xf9d arch/x86/entry/common.c:389
entry_SYSENTER_compat+0x54/0x63 arch/x86/entry/entry_64_compat.S:129
RIP: 0023:0xf7fecc79
RSP: 002b:00000000ffadc46c EFLAGS: 00000286 ORIG_RAX: 0000000000000171
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000020098000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000020cf9000
RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000

The buggy address belongs to the page:
page:ffffea0006cdfdc0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x2fffc0000000000()
raw: 02fffc0000000000 0000000000000000 0000000000000000 00000000ffffffff
raw: 0000000000000000 0000000100000001 0000000000000000 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff8801b37f7800: f2 f2 f2 f2 f2 00 00 00 f2 f2 f2 f2 f2 00 00 00
ffff8801b37f7880: 00 f2 f2 f2 f2 00 00 00 00 00 00 f2 f2 f2 f2 f2
> ffff8801b37f7900: f2 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 00 00 00
^
ffff8801b37f7980: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00
ffff8801b37f7a00: 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f3
==================================================================


---
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.

syzbot will keep track of this bug report.
If you forgot to add the Reported-by tag, once the fix for this bug is
merged
into any tree, please reply to this email with:
#syz fix: exact-commit-title
If you want to test a patch for this bug, please reply with:
#syz test: git://repo/address.git branch
and provide the patch inline or as an attachment.
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.

[Steffen Klassert]

On Wed, Jan 31, 2018 at 07:58:01AM -0800, syzbot wrote:
> Hello,
>
> syzbot hit the following crash on upstream commit
> 72906f38934a49faf4d2d38ea9ae32adcf7d5d0c (Tue Jan 30 21:04:50 2018 +0000)
> Merge branch 'x86-hyperv-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>
> So far this crash happened 4 times on net-next, upstream.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> user-space arch: i386

Looks like we forgot to refuse to insert socket policies
when userspace is 32 bit and kernel is 64 bit. We do this
already for policies inserted with netlink because we don't
have a compat layer for xfrm. This means that userspace
and kernel structues don't match, leading to broken
configurations.

I don't have 32 bit userspace on 64 bit machines, so I
can't test this myself. Can you please test this patch:

Subject: [PATCH RFC] xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems

We don't have compat layer for xfrm, so userspace and kernel
structures have different sizes in this case. This results in
a broken confuguration, so refuse to configure socket policies
when trying to insert from 32 bit userspace as we do it already
with policies inserted via netlink.

Signed-off-by: Steffen Klassert <steffen....@secunet.com>
---
net/xfrm/xfrm_state.c | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index a3785f538018..25861a4ef872 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2056,6 +2056,11 @@ int xfrm_user_policy(struct sock *sk, int optname, u8 __user *optval, int optlen
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;

+#ifdef CONFIG_COMPAT
+ if (in_compat_syscall())
+ return -EOPNOTSUPP;
+#endif
+
if (optlen <= 0 || optlen > PAGE_SIZE)
return -EMSGSIZE;

--
2.14.1

[Dmitry Vyukov]

On Thu, Feb 1, 2018 at 9:34 AM, Steffen Klassert
<steffen....@secunet.com> wrote:
> On Wed, Jan 31, 2018 at 07:58:01AM -0800, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on upstream commit
>> 72906f38934a49faf4d2d38ea9ae32adcf7d5d0c (Tue Jan 30 21:04:50 2018 +0000)
>> Merge branch 'x86-hyperv-for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
>>
>> So far this crash happened 4 times on net-next, upstream.
>> C reproducer is attached.
>> syzkaller reproducer is attached.
>> Raw console output is attached.
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached.
>> user-space arch: i386
>
> Looks like we forgot to refuse to insert socket policies
> when userspace is 32 bit and kernel is 64 bit. We do this
> already for policies inserted with netlink because we don't
> have a compat layer for xfrm. This means that userspace
> and kernel structues don't match, leading to broken
> configurations.
>
> I don't have 32 bit userspace on 64 bit machines, so I
> can't test this myself. Can you please test this patch:

Hi Steffen,

Please see the email footer:

> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.

> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bug...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20180201083418.rfarzrodccdy54xx%40gauss3.secunet.de.
> For more options, visit https://groups.google.com/d/optout.

[Dmitry Vyukov]

And please add the Reported-by tag as syzbot asked:
Reported-by: syzbot+e1a157...@syzkaller.appspotmail.com
This is really important for overall process. In particular, syzbot
will never report bugs in xfrm_state_find again as it will think that
it's still the old bug not fixed. This is 4-th out-of-bounds in
xfrm_state_find, so you can see this is important. I guess syzbot
actually found this more than a month ago, but did not report, because
nobody told it that the previous one is fixed. It reported it now
because Eric updated the old bug with the fix yesterday.

[Steffen Klassert]

On Thu, Feb 01, 2018 at 11:30:00AM +0100, Dmitry Vyukov wrote:
> On Thu, Feb 1, 2018 at 9:34 AM, Steffen Klassert
>

> Hi Steffen,
>
> Please see the email footer:
>
> > If you want to test a patch for this bug, please reply with:
> > #syz test: git://repo/address.git branch
> > and provide the patch inline or as an attachment.

Thanks for the hint, I've overlooked this. This is very usefull
for the case that I can not reproduce the bug, but I think I know
how to fix it.

There are two more cases that come to my mind where syzbot could
help.

1. I can not reproduce the bug and I don't know how to fix it,
but some debug output would be helpfull:

syz test-debug-patch-and-send-dmesg-output: git://repo/address.git branch

2. I can not reproduce the bug and I have absolutely no idea what it
could be:

syz bisect: git://repo/address.git branch commit a commit b

I don't know if this is possible, but it would bring the bugfixing
process a bit coser to the case where a real user does a bug report.


#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master

Subject: [PATCH RFC] xfrm: Refuse to insert 32 bit userspace socket policies on 64 bit systems

We don't have compat layer for xfrm, so userspace and kernel
structures have different sizes in this case. This results in
a broken confuguration, so refuse to configure socket policies
when trying to insert from 32 bit userspace as we do it already
with policies inserted via netlink.

Reported-by: syzbot+e1a157...@syzkaller.appspotmail.com

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger
crash:

Reported-and-tested-by:
syzbot+e1a157...@syzkaller.appspotmail.com

Note: the tag will also help syzbot to understand when the bug is fixed.

Tested on upstream commit
4bf772b14675411a69b3c807f73006de0fe4b649 (Fri Feb 2 01:48:47 2018 +0000)
Merge tag 'drm-for-v4.16' of git://people.freedesktop.org/~airlied/linux

compiler: gcc (GCC) 7.1.1 20170620

Patch is attached.
Kernel config is attached.


---
There is no WARRANTY for the result, to the extent permitted by applicable
law.
Except when otherwise stated in writing syzbot provides the result "AS IS"
without warranty of any kind, either expressed or implied, but not limited
to,
the implied warranties of merchantability and fittness for a particular
purpose.
The entire risk as to the quality of the result is with you. Should the
result
prove defective, you assume the cost of all necessary servicing, repair or
correction.

[syzbot]

[Dmitry Vyukov]

On Fri, Feb 2, 2018 at 8:22 AM, Steffen Klassert
<steffen....@secunet.com> wrote:
> On Thu, Feb 01, 2018 at 11:30:00AM +0100, Dmitry Vyukov wrote:
>> On Thu, Feb 1, 2018 at 9:34 AM, Steffen Klassert
>>
>> Hi Steffen,
>>
>> Please see the email footer:
>>
>> > If you want to test a patch for this bug, please reply with:
>> > #syz test: git://repo/address.git branch
>> > and provide the patch inline or as an attachment.
>
> Thanks for the hint, I've overlooked this. This is very usefull
> for the case that I can not reproduce the bug, but I think I know
> how to fix it.
>
> There are two more cases that come to my mind where syzbot could
> help.
>
> 1. I can not reproduce the bug and I don't know how to fix it,
> but some debug output would be helpfull:
>
> syz test-debug-patch-and-send-dmesg-output: git://repo/address.git branch

This is supported by "syz test", see:
https://github.com/google/syzkaller/blob/master/docs/syzbot.md#communication-with-syzbot

> 2. I can not reproduce the bug and I have absolutely no idea what it
> could be:
>
> syz bisect: git://repo/address.git branch commit a commit b
>
> I don't know if this is possible, but it would bring the bugfixing
> process a bit coser to the case where a real user does a bug report.

This is on my plate:
https://github.com/google/syzkaller/issues/501
I think we probably will do bisection always without user request, and
then just post an additional email with results.