linux-kernel - Re: [PATCH] bpf: Fix out-of-bounds write in trie_get_next

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]

Message-ID: <Zxil/uyqq5qDHuRX@localhost.localdomain>
Date: Wed, 23 Oct 2024 16:30:06 +0900
From: Byeonguk Jeong <jungbu2855@...il.com>
To: Hou Tao <houtao@...weicloud.com>
Cc: Daniel Borkmann <daniel@...earbox.net>,
	Yonghong Song <yonghong.song@...ux.dev>, bpf@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] bpf: Fix out-of-bounds write in trie_get_next_key()

On Wed, Oct 23, 2024 at 10:03:44AM +0800, Hou Tao wrote:
>
> Without the fix, there will be KASAN report as show below when dumping
> all keys in the lpm-trie through bpf_map_get_next_key().

Thank you for testing.

> 
> However, I have a dumb question: does it make sense to reject the
> element with prefixlen = 0 ? Because I can't think of a use case where a
> zero-length prefix will be useful.

With prefixlen = 0, it would always return -ENOENT, I think. Maybe it is
good to reject it earlier!