netdev - Re: [PATCH] bpf: check size before calling kvmalloc

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Dec 2021 23:45:53 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     George Kennedy <george.kennedy@...cle.com>, sdf@...gle.com,
        ast@...nel.org
Cc:     netdev@...r.kernel.org, bpf@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bpf: check size before calling kvmalloc

On 12/17/21 7:48 PM, George Kennedy wrote:
> ZERO_SIZE_PTR ((void *)16) is returned by kvmalloc() instead of NULL
> if size is zero. Currently, return values from kvmalloc() are only
> checked for NULL. Before calling kvmalloc() check for size of zero
> and return error if size is zero to avoid the following crash.
> 
> BUG: kernel NULL pointer dereference, address: 0000000000000000
> PGD 1030bd067 P4D 1030bd067 PUD 103497067 PMD 0
> Oops: 0010 [#1] PREEMPT SMP KASAN NOPTI
> CPU: 1 PID: 15094 Comm: syz-executor344 Not tainted 5.16.0-rc1-syzk #1
> Hardware name: Red Hat KVM, BIOS
> RIP: 0010:0x0
> Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
> RSP: 0018:ffff888017627b78 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8880215d0780 RCX: ffffffff81b63c60
> RDX: 0000000000000010 RSI: 0000000000000000 RDI: ffff8881035db400
> RBP: ffff888017627f08 R08: ffffed1003697209 R09: ffffed1003697209
> R10: ffff88801b4b9043 R11: ffffed1003697208 R12: ffffffff8f15d580
> R13: 1ffff11002ec4f77 R14: ffff8881035db400 R15: 0000000000000000
> FS:  00007f62bca78740(0000) GS:ffff888107880000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffffffffffffd6 CR3: 000000002282a000 CR4: 00000000000006e0
> Call Trace:
>   <TASK>
>   map_get_next_key kernel/bpf/syscall.c:1279 [inline]
>   __sys_bpf+0x384d/0x5b30 kernel/bpf/syscall.c:4612
>   __do_sys_bpf kernel/bpf/syscall.c:4722 [inline]
>   __se_sys_bpf kernel/bpf/syscall.c:4720 [inline]
>   __x64_sys_bpf+0x7a/0xc0 kernel/bpf/syscall.c:4720
>   do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>   do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80
>   entry_SYSCALL_64_after_hwframe+0x44/0xae
> 
> Reported-by: syzkaller <syzkaller@...glegroups.com>
> Signed-off-by: George Kennedy <george.kennedy@...cle.com>

Could you provide some more details, e.g. which map type is this where we
have to assume zero-sized keys everywhere?

(Or link to syzkaller report could also work alternatively if public.)

Thanks,
Daniel