Re: general protection fault in inet_unhash

From: Andrii Nakryiko
Date: Fri May 29 2020 - 02:30:13 EST

On 5/28/20 2:27 PM, Eric Dumazet wrote:

On 5/28/20 2:01 PM, Andrii Nakryiko wrote:
On 5/28/20 9:44 AM, syzbot wrote:

syzbot found the following crash on:

HEAD commit:ÂÂÂ dc0f3ed1 net: phy: at803x: add cable diagnostics support f..
git tree:ÂÂÂÂÂÂ net-next
console output:
kernel config:Â
dashboard link:
compiler:ÂÂÂÂÂÂ gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:ÂÂÂÂÂ
C reproducer:ÂÂ

The bug was bisected to:

commit af6eea57437a830293eab56246b6025cc7d46ee7
Author: Andrii Nakryiko <andriin@xxxxxx>
Date:ÂÂ Mon Mar 30 02:59:58 2020 +0000

ÂÂÂÂ bpf: Implement bpf_link-based cgroup BPF program attachment

bisection log:Â
final crash:ÂÂÂ
console output:

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3610d489778b57cc8031@xxxxxxxxxxxxxxxxxxxxxxxxx
Fixes: af6eea57437a ("bpf: Implement bpf_link-based cgroup BPF program attachment")

general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 7063 Comm: syz-executor654 Not tainted 5.7.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:inet_unhash+0x11f/0x770 net/ipv4/inet_hashtables.c:600

No idea why it was bisected to bpf_link change. It seems completely struct sock-related. Seems like

struct inet_hashinfo *hashinfo = sk->sk_prot->h.hashinfo;

ends up being NULL.

Can some more networking-savvy people help with investigating this, please?

Well, the repro definitely uses BPF

It does. Even more so, it uses bpf_link_create for cgroup which was added in my patch. So before it, it just won't be attaching anything. I just suspect that bug can be repro'ed without cgroup bpf_link and existed before. This particular repro, though, will always stop on my commit.

On the following run, my kernel does not have L2TP, so does not crash.

You'd have to use syzbot's kernel config, there is a link to it above.

[pid 817013] bpf(BPF_TASK_FD_QUERY, {task_fd_query={pid=0, fd=-1, flags=0, buf_len=7, buf="cgroup", prog_id=0, fd_type=BPF_FD_TYPE_RAW_TRACEPOINT, probe_offset=0, probe_addr=0}}, 48) = -1 ENOENT (No such file or directory)
[pid 817013] openat(AT_FDCWD, "cgroup", O_RDWR|O_PATH) = 3
[pid 817013] bpf(BPF_PROG_LOAD, {prog_type=BPF_PROG_TYPE_CGROUP_SOCK, insn_cnt=4, insns=0x20000000, license="GPL", log_level=0, log_size=0, log_buf=NULL, kern_version=KERNEL_VERSION(0, 0, 0), prog_flags=0, prog_name="", prog_ifindex=0, expected_attach_type=BPF_CGROUP_INET_INGRESS, prog_btf_fd=-1, func_info_rec_size=8, func_info=NULL, func_info_cnt=0, line_info_rec_size=16, line_info=NULL, line_info_cnt=0, attach_btf_id=0}, 112) = -1 EPERM (Operation not permitted)
[pid 817013] bpf(BPF_LINK_CREATE, {link_create={prog_fd=-1, target_fd=3, attach_type=BPF_CGROUP_INET_SOCK_CREATE, flags=0}}, 16) = -1 EBADF (Bad file descriptor)
[pid 817013] socket(AF_INET, SOCK_DGRAM, IPPROTO_L2TP <unfinished ...>
[pid 816180] <... nanosleep resumed>NULL) = 0
[pid 816180] wait4(-1, 0x7fffa59867cc, WNOHANG|__WALL, NULL) = 0
[pid 816180] nanosleep({tv_sec=0, tv_nsec=1000000}, <unfinished ...>
[pid 817013] <... socket resumed>) = -1 EPROTONOSUPPORT (Protocol not supported)