Re: [PATCH bpf] libbpf: fix passing uninitialized bytes to setsockopt

On Sat, Oct 12, 2019 at 9:52 PM Ilya Maximets [off-list ref] wrote:

'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
valgrind complain about passing uninitialized stack memory to the
syscall:

  Syscall param socketcall.setsockopt() points to uninitialised byte(s)
    at 0x4E7AB7E: setsockopt (in /usr/lib64/libc-2.29.so)
    by 0x4BDE035: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:172)
  Uninitialised value was created by a stack allocation
    at 0x4BDDEBA: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:140)

Padding bytes appeared after introducing of a new 'flags' field.

Fixes: 10d30e301732 ("libbpf: add flags to umem config")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>

Something is not right with (e|g)mail.
This is 3rd email I got with the same patch.
First one (the one that was applied) was 3 days ago.

On 13.10.2019 6:59, Alexei Starovoitov wrote:

On Sat, Oct 12, 2019 at 9:52 PM Ilya Maximets [off-list ref] wrote:

quoted

'struct xdp_umem_reg' has 4 bytes of padding at the end that makes
valgrind complain about passing uninitialized stack memory to the
syscall:

   Syscall param socketcall.setsockopt() points to uninitialised byte(s)
     at 0x4E7AB7E: setsockopt (in /usr/lib64/libc-2.29.so)
     by 0x4BDE035: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:172)
   Uninitialised value was created by a stack allocation
     at 0x4BDDEBA: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:140)

Padding bytes appeared after introducing of a new 'flags' field.

Fixes: 10d30e301732 ("libbpf: add flags to umem config")
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>

Something is not right with (e|g)mail.
This is 3rd email I got with the same patch.
First one (the one that was applied) was 3 days ago.

I'm sorry.  I don't know why the mail server started re-sending
these e-mails.  I'm receiving them too.

That is strange.

Best regards, Ilya Maximets.