BPF Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH bpf] libbpf: fix passing uninitialized bytes to setsockopt
@ 2019-10-09 15:42 Ilya Maximets
  2019-10-09 16:29 ` Andrii Nakryiko
  0 siblings, 1 reply; 5+ messages in thread
From: Ilya Maximets @ 2019-10-09 15:42 UTC (permalink / raw)
  To: netdev
  Cc: bpf, linux-kernel, Alexei Starovoitov, Daniel Borkmann,
	David S . Miller, Jonathan Lemon, Ilya Maximets

'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 = {};
 	struct xsk_umem *umem;
 	socklen_t optlen;
 	void *map;
-- 
2.17.1


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf] libbpf: fix passing uninitialized bytes to setsockopt
  2019-10-09 15:42 [PATCH bpf] libbpf: fix passing uninitialized bytes to setsockopt Ilya Maximets
@ 2019-10-09 16:29 ` Andrii Nakryiko
  2019-10-09 16:39   ` Ilya Maximets
  0 siblings, 1 reply; 5+ messages in thread
From: Andrii Nakryiko @ 2019-10-09 16:29 UTC (permalink / raw)
  To: Ilya Maximets
  Cc: Networking, bpf, open list, Alexei Starovoitov, Daniel Borkmann,
	David S . Miller, Jonathan Lemon

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
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf] libbpf: fix passing uninitialized bytes to setsockopt
  2019-10-09 16:29 ` Andrii Nakryiko
@ 2019-10-09 16:39   ` Ilya Maximets
  0 siblings, 0 replies; 5+ messages in thread
From: Ilya Maximets @ 2019-10-09 16:39 UTC (permalink / raw)
  To: Andrii Nakryiko, Ilya Maximets
  Cc: Networking, bpf, open list, Alexei Starovoitov, Daniel Borkmann,
	David S . Miller, Jonathan Lemon

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
>>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf] libbpf: fix passing uninitialized bytes to setsockopt
  2019-10-13  4:59 ` Alexei Starovoitov
@ 2019-10-13 10:01   ` Ilya Maximets
  0 siblings, 0 replies; 5+ messages in thread
From: Ilya Maximets @ 2019-10-13 10:01 UTC (permalink / raw)
  To: Alexei Starovoitov, Ilya Maximets
  Cc: netdev, bpf, linux-kernel, Alexei Starovoitov, Daniel Borkmann,
	David S . Miller, Jonathan Lemon

On 13.10.2019 6:59, Alexei Starovoitov wrote:
> On Sat, Oct 12, 2019 at 9:52 PM 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>
> 
> 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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH bpf] libbpf: fix passing uninitialized bytes to setsockopt
       [not found] <5da2ad7f.1c69fb81.2ed87.f547SMTPIN_ADDED_BROKEN@mx.google.com>
@ 2019-10-13  4:59 ` Alexei Starovoitov
  2019-10-13 10:01   ` Ilya Maximets
  0 siblings, 1 reply; 5+ messages in thread
From: Alexei Starovoitov @ 2019-10-13  4:59 UTC (permalink / raw)
  To: Ilya Maximets
  Cc: netdev, bpf, linux-kernel, Alexei Starovoitov, Daniel Borkmann,
	David S . Miller, Jonathan Lemon

On Sat, Oct 12, 2019 at 9:52 PM 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>

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.

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-09 15:42 [PATCH bpf] libbpf: fix passing uninitialized bytes to setsockopt Ilya Maximets
2019-10-09 16:29 ` Andrii Nakryiko
2019-10-09 16:39   ` Ilya Maximets
     [not found] <5da2ad7f.1c69fb81.2ed87.f547SMTPIN_ADDED_BROKEN@mx.google.com>
2019-10-13  4:59 ` Alexei Starovoitov
2019-10-13 10:01   ` Ilya Maximets

BPF Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/bpf/0 bpf/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 bpf bpf/ https://lore.kernel.org/bpf \
		bpf@vger.kernel.org bpf@archiver.kernel.org
	public-inbox-index bpf

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.bpf


AGPL code for this site: git clone https://public-inbox.org/ public-inbox