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

[syzbot]

Hello,

syzkaller hit the following crash on
1deab8ce2c91e3b16563b7a7ea150f82334262ec
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-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.


==================================================================
BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230
net/xfrm/xfrm_state.c:1051
Read of size 4 at addr ffff8801c06b7af8 by task syz-executor4/24212

CPU: 0 PID: 24212 Comm: syz-executor4 Not tainted 4.14.0+ #126
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
IPv6: ADDRCONF(NETDEV_UP): sit0: link is not ready
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+0x30fc/0x3230 net/xfrm/xfrm_state.c:1051
xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:1388 [inline]
xfrm_tmpl_resolve+0x2fb/0xbd0 net/xfrm/xfrm_policy.c:1432
xfrm_resolve_and_create_bundle+0x11b/0x2600 net/xfrm/xfrm_policy.c:1821
xfrm_lookup+0x1574/0x23f0 net/xfrm/xfrm_policy.c:2146
SELinux: unrecognized netlink message: protocol=0 nlmsg_type=7
sclass=netlink_route_socket pig=24256 comm=syz-executor6
SELinux: unrecognized netlink message: protocol=0 nlmsg_type=0
sclass=netlink_route_socket pig=24256 comm=syz-executor6
SELinux: unrecognized netlink message: protocol=0 nlmsg_type=7
sclass=netlink_route_socket pig=24257 comm=syz-executor6
SELinux: unrecognized netlink message: protocol=0 nlmsg_type=0
sclass=netlink_route_socket pig=24256 comm=syz-executor6
xfrm_lookup_route+0x39/0x1a0 net/xfrm/xfrm_policy.c:2264
ip_route_output_flow+0x7c/0xa0 net/ipv4/route.c:2559
raw_sendmsg+0xc4f/0x3920 net/ipv4/raw.c:633
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
sock_sendmsg_nosec net/socket.c:632 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:642
SYSC_sendto+0x358/0x5a0 net/socket.c:1749
SyS_sendto+0x40/0x50 net/socket.c:1717
entry_SYSCALL_64_fastpath+0x1f/0x96
RIP: 0033:0x452879
RSP: 002b:00007f4737804be8 EFLAGS: 00000212 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00000000007580d8 RCX: 0000000000452879
RDX: 0000000000000000 RSI: 0000000020098000 RDI: 0000000000000015
RBP: 0000000000000086 R08: 0000000020c24000 R09: 0000000000000010
R10: fffffffffffffffe R11: 0000000000000212 R12: 00000000006ed3b8
R13: 00000000ffffffff R14: 00007f47378056d4 R15: 000000000000000c

The buggy address belongs to the page:
page:ffffea000701adc0 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:
ffff8801c06b7980: f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2 00 00 00 f2
ffff8801c06b7a00: f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00
> ffff8801c06b7a80: 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 f2
^
ffff8801c06b7b00: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 f2 f2 f2
ffff8801c06b7b80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 f1 f1
==================================================================


---
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 committed, please 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.

[syzbot]

syzkaller has found reproducer for the following crash on
0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c

git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-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

BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230
net/xfrm/xfrm_state.c:1051

Read of size 4 at addr ffff8801ccaa7af8 by task syzkaller231684/3045

CPU: 0 PID: 3045 Comm: syzkaller231684 Not tainted 4.14.0+ #128

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+0x30fc/0x3230 net/xfrm/xfrm_state.c:1051
xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:1388 [inline]
xfrm_tmpl_resolve+0x2fb/0xbd0 net/xfrm/xfrm_policy.c:1432
xfrm_resolve_and_create_bundle+0x11b/0x2600 net/xfrm/xfrm_policy.c:1821
xfrm_lookup+0x1574/0x23f0 net/xfrm/xfrm_policy.c:2146

xfrm_lookup_route+0x39/0x1a0 net/xfrm/xfrm_policy.c:2264
ip_route_output_flow+0x7c/0xa0 net/ipv4/route.c:2559
raw_sendmsg+0xc4f/0x3920 net/ipv4/raw.c:633
inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763
sock_sendmsg_nosec net/socket.c:632 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:642
SYSC_sendto+0x358/0x5a0 net/socket.c:1749
SyS_sendto+0x40/0x50 net/socket.c:1717
entry_SYSCALL_64_fastpath+0x1f/0x96

RIP: 0033:0x43ff09
RSP: 002b:00007fffb0363278 EFLAGS: 00000217 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043ff09
RDX: 0000000000000000 RSI: 0000000020098000 RDI: 0000000000000003

RBP: 0000000000000086 R08: 0000000020c24000 R09: 0000000000000010

R10: fffffffffffffffe R11: 0000000000000217 R12: 0000000000401870
R13: 0000000000401900 R14: 0000000000000000 R15: 0000000000000000

The buggy address belongs to the page:

page:ffffea000732a9c0 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:

ffff8801ccaa7980: f2 f2 f2 f2 00 f2 f2 f2 f2 f2 f2 f2 00 00 00 f2
ffff8801ccaa7a00: f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00
> ffff8801ccaa7a80: 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 f2
^
ffff8801ccaa7b00: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 f2 f2 f2
ffff8801ccaa7b80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 f1 f1
==================================================================

[Steffen Klassert]

On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
> syzkaller has found reproducer for the following crash on
> 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-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
>
>
> BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230
> net/xfrm/xfrm_state.c:1051
> Read of size 4 at addr ffff8801ccaa7af8 by task syzkaller231684/3045

The patch below should fix this. I plan to apply it to the ipsec tree
after some advanced testing.

Subject: [PATCH RFC] xfrm: Fix stack-out-of-bounds with misconfigured transport
mode policies.

On policies with a transport mode template, we pass the addresses
from the flowi to xfrm_state_find(), assuming that the IP addresses
(and address family) don't change during transformation.

Unfortunately our policy template validation is not strict enough.
It is possible to configure policies with transport mode template
where the address family of the template does not match the selectors
address family. This lead to stack-out-of-bound reads because
we compare arddesses of the wrong family. Fix this by refusing
such a configuration, address family can not change on transport
mode.

We use the assumption that, on transport mode, the first templates
address family must match the address family of the policy selector.
Subsequent transport mode templates must mach the address family of
the previous template.

Reported-by: syzbot <syzk...@googlegroups.com>
Signed-off-by: Steffen Klassert <steffen....@secunet.com>
---
net/xfrm/xfrm_user.c | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 983b0233767b..57ad016ae675 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -1419,11 +1419,14 @@ static void copy_templates(struct xfrm_policy *xp, struct xfrm_user_tmpl *ut,

static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
{
+ u16 prev_family;
int i;

if (nr > XFRM_MAX_DEPTH)
return -EINVAL;

+ prev_family = family;
+
for (i = 0; i < nr; i++) {
/* We never validated the ut->family value, so many
* applications simply leave it at zero. The check was
@@ -1435,6 +1438,12 @@ static int validate_tmpl(int nr, struct xfrm_user_tmpl *ut, u16 family)
if (!ut[i].family)
ut[i].family = family;

+ if ((ut[i].mode == XFRM_MODE_TRANSPORT) &&
+ (ut[i].family != prev_family))
+ return -EINVAL;
+
+ prev_family = ut[i].family;
+
switch (ut[i].family) {
case AF_INET:
break;
--
2.14.1

[Dmitry Vyukov]

On Fri, Dec 1, 2017 at 8:27 AM, Steffen Klassert
<steffen....@secunet.com> wrote:
> On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
>> syzkaller has found reproducer for the following crash on
>> 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c
>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-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
>>
>>
>> BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230
>> net/xfrm/xfrm_state.c:1051
>> Read of size 4 at addr ffff8801ccaa7af8 by task syzkaller231684/3045
>
> The patch below should fix this. I plan to apply it to the ipsec tree
> after some advanced testing.

Please also follow this part:

> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title

> Note: all commands must start from beginning of the line in the email body.

This will greatly help keep the process running.

Thanks

> --
> 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/20171201072743.47ztbmrql7ub327u%40gauss3.secunet.de.
> For more options, visit https://groups.google.com/d/optout.

[Eric Biggers]

Hi Steffen,

On Fri, Dec 01, 2017 at 08:27:43AM +0100, Steffen Klassert wrote:
> On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
> > syzkaller has found reproducer for the following crash on
> > 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-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
> >
> >
> > BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x30fc/0x3230
> > net/xfrm/xfrm_state.c:1051
> > Read of size 4 at addr ffff8801ccaa7af8 by task syzkaller231684/3045
>
> The patch below should fix this. I plan to apply it to the ipsec tree
> after some advanced testing.
>
> Subject: [PATCH RFC] xfrm: Fix stack-out-of-bounds with misconfigured transport
> mode policies.
>

Are you still planning to apply this? syzbot is still hitting this bug.

Eric

[Steffen Klassert]

It is already applied to the ipsec tree, will go upstream by the end of
this week.

[Eric Biggers]

Marking this fixed for syzbot:

#syz fix: xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.