lkml.org 
[lkml]   [2024]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2] bpf: Replace bpf_lpm_trie_key 0-length array with flexible array
    On Mon, Feb 19, 2024 at 06:48:41PM +0100, Daniel Borkmann wrote:
    > 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?

    Oops, yes, sorry. I see how that cilium does include it in the same
    fashion. I will adjust this patch again. Thanks for double-checking!

    struct egress_gw_policy_key {
    struct bpf_lpm_trie_key lpm_key;
    __u32 saddr;
    __u32 daddr;
    };

    --
    Kees Cook

    \
     
     \ /
      Last update: 2024-05-27 15:10    [W:5.169 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site