Message ID | 20191009154238.15410-1-i.maximets@ovn.org |
---|---|
State | Changes Requested |
Delegated to: | BPF Maintainers |
Headers | show |
Series | [bpf] libbpf: fix passing uninitialized bytes to setsockopt | expand |
On Wed, Oct 9, 2019 at 8:43 AM Ilya Maximets <i.maximets@ovn.org> 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> > --- > tools/lib/bpf/xsk.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c > index a902838f9fcc..26d9db783560 100644 > --- a/tools/lib/bpf/xsk.c > +++ b/tools/lib/bpf/xsk.c > @@ -139,7 +139,7 @@ int xsk_umem__create_v0_0_4(struct xsk_umem **umem_ptr, void *umem_area, > const struct xsk_umem_config *usr_config) > { > struct xdp_mmap_offsets off; > - struct xdp_umem_reg mr; > + struct xdp_umem_reg mr = {}; well, guess what, even with this explicit initialization, padding is not guaranteed to be initialized (and it's sometimes is not in practice, I ran into such problems), only since C11 standard it is specified that padding is also zero-initialized. You have to do memset to 0. > struct xsk_umem *umem; > socklen_t optlen; > void *map; > -- > 2.17.1 >
On 09.10.2019 18:29, Andrii Nakryiko wrote: > On Wed, Oct 9, 2019 at 8:43 AM Ilya Maximets <i.maximets@ovn.org> 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> >> --- >> tools/lib/bpf/xsk.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c >> index a902838f9fcc..26d9db783560 100644 >> --- a/tools/lib/bpf/xsk.c >> +++ b/tools/lib/bpf/xsk.c >> @@ -139,7 +139,7 @@ int xsk_umem__create_v0_0_4(struct xsk_umem **umem_ptr, void *umem_area, >> const struct xsk_umem_config *usr_config) >> { >> struct xdp_mmap_offsets off; >> - struct xdp_umem_reg mr; >> + struct xdp_umem_reg mr = {}; > > well, guess what, even with this explicit initialization, padding is > not guaranteed to be initialized (and it's sometimes is not in > practice, I ran into such problems), only since C11 standard it is > specified that padding is also zero-initialized. You have to do memset > to 0. OK. Sure. I'll send v2. > >> struct xsk_umem *umem; >> socklen_t optlen; >> void *map; >> -- >> 2.17.1 >>
diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c index a902838f9fcc..26d9db783560 100644 --- a/tools/lib/bpf/xsk.c +++ b/tools/lib/bpf/xsk.c @@ -139,7 +139,7 @@ int xsk_umem__create_v0_0_4(struct xsk_umem **umem_ptr, void *umem_area, const struct xsk_umem_config *usr_config) { struct xdp_mmap_offsets off; - struct xdp_umem_reg mr; + struct xdp_umem_reg mr = {}; struct xsk_umem *umem; socklen_t optlen; void *map;
'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> --- tools/lib/bpf/xsk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)