netdev - Re: [PATCH net] ipv4: check for NULL idev in ip_route_use

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed, 24 Apr 2024 13:46:07 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Eric Dumazet <edumazet@...gle.com>, "David S . Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org, 
	eric.dumazet@...il.com, syzbot <syzkaller@...glegroups.com>
Subject: Re: [PATCH net] ipv4: check for NULL idev in ip_route_use_hint()

On Tue, 23 Apr 2024 at 15:57, Paolo Abeni <pabeni@...hat.com> wrote:
>
> On Sun, 2024-04-21 at 18:43 +0000, Eric Dumazet wrote:
> > syzbot was able to trigger a NULL deref in fib_validate_source()
> > in an old tree [1].
> >
> > It appears the bug exists in latest trees.
> >
> > All calls to __in_dev_get_rcu() must be checked for a NULL result.
> >
> > [1]
> > general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN
> > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> > CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
> >  RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425
> > Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf
> > RSP: 0018:ffffc900015fee40 EFLAGS: 00010246
> > RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0
> > RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0
> > RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000
> > R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000
> > R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000
> > FS:  00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000
> > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0
> > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> > Call Trace:
> >   ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231
> >   ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327
> >   ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]
> >   ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638
> >   ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673
> >   __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]
> >   __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620
> >   __netif_receive_skb_list net/core/dev.c:5672 [inline]
> >   netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764
> >   netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816
> >   xdp_recv_frames net/bpf/test_run.c:257 [inline]
> >   xdp_test_run_batch net/bpf/test_run.c:335 [inline]
> >   bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363
> >   bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376
> >   bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736
> >   __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115
> >   __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]
> >   __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]
> >   __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199
> >
> > Fixes: 02b24941619f ("ipv4: use dst hint for ipv4 list receive")
> > Reported-by: syzbot <syzkaller@...glegroups.com>
> > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
>
> Thanks for fixing it!
>
> Acked-by: Paolo Abeni <pabeni@...hat.com>
>
> syzbot took surprisingly long to spot this, I guess the race window is
> very tiny? (or syzbot learned new tricks...)

>From the stack it looks like this requires creating a non-trivial
valid BPF program, this may still be challenging for the fuzzer.