net: GPF in rt6_nexthop_info

[Dmitry Vyukov]

Hello,

The following program triggers GPF in rt6_nexthop_info

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <sys/types.h>
#include <sys/socket.h>
#include <linux/sched.h>
#include <unistd.h>
#include <sched.h>

int main()
{
unshare(CLONE_NEWNET);
int fd = socket(PF_NETLINK, SOCK_DGRAM|SOCK_NONBLOCK, 0);
const char* data ="\x22\x00\x00\x00\x1a\x00\x07\x00\x08\x09\x00\x0f"
"\x09\x00\x07\x00\x0a\xff\xfc\x03\x1b\x00\xa8\xc6"
"\x19\xf3\xff\xff\x05\x00\x10\x00\xbe\x45";
write(fd, data, 34);
return 0;
}

general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 2 PID: 2965 Comm: a.out Not tainted 4.10.0+ #229
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff8800650fc100 task.stack: ffff880065378000
RIP: 0010:rt6_nexthop_info+0x278/0x3b0 net/ipv6/route.c:3325
RSP: 0018:ffff88006537f350 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: ffff88006865da00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 000000000000004a RDI: 0000000000000254
RBP: ffff88006537f3f0 R08: ffffed000cc55820 R09: ffffed000cc55820
R10: 0000000000000001 R11: ffffed000cc5581f R12: 1ffff1000ca6fe6d
R13: ffff8800662ac0d8 R14: ffff88006537f3c8 R15: dffffc0000000000
FS: 0000000000c39880(0000) GS:ffff88006d100000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004b20e0 CR3: 000000006cdb7000 CR4: 00000000001406e0
Call Trace:
rt6_fill_node.isra.61+0xea4/0x1780 net/ipv6/route.c:3513
inet6_rtm_getroute+0x7da/0xce0 net/ipv6/route.c:3639
rtnetlink_rcv_msg+0x609/0x860 net/core/rtnetlink.c:4104
netlink_rcv_skb+0x2ab/0x390 net/netlink/af_netlink.c:2298
rtnetlink_rcv+0x2a/0x40 net/core/rtnetlink.c:4110
netlink_unicast_kernel net/netlink/af_netlink.c:1231 [inline]
netlink_unicast+0x514/0x730 net/netlink/af_netlink.c:1257
netlink_sendmsg+0xa9f/0xe50 net/netlink/af_netlink.c:1803
sock_sendmsg_nosec net/socket.c:633 [inline]
sock_sendmsg+0xca/0x110 net/socket.c:643
sock_write_iter+0x326/0x600 net/socket.c:846
new_sync_write fs/read_write.c:499 [inline]
__vfs_write+0x483/0x740 fs/read_write.c:512
vfs_write+0x187/0x530 fs/read_write.c:560
SYSC_write fs/read_write.c:607 [inline]
SyS_write+0xfb/0x230 fs/read_write.c:599
entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x433ef0
RSP: 002b:00007ffcea6171b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 0000000000401730 RCX: 0000000000433ef0
RDX: 0000000000000022 RSI: 0000000000493548 RDI: 0000000000000003
RBP: 0000000000000000 R08: 000000000000000b R09: 0000000000000004
R10: 000000000000000d R11: 0000000000000246 R12: 00000000004002b0
R13: 00007ffcea6172c8 R14: 0000000000000002 R15: 0000000000000000
Code: ff df 80 3c 01 00 0f 85 3c 01 00 00 48 8b 8b 58 01 00 00 48 b8
00 00 00 00 00 fc ff df 48 8d b9 54 02 00 00 48 89 fe 48 c1 ee 03 <0f>
b6 34 06 48 89 f8 83 e0 07 83 c0 03 40 38 f0 7c 05 40 84 f6
RIP: rt6_nexthop_info+0x278/0x3b0 net/ipv6/route.c:3325 RSP: ffff88006537f350
---[ end trace 6a59074c79adfb5f ]---

On commit e5d56efc97f8240d0b5d66c03949382b6d7e5570

[Eric Dumazet]

Not sure how you chose all these addresses on CC, while you forgot David
Ahern. I doubt Yuchung is interested in fixing IPv6 bugs.

David, rt->rt6i_idev can be NULL.

a1a22c12060e4b9c52f45d4b3460f614e00162a2 ("net: ipv6: Keep nexthop of
multipath route on admin down") added one bug in fib6_ifdown()

And beb1afac518dec5a15dc92ba8f0ca016dcf457b4 ("net: ipv6: Add support to
dump multipath routes via RTA_MULTIPATH attribute") added one bug in
rt6_nexthop_info()

[Dmitry Vyukov]

I always run get_maintainer.pl on the top file. David is not listed
for net/ipv6/route.c.
I've added Yuchung as you said you want to partition load.

[Eric Dumazet]

On Tue, 2017-02-28 at 14:30 +0100, Dmitry Vyukov wrote:

> I always run get_maintainer.pl on the top file. David is not listed
> for net/ipv6/route.c.
> I've added Yuchung as you said you want to partition load.

Yuchung is working on TCP stack exclusively, as far as linux kernel is
concerned.

He never submitted a single patch targeting IPv6, if this was not for a
TCP change.

net...@vger.kernel.org is the appropriate point of contact for bugs in
linux network stacks.

Thanks.

[Cong Wang]

Probably we need to skip null entry again here:

diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index f54f426..25590d1 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -3627,6 +3627,12 @@ static int inet6_rtm_getroute(struct sk_buff
*in_skb, struct nlmsghdr *nlh)
rt = (struct rt6_info *)ip6_route_output(net, NULL, &fl6);
}

+ if (rt == net->ipv6.ip6_null_entry) {
+ ip6_rt_put(rt);
+ err = -ENOENT;
+ goto errout;
+ }
+
skb = alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL);
if (!skb) {
ip6_rt_put(rt);

[David Ahern]

On 2/28/17 5:10 AM, Eric Dumazet wrote:
> David, rt->rt6i_idev can be NULL.

Do you know of an example where rt6i_idev can be NULL - besides the
null_entry rt which is null only because of init order?

[Eric Dumazet]

I might have been mistaken, but many points in net/ipv6/route.c test
rt->rt6i_idev being NULL or not before dereferencing it.

Maybe other rts (other than null_entry) share this property.

[David Ahern]

Seen those and always been confused that an L3 route object does not
require the L3 addr struct for the device.

Code wise the struct is allocated for all net devices at registration as
long as mtu >= 1280. If it is not allocated, routes referencing the
device fail with ENODEV (idev check in ip6_route_info_create). Putting
that together I can't see how a standard ipv6 rt other than the
null_entry can reference a null rt6i_idev.