net: GPF in netlink_getsockbyportid

[Dmitry Vyukov]

Hello,

The following program causes GPF in netlink_getsockbyportid:

// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include <pthread.h>
#include <stdint.h>
#include <string.h>
#include <sys/syscall.h>
#include <unistd.h>

int main()
{
syscall(SYS_mmap, 0x20000000ul, 0xe65000ul, 0x3ul, 0x32ul,
0xfffffffffffffffful, 0x0ul);
int fd = syscall(SYS_socket, 0x10ul, 0x803ul, 0xcul, 0, 0, 0);
*(uint32_t*)0x20e64000 = (uint32_t)0x28;
*(uint32_t*)0x20e64004 = (uint32_t)0x10;
*(uint64_t*)0x20e64008 = (uint64_t)0x0;
*(uint64_t*)0x20e64010 = (uint64_t)0x3;
*(uint64_t*)0x20e64018 = (uint64_t)0xfff;
*(uint16_t*)0x20e64020 = (uint16_t)0x5;
syscall(SYS_write, fd, 0x20e64000ul, 0x28ul, 0, 0, 0);
return 0;
}


kasan: GPF could be caused by NULL-ptr deref or user memory
accessgeneral protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
Modules linked in:
CPU: 1 PID: 7519 Comm: syz-executor Not tainted 4.4.0+ #276
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff8800625e17c0 ti: ffff880062b50000 task.ti: ffff880062b50000
RIP: 0010:[<ffffffff8536b150>] [<ffffffff8536b150>]
netlink_getsockbyportid+0x30/0x1b0
RSP: 0018:ffff880062b57818 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000002 RCX: 0000000000000002
RDX: 0000000000000048 RSI: 0000000000000002 RDI: 0000000000000240
RBP: ffff880062b57838 R08: 00000000024000c0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 00000000024000c0 R14: 0000000000000000 R15: 0000000000000002
FS: 00007fe4328d7700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007fff7c3ecd80 CR3: 000000003b0b3000 CR4: 00000000000006e0
Stack:
ffff880062b578d0 0000000000000000 000000000000003c 00000000024000c0
ffff880062b578b8 ffffffff8536b300 00000000000000e0 ffffffff8175fe26
ffff8800625e1fe0 7379736275732d6b 000000000000302d ffffffff8764d868
Call Trace:
[<ffffffff8536b300>] __netlink_alloc_skb+0x30/0x790
net/netlink/af_netlink.c:1890
[< inline >] netlink_alloc_skb include/linux/netlink.h:79
[<ffffffff853761a3>] netlink_ack+0x153/0x520 net/netlink/af_netlink.c:2968
[< inline >] nfnetlink_rcv_batch net/netfilter/nfnetlink.c:321
[<ffffffff8538425d>] nfnetlink_rcv+0xbad/0x10a0 net/netfilter/nfnetlink.c:477
[< inline >] netlink_unicast_kernel net/netlink/af_netlink.c:1834
[<ffffffff8537466a>] netlink_unicast+0x47a/0x700 net/netlink/af_netlink.c:1860
[<ffffffff85375976>] netlink_sendmsg+0x1086/0x1760
net/netlink/af_netlink.c:2511
[< inline >] sock_sendmsg_nosec net/socket.c:611
[<ffffffff851cc94a>] sock_sendmsg+0xca/0x110 net/socket.c:621
[<ffffffff851ccba6>] sock_write_iter+0x216/0x3a0 net/socket.c:820
[< inline >] new_sync_write fs/read_write.c:517
[<ffffffff817b0512>] __vfs_write+0x302/0x480 fs/read_write.c:530
[<ffffffff817b1db7>] vfs_write+0x167/0x4a0 fs/read_write.c:577
[< inline >] SYSC_write fs/read_write.c:624
[<ffffffff817b50a1>] SyS_write+0x111/0x220 fs/read_write.c:616
[<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
Code: 55 41 54 53 49 89 fc 89 f3 48 83 ec 08 e8 39 b7 20 fc 49 8d bc
24 40 02 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f>
b6 04 02 84 c0 74 08 3c 03 0f 8e 30 01 00 00 49 8d 7c 24 30
RIP [<ffffffff8536b150>] netlink_getsockbyportid+0x30/0x1b0
net/netlink/af_netlink.c:1658
RSP <ffff880062b57818>
---[ end trace f4ac9332ef80a14f ]---

On commit 30f05309bde49295e02e45c7e615f73aa4e0ccc2.

[Florian Westphal]

Dmitry Vyukov <dvy...@google.com> wrote:

[ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ]

> The following program causes GPF in netlink_getsockbyportid:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <pthread.h>
> #include <stdint.h>
> #include <string.h>
> #include <sys/syscall.h>
> #include <unistd.h>
>
> int main()
> {
> syscall(SYS_mmap, 0x20000000ul, 0xe65000ul, 0x3ul, 0x32ul,
> 0xfffffffffffffffful, 0x0ul);
> int fd = syscall(SYS_socket, 0x10ul, 0x803ul, 0xcul, 0, 0, 0);
> *(uint32_t*)0x20e64000 = (uint32_t)0x28;
> *(uint32_t*)0x20e64004 = (uint32_t)0x10;
> *(uint64_t*)0x20e64008 = (uint64_t)0x0;
> *(uint64_t*)0x20e64010 = (uint64_t)0x3;
> *(uint64_t*)0x20e64018 = (uint64_t)0xfff;
> *(uint16_t*)0x20e64020 = (uint16_t)0x5;
> syscall(SYS_write, fd, 0x20e64000ul, 0x28ul, 0, 0, 0);
> return 0;
> }

CONFIG_NETLINK_MMAP and nfnetlink batching strike in unison :-/

root cause is in nfnetlink_rcv_batch():

296 replay:
297 status = 0;
298
299 skb = netlink_skb_clone(oskb, GFP_KERNEL);

The clone op doesn't copy oskb->sk, so we oops in
__netlink_alloc_skb -> netlink_getsockbyportid() when nfnetlink_rcv_batch
tries to send netlink ack.

[Daniel Borkmann]

If indeed oskb is the mmap'ed netlink skb, then it's not even allowed
to call into skb_clone() as it would access skb shared info data that
can be controlled by the user space mmap buffer, iirc, we had that in
the past with nlmon where skb_clone() was accidentally used.

[Florian Westphal]

Daniel Borkmann <dan...@iogearbox.net> wrote:
> On 01/23/2016 08:25 PM, Florian Westphal wrote:
> >Dmitry Vyukov <dvy...@google.com> wrote:
> >
> >[ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ]
> >
> >>The following program causes GPF in netlink_getsockbyportid:

[..]

> >CONFIG_NETLINK_MMAP and nfnetlink batching strike in unison :-/
> >
> >root cause is in nfnetlink_rcv_batch():
> >
> >296 replay:
> >297 status = 0;
> >298
> >299 skb = netlink_skb_clone(oskb, GFP_KERNEL);
> >
> >The clone op doesn't copy oskb->sk, so we oops in
> >__netlink_alloc_skb -> netlink_getsockbyportid() when nfnetlink_rcv_batch
> >tries to send netlink ack.
>
> If indeed oskb is the mmap'ed netlink skb, then it's not even allowed
> to call into skb_clone()

Right, but in this case there is no mmap'd netlink sk involved -- we
crash when we try to look up dst netlink socket to see if there is an
mmap'd ring attached.

[ and that code isn't there with CONFIG_NETLINK_MMAP=n ].

[Herbert Xu]

Let's CC Pablo since he wrote the code in question.

Thanks,
--
Email: Herbert Xu <her...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[Pablo Neira Ayuso]

On Mon, Jan 25, 2016 at 06:03:41PM +0800, Herbert Xu wrote:
> On Sun, Jan 24, 2016 at 01:11:03AM +0100, Florian Westphal wrote:
> > Daniel Borkmann <dan...@iogearbox.net> wrote:
> > > On 01/23/2016 08:25 PM, Florian Westphal wrote:
> > > >Dmitry Vyukov <dvy...@google.com> wrote:
> > > >
> > > >[ CC nf-devel, not sure if its nfnetlink fault or NETLINK_MMAP ]
> > > >
> > > >>The following program causes GPF in netlink_getsockbyportid:
> > [..]
> >
> > > >CONFIG_NETLINK_MMAP and nfnetlink batching strike in unison :-/
> > > >
> > > >root cause is in nfnetlink_rcv_batch():
> > > >
> > > >296 replay:
> > > >297 status = 0;
> > > >298
> > > >299 skb = netlink_skb_clone(oskb, GFP_KERNEL);
> > > >
> > > >The clone op doesn't copy oskb->sk, so we oops in
> > > >__netlink_alloc_skb -> netlink_getsockbyportid() when nfnetlink_rcv_batch
> > > >tries to send netlink ack.
> > >
> > > If indeed oskb is the mmap'ed netlink skb, then it's not even allowed
> > > to call into skb_clone()
> >
> > Right, but in this case there is no mmap'd netlink sk involved -- we
> > crash when we try to look up dst netlink socket to see if there is an
> > mmap'd ring attached.
> >
> > [ and that code isn't there with CONFIG_NETLINK_MMAP=n ].
>
> Let's CC Pablo since he wrote the code in question.

I have just sent this patch:

http://patchwork.ozlabs.org/patch/572489/