[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87msrmdnjh.fsf@toke.dk>
Date: Tue, 27 Feb 2024 14:50:10 +0100
From: Toke Høiland-Jørgensen <toke@...nel.org>
To: John Fastabend <john.fastabend@...il.com>, syzbot
<syzbot+8cd36f6b65f3cafd400a@...kaller.appspotmail.com>,
andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
daniel@...earbox.net, davem@...emloft.net, haoluo@...gle.com,
hawk@...nel.org, john.fastabend@...il.com, jolsa@...nel.org,
kpsingh@...nel.org, kuba@...nel.org, linux-kernel@...r.kernel.org,
martin.lau@...ux.dev, netdev@...r.kernel.org, sdf@...gle.com,
song@...nel.org, syzkaller-bugs@...glegroups.com, yonghong.song@...ux.dev
Subject: Re: [syzbot] [bpf?] [net?] BUG: unable to handle kernel NULL
pointer dereference in dev_map_hash_update_elem
John Fastabend <john.fastabend@...il.com> writes:
> syzbot wrote:
>> syzbot has found a reproducer for the following issue on:
>>
>> HEAD commit: 70ff1fe626a1 Merge tag 'docs-6.8-fixes3' of git://git.lwn...
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1762045c180000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=4cf52b43f46d820d
>> dashboard link: https://syzkaller.appspot.com/bug?extid=8cd36f6b65f3cafd400a
>> compiler: arm-linux-gnueabi-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
>> userspace arch: arm
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=110cf122180000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=142f6d8c180000
>>
>> Downloadable assets:
>> disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/8ead8862021c/non_bootable_disk-70ff1fe6.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/bc398db9fd8c/vmlinux-70ff1fe6.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/6d3f8b72a671/zImage-70ff1fe6.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+8cd36f6b65f3cafd400a@...kaller.appspotmail.com
>>
>
> I'll take a look this week if no one beats me to it. Looks like there is
> a reproducer so should be able to sort it out.
Took a look at the reproducer. Looks like it's creating the map with
max_entries=0x80000202, which means the rounding up of the number of
hash buckets overflows, and somehow the overflow check (for 0) is not
working on a 32-bit machine? I guess because the roundup_power_of_two()
ends up doing a (1UL << 32), which is undefined behaviour when an
unsigned long is four bytes.
I'll send a patch to check the value before the rounding up instead of
after.
-Toke
Powered by blists - more mailing lists