Received-SPF: pass (google.com: domain of linux-kernel+bounces-71777-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Subject: Re: [PATCH v2] bpf: Replace bpf_lpm_trie_key 0-length array with
 flexible array
To: Kees Cook <keescook@chromium.org>,
 "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Cc: Alexei Starovoitov <ast@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
 Andrii Nakryiko <andrii@kernel.org>, Martin KaFai Lau
 <martin.lau@linux.dev>, Song Liu <song@kernel.org>,
 Yonghong Song <yhs@fb.com>, John Fastabend <john.fastabend@gmail.com>,
 KP Singh <kpsingh@kernel.org>, Stanislav Fomichev <sdf@google.com>,
 Hao Luo <haoluo@google.com>, Jiri Olsa <jolsa@kernel.org>,
 Mykola Lysenko <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>,
 Haowen Bai <baihaowen@meizu.com>, bpf@vger.kernel.org,
 linux-kselftest@vger.kernel.org, Yonghong Song <yonghong.song@linux.dev>,
 Anton Protopopov <aspsk@isovalent.com>, linux-kernel@vger.kernel.org,
 linux-hardening@vger.kernel.org
References: <20240216235536.it.234-kees@kernel.org>
 <e58d035c-fb74-4d29-94d5-6c22542e7513@embeddedor.com>
 <202402161902.FCFFEC322@keescook>
From: Daniel Borkmann <daniel@iogearbox.net>
Message-ID: <a74a7255-5dbd-060e-fe2f-ac3563f466fb@iogearbox.net>
Date: Mon, 19 Feb 2024 18:48:41 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <202402161902.FCFFEC322@keescook>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit

On 2/17/24 4:03 AM, Kees Cook wrote:
> On Fri, Feb 16, 2024 at 06:27:08PM -0600, Gustavo A. R. Silva wrote:
>> On 2/16/24 17:55, Kees Cook wrote:
>>> Replace deprecated 0-length array in struct bpf_lpm_trie_key with
>>> flexible array. Found with GCC 13:
>>>
>>> ../kernel/bpf/lpm_trie.c:207:51: warning: array subscript i is outside array bounds of 'const __u8[0]' {aka 'const unsigned char[]'} [-Warray-bounds=]
>>>     207 |                                        *(__be16 *)&key->data[i]);
>>>         |                                                   ^~~~~~~~~~~~~
>>> ../include/uapi/linux/swab.h:102:54: note: in definition of macro '__swab16'
>>>     102 | #define __swab16(x) (__u16)__builtin_bswap16((__u16)(x))
>>>         |                                                      ^
>>> ../include/linux/byteorder/generic.h:97:21: note: in expansion of macro '__be16_to_cpu'
>>>      97 | #define be16_to_cpu __be16_to_cpu
>>>         |                     ^~~~~~~~~~~~~
>>> ../kernel/bpf/lpm_trie.c:206:28: note: in expansion of macro 'be16_to_cpu'
>>>     206 |                 u16 diff = be16_to_cpu(*(__be16 *)&node->data[i]
>>> ^
>>>         |                            ^~~~~~~~~~~
>>> In file included from ../include/linux/bpf.h:7:
>>> ../include/uapi/linux/bpf.h:82:17: note: while referencing 'data'
>>>      82 |         __u8    data[0];        /* Arbitrary size */
>>>         |                 ^~~~
>>>
>>> And found at run-time under CONFIG_FORTIFY_SOURCE:
>>>
>>>     UBSAN: array-index-out-of-bounds in kernel/bpf/lpm_trie.c:218:49
>>>     index 0 is out of range for type '__u8 [*]'
>>>
>>> This includes fixing the selftest which was incorrectly using a
>>> variable length struct as a header, identified earlier[1]. Avoid this
>>> by just explicitly including the prefixlen member instead of struct
>>> bpf_lpm_trie_key.
>>>
>>> Note that it is not possible to simply remove the "data" member, as it
>>> is referenced by userspace
>>>
>>> cilium:
>>>           struct egress_gw_policy_key in_key = {
>>>                   .lpm_key = { 32 + 24, {} },
>>>                   .saddr   = CLIENT_IP,
>>>                   .daddr   = EXTERNAL_SVC_IP & 0Xffffff,
>>>           };
>>>
>>> systemd:
>>> 	ipv6_map_fd = bpf_map_new(
>>> 			BPF_MAP_TYPE_LPM_TRIE,
>>> 			offsetof(struct bpf_lpm_trie_key, data) + sizeof(uint32_t)*4,
>>> 			sizeof(uint64_t),
>>> 			...
>>>
>>> The only risk to UAPI would be if sizeof() were used directly on the
>>> data member, which it does not seem to be. It is only used as a static
>>> initializer destination and to find its location via offsetof().
>>>
>>> Link: https://lore.kernel.org/all/202206281009.4332AA33@keescook/ [1]
>>> Reported-by: Mark Rutland <mark.rutland@arm.com>
>>> Closes: https://paste.debian.net/hidden/ca500597/
>>
>> mmh... this URL expires: 2024-05-15
> 
> Yup, but that's why I included the run-time splat above too. :)

I don't quite follow, this basically undoes 3024d95a4c52 ("bpf: Partially revert
flexible-array member replacement") again with the small change that this 'fixes'
up the BPF selftest to not embed struct bpf_lpm_trie_key.

Outside of BPF selftests though aren't we readding the same error that we fixed
earlier for BPF programs in the wild which embed struct bpf_lpm_trie_key into their
key structure?

Thanks,
Daniel