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

7 messages, 4 authors, 2018-01-30 · open the first message on its own page

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

From: syzbot <hidden>
Date: 2017-11-20 17:22:03 

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 syzkaller@googlegroups.com.
Please credit me with: Reported-by: syzbot [off-list ref]

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.

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

From: syzbot <hidden>
Date: 2017-11-22 16:05:03 

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

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

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: 2017-12-01 07:27:47 

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 <redacted>
Signed-off-by: Steffen Klassert <steffen.klassert@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

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

From: Dmitry Vyukov <dvyukov@google.com>
Date: 2017-12-01 08:15:34 

On Fri, Dec 1, 2017 at 8:27 AM, Steffen Klassert
[off-list ref] wrote:
On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
quoted
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
quoted hunk
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 <redacted>
Signed-off-by: Steffen Klassert <steffen.klassert@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

--
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-bugs+unsubscribe@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.

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

From: Eric Biggers <hidden>
Date: 2017-12-12 21:00:39 

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:
quoted
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

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

From: Steffen Klassert <steffen.klassert@secunet.com>
Date: 2017-12-13 05:18:15 

On Tue, Dec 12, 2017 at 01:00:31PM -0800, Eric Biggers wrote:
Hi Steffen,

On Fri, Dec 01, 2017 at 08:27:43AM +0100, Steffen Klassert wrote:
quoted
On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
quoted
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.
It is already applied to the ipsec tree, will go upstream by the end of
this week.

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

From: Eric Biggers <hidden>
Date: 2018-01-30 21:28:14 

On Wed, Dec 13, 2017 at 06:18:05AM +0100, Steffen Klassert wrote:
On Tue, Dec 12, 2017 at 01:00:31PM -0800, Eric Biggers wrote:
quoted
Hi Steffen,

On Fri, Dec 01, 2017 at 08:27:43AM +0100, Steffen Klassert wrote:
quoted
On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote:
quoted
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.
It is already applied to the ipsec tree, will go upstream by the end of
this week.
Marking this fixed for syzbot:

#syz fix: xfrm: Fix stack-out-of-bounds with misconfigured transport mode policies.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help