Re: [PATCH] bpf: clean up unused-variable warning

[Daniel Borkmann]

On 02/20/2018 11:07 PM, Arnd Bergmann wrote:
> The only user of this variable is inside of an #ifdef, causing
> a warning without CONFIG_INET:
> 
> net/core/filter.c: In function 'bpf_sock_ops_cb_flags_set':
> net/core/filter.c:3382:6: error: unused variable 'val' 
> [-Werror=unused-variable]
>   int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
> 
> This replaces the #ifdef with a nicer IS_ENABLED() check that
> makes the code more readable and avoids the warning.
> 
> Fixes: b13d88072172 ("bpf: Adds field bpf_sock_ops_cb_flags to tcp_sock")
> Signed-off-by: Arnd Bergmann 

Now applied to bpf, thanks Arnd!

Re: [PATCH] bpf: hide a possibly unused variable

[Daniel Borkmann]

On 02/20/2018 11:08 PM, Arnd Bergmann wrote:
> On Tue, Feb 20, 2018 at 10:44 PM, Daniel Borkmann <dan...@iogearbox.net> 
> wrote:
>> Hi Arnd,
>>
>> On 02/20/2018 10:16 PM, Arnd Bergmann wrote:
>>> The only user of this variable is inside of an #ifdef, causing
>>> a warning without CONFIG_INET:
>>>
>>> net/core/filter.c: In function 'bpf_sock_ops_cb_flags_set':
>>> net/core/filter.c:3382:6: error: unused variable 'val' 
>>> [-Werror=unused-variable]
>>>   int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
>>>
>>> This adds the same #ifdef around the declaration.
>>>
>>> Fixes: b13d88072172 ("bpf: Adds field bpf_sock_ops_cb_flags to tcp_sock")
>>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>>> ---
>>>  net/core/filter.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/net/core/filter.c b/net/core/filter.c
>>> index 08ab4c65a998..c3dc6d60b4bb 100644
>>> --- a/net/core/filter.c
>>> +++ b/net/core/filter.c
>>> @@ -3379,7 +3379,9 @@ BPF_CALL_2(bpf_sock_ops_cb_flags_set, struct 
>>> bpf_sock_ops_kern *, bpf_sock,
>>>  int, argval)
>>>  {
>>>   struct sock *sk = bpf_sock->sk;
>>> +#ifdef CONFIG_INET
>>>   int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
>>> +#endif
>>
>> Looks good, thanks for the fix!
>>
>> Could you move the existing '#ifdef CONFIG_INET' to the beginning of
>> the function given the only error in case of !CONFIG_INET is -EINVAL
>> anyway? That would at least not increase the ifdef ugliness further.
> 
> Sure, sent a new version now. I decided to clean up that #ifdef
> check as well, since a IS_ENABLED() check is nicer anway.

Looks great, thanks! I'll get it into bpf once the pending pr got pulled.

Re: [PATCH] bpf: hide a possibly unused variable

[Daniel Borkmann]

On 02/20/2018 11:08 PM, Arnd Bergmann wrote:
> On Tue, Feb 20, 2018 at 10:44 PM, Daniel Borkmann  
> wrote:
>> Hi Arnd,
>>
>> On 02/20/2018 10:16 PM, Arnd Bergmann wrote:
>>> The only user of this variable is inside of an #ifdef, causing
>>> a warning without CONFIG_INET:
>>>
>>> net/core/filter.c: In function 'bpf_sock_ops_cb_flags_set':
>>> net/core/filter.c:3382:6: error: unused variable 'val' 
>>> [-Werror=unused-variable]
>>>   int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
>>>
>>> This adds the same #ifdef around the declaration.
>>>
>>> Fixes: b13d88072172 ("bpf: Adds field bpf_sock_ops_cb_flags to tcp_sock")
>>> Signed-off-by: Arnd Bergmann 
>>> ---
>>>  net/core/filter.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/net/core/filter.c b/net/core/filter.c
>>> index 08ab4c65a998..c3dc6d60b4bb 100644
>>> --- a/net/core/filter.c
>>> +++ b/net/core/filter.c
>>> @@ -3379,7 +3379,9 @@ BPF_CALL_2(bpf_sock_ops_cb_flags_set, struct 
>>> bpf_sock_ops_kern *, bpf_sock,
>>>  int, argval)
>>>  {
>>>   struct sock *sk = bpf_sock->sk;
>>> +#ifdef CONFIG_INET
>>>   int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
>>> +#endif
>>
>> Looks good, thanks for the fix!
>>
>> Could you move the existing '#ifdef CONFIG_INET' to the beginning of
>> the function given the only error in case of !CONFIG_INET is -EINVAL
>> anyway? That would at least not increase the ifdef ugliness further.
> 
> Sure, sent a new version now. I decided to clean up that #ifdef
> check as well, since a IS_ENABLED() check is nicer anway.

Looks great, thanks! I'll get it into bpf once the pending pr got pulled.

Re: [PATCH] bpf: hide a possibly unused variable

[Daniel Borkmann]

Hi Arnd,

On 02/20/2018 10:16 PM, Arnd Bergmann wrote:
> The only user of this variable is inside of an #ifdef, causing
> a warning without CONFIG_INET:
> 
> net/core/filter.c: In function 'bpf_sock_ops_cb_flags_set':
> net/core/filter.c:3382:6: error: unused variable 'val' 
> [-Werror=unused-variable]
>   int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
> 
> This adds the same #ifdef around the declaration.
> 
> Fixes: b13d88072172 ("bpf: Adds field bpf_sock_ops_cb_flags to tcp_sock")
> Signed-off-by: Arnd Bergmann 
> ---
>  net/core/filter.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 08ab4c65a998..c3dc6d60b4bb 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -3379,7 +3379,9 @@ BPF_CALL_2(bpf_sock_ops_cb_flags_set, struct 
> bpf_sock_ops_kern *, bpf_sock,
>  int, argval)
>  {
>   struct sock *sk = bpf_sock->sk;
> +#ifdef CONFIG_INET
>   int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
> +#endif

Looks good, thanks for the fix!

Could you move the existing '#ifdef CONFIG_INET' to the beginning of
the function given the only error in case of !CONFIG_INET is -EINVAL
anyway? That would at least not increase the ifdef ugliness further.

Thanks a lot,
Daniel

>   if (!sk_fullsock(sk))
>   return -EINVAL;
> 

Re: [PATCH] bpf: hide a possibly unused variable

[Daniel Borkmann]

Hi Arnd,

On 02/20/2018 10:16 PM, Arnd Bergmann wrote:
> The only user of this variable is inside of an #ifdef, causing
> a warning without CONFIG_INET:
> 
> net/core/filter.c: In function 'bpf_sock_ops_cb_flags_set':
> net/core/filter.c:3382:6: error: unused variable 'val' 
> [-Werror=unused-variable]
>   int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
> 
> This adds the same #ifdef around the declaration.
> 
> Fixes: b13d88072172 ("bpf: Adds field bpf_sock_ops_cb_flags to tcp_sock")
> Signed-off-by: Arnd Bergmann 
> ---
>  net/core/filter.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 08ab4c65a998..c3dc6d60b4bb 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -3379,7 +3379,9 @@ BPF_CALL_2(bpf_sock_ops_cb_flags_set, struct 
> bpf_sock_ops_kern *, bpf_sock,
>  int, argval)
>  {
>   struct sock *sk = bpf_sock->sk;
> +#ifdef CONFIG_INET
>   int val = argval & BPF_SOCK_OPS_ALL_CB_FLAGS;
> +#endif

Looks good, thanks for the fix!

Could you move the existing '#ifdef CONFIG_INET' to the beginning of
the function given the only error in case of !CONFIG_INET is -EINVAL
anyway? That would at least not increase the ifdef ugliness further.

Thanks a lot,
Daniel

>   if (!sk_fullsock(sk))
>   return -EINVAL;
> 

Re: [PATCH] tools/libbpf: Avoid possibly using uninitialized variable

[Daniel Borkmann]

On 02/20/2018 02:00 AM, Jeremy Cline wrote:
> Fixes a GCC maybe-uninitialized warning introduced by 48cca7e44f9f.
> "text" is only initialized inside the if statement so only print debug
> info there.
> 
> Signed-off-by: Jeremy Cline 

Looks good, applied to bpf tree, thanks Jeremy!

Re: [PATCH] tools/libbpf: Avoid possibly using uninitialized variable

[Daniel Borkmann]

On 02/20/2018 02:00 AM, Jeremy Cline wrote:
> Fixes a GCC maybe-uninitialized warning introduced by 48cca7e44f9f.
> "text" is only initialized inside the if statement so only print debug
> info there.
> 
> Signed-off-by: Jeremy Cline 

Looks good, applied to bpf tree, thanks Jeremy!

Re: [PATCH net] bpf: cpumap: use GFP_KERNEL instead of GFP_ATOMIC in __cpu_map_entry_alloc()

[Daniel Borkmann]

On 02/14/2018 06:04 PM, Michael S. Tsirkin wrote:
> On Wed, Feb 14, 2018 at 10:17:34PM +0800, Jason Wang wrote:
>> There're several implications after commit 0bf7800f1799 ("ptr_ring:
>> try vmalloc() when kmalloc() fails") with the using of vmalloc() since
>> can't allow GFP_ATOMIC but mandate GFP_KERNEL. This will lead a WARN
>> since cpumap try to call with GFP_ATOMIC. Fortunately, entry
>> allocation of cpumap can only be done through syscall path which means
>> GFP_ATOMIC is not necessary, so fixing this by replacing GFP_ATOMIC
>> with GFP_KERNEL.
>>
>> Reported-by: syzbot+1a240cdb1f4cc8881...@syzkaller.appspotmail.com
>> Fixes: 0bf7800f1799 ("ptr_ring: try vmalloc() when kmalloc() fails")
>> Cc: Michal Hocko <mho...@kernel.org>
>> Cc: Daniel Borkmann <dan...@iogearbox.net>
>> Cc: Matthew Wilcox <wi...@infradead.org>
>> Cc: Jesper Dangaard Brouer <bro...@redhat.com>
>> Cc: a...@linux-foundation.org
>> Cc: dhowe...@redhat.com
>> Cc: han...@cmpxchg.org
>> Signed-off-by: Jason Wang <jasow...@redhat.com>
> 
> Frankly I'd start with the revert. The original patch was rushed
> into net without enough justification IMHO, and we just seem to keep
> piling up these things. How about deferring all these ideas
> to net-next?

It's up to you if you think a revert is needed. The below is fine and
small enough in any case for cpumap, imho.

>>  kernel/bpf/cpumap.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
>> index fbfdada6..a4bb0b3 100644
>> --- a/kernel/bpf/cpumap.c
>> +++ b/kernel/bpf/cpumap.c
>> @@ -334,7 +334,7 @@ static int cpu_map_kthread_run(void *data)
>>  static struct bpf_cpu_map_entry *__cpu_map_entry_alloc(u32 qsize, u32 cpu,
>> int map_id)
>>  {
>> -gfp_t gfp = GFP_ATOMIC|__GFP_NOWARN;
>> +gfp_t gfp = GFP_KERNEL | __GFP_NOWARN;
>>  struct bpf_cpu_map_entry *rcpu;
>>  int numa, err;
>>  
>> -- 
>> 2.7.4

Re: [PATCH net] bpf: cpumap: use GFP_KERNEL instead of GFP_ATOMIC in __cpu_map_entry_alloc()

[Daniel Borkmann]

On 02/14/2018 06:04 PM, Michael S. Tsirkin wrote:
> On Wed, Feb 14, 2018 at 10:17:34PM +0800, Jason Wang wrote:
>> There're several implications after commit 0bf7800f1799 ("ptr_ring:
>> try vmalloc() when kmalloc() fails") with the using of vmalloc() since
>> can't allow GFP_ATOMIC but mandate GFP_KERNEL. This will lead a WARN
>> since cpumap try to call with GFP_ATOMIC. Fortunately, entry
>> allocation of cpumap can only be done through syscall path which means
>> GFP_ATOMIC is not necessary, so fixing this by replacing GFP_ATOMIC
>> with GFP_KERNEL.
>>
>> Reported-by: syzbot+1a240cdb1f4cc8881...@syzkaller.appspotmail.com
>> Fixes: 0bf7800f1799 ("ptr_ring: try vmalloc() when kmalloc() fails")
>> Cc: Michal Hocko 
>> Cc: Daniel Borkmann 
>> Cc: Matthew Wilcox 
>> Cc: Jesper Dangaard Brouer 
>> Cc: a...@linux-foundation.org
>> Cc: dhowe...@redhat.com
>> Cc: han...@cmpxchg.org
>> Signed-off-by: Jason Wang 
> 
> Frankly I'd start with the revert. The original patch was rushed
> into net without enough justification IMHO, and we just seem to keep
> piling up these things. How about deferring all these ideas
> to net-next?

It's up to you if you think a revert is needed. The below is fine and
small enough in any case for cpumap, imho.

>>  kernel/bpf/cpumap.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
>> index fbfdada6..a4bb0b3 100644
>> --- a/kernel/bpf/cpumap.c
>> +++ b/kernel/bpf/cpumap.c
>> @@ -334,7 +334,7 @@ static int cpu_map_kthread_run(void *data)
>>  static struct bpf_cpu_map_entry *__cpu_map_entry_alloc(u32 qsize, u32 cpu,
>> int map_id)
>>  {
>> -gfp_t gfp = GFP_ATOMIC|__GFP_NOWARN;
>> +gfp_t gfp = GFP_KERNEL | __GFP_NOWARN;
>>  struct bpf_cpu_map_entry *rcpu;
>>  int numa, err;
>>  
>> -- 
>> 2.7.4

Re: WARNING: kmalloc bug in bpf_prog_array_copy_info

[Daniel Borkmann]

On 02/14/2018 01:36 PM, Daniel Borkmann wrote:
> On 02/14/2018 12:59 AM, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on bpf-next commit
>> 7928b2cbe55b2a410a0f5c1f154610059c57b1b2 (Sun Feb 11 23:04:29 2018 +)
>> Linux 4.16-rc1
>>
>> So far this crash happened 362 times on bpf-next.
>> C reproducer is attached.
>> syzkaller reproducer is attached.
>> Raw console output is attached.
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached.
> 
> Will send a fix for this in a bit.

(http://patchwork.ozlabs.org/patch/873373/)

#syz fix: bpf: fix bpf_prog_array_copy_to_user warning from perf event prog 
query

Re: WARNING: kmalloc bug in bpf_prog_array_copy_info

[Daniel Borkmann]

On 02/14/2018 01:36 PM, Daniel Borkmann wrote:
> On 02/14/2018 12:59 AM, syzbot wrote:
>> Hello,
>>
>> syzbot hit the following crash on bpf-next commit
>> 7928b2cbe55b2a410a0f5c1f154610059c57b1b2 (Sun Feb 11 23:04:29 2018 +)
>> Linux 4.16-rc1
>>
>> So far this crash happened 362 times on bpf-next.
>> C reproducer is attached.
>> syzkaller reproducer is attached.
>> Raw console output is attached.
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached.
> 
> Will send a fix for this in a bit.

(http://patchwork.ozlabs.org/patch/873373/)

#syz fix: bpf: fix bpf_prog_array_copy_to_user warning from perf event prog 
query

Re: [PATCH net] bpf: cpumap: use GFP_KERNEL instead of GFP_ATOMIC in __cpu_map_entry_alloc()

[Daniel Borkmann]

On 02/14/2018 03:17 PM, Jason Wang wrote:
> There're several implications after commit 0bf7800f1799 ("ptr_ring:
> try vmalloc() when kmalloc() fails") with the using of vmalloc() since
> can't allow GFP_ATOMIC but mandate GFP_KERNEL. This will lead a WARN
> since cpumap try to call with GFP_ATOMIC. Fortunately, entry
> allocation of cpumap can only be done through syscall path which means
> GFP_ATOMIC is not necessary, so fixing this by replacing GFP_ATOMIC
> with GFP_KERNEL.
> 
> Reported-by: syzbot+1a240cdb1f4cc8881...@syzkaller.appspotmail.com
> Fixes: 0bf7800f1799 ("ptr_ring: try vmalloc() when kmalloc() fails")
> Cc: Michal Hocko <mho...@kernel.org>
> Cc: Daniel Borkmann <dan...@iogearbox.net>
> Cc: Matthew Wilcox <wi...@infradead.org>
> Cc: Jesper Dangaard Brouer <bro...@redhat.com>
> Cc: a...@linux-foundation.org
> Cc: dhowe...@redhat.com
> Cc: han...@cmpxchg.org
> Signed-off-by: Jason Wang <jasow...@redhat.com>

Applied to bpf tree, thanks Jason!

Re: [PATCH net] bpf: cpumap: use GFP_KERNEL instead of GFP_ATOMIC in __cpu_map_entry_alloc()

[Daniel Borkmann]

On 02/14/2018 03:17 PM, Jason Wang wrote:
> There're several implications after commit 0bf7800f1799 ("ptr_ring:
> try vmalloc() when kmalloc() fails") with the using of vmalloc() since
> can't allow GFP_ATOMIC but mandate GFP_KERNEL. This will lead a WARN
> since cpumap try to call with GFP_ATOMIC. Fortunately, entry
> allocation of cpumap can only be done through syscall path which means
> GFP_ATOMIC is not necessary, so fixing this by replacing GFP_ATOMIC
> with GFP_KERNEL.
> 
> Reported-by: syzbot+1a240cdb1f4cc8881...@syzkaller.appspotmail.com
> Fixes: 0bf7800f1799 ("ptr_ring: try vmalloc() when kmalloc() fails")
> Cc: Michal Hocko 
> Cc: Daniel Borkmann 
> Cc: Matthew Wilcox 
> Cc: Jesper Dangaard Brouer 
> Cc: a...@linux-foundation.org
> Cc: dhowe...@redhat.com
> Cc: han...@cmpxchg.org
> Signed-off-by: Jason Wang 

Applied to bpf tree, thanks Jason!

Re: WARNING in kvmalloc_node

[Daniel Borkmann]

On 02/14/2018 01:47 PM, Jason Wang wrote:
> On 2018年02月14日 20:29, Jesper Dangaard Brouer wrote:
>> On Wed, 14 Feb 2018 13:17:18 +0100
>> Daniel Borkmann <dan...@iogearbox.net> wrote:
>>> On 02/14/2018 01:02 PM, Jason Wang wrote:
>>>> On 2018年02月14日 19:51, Michal Hocko wrote:
>>>>> On Wed 14-02-18 19:47:30, Jason Wang wrote:
>>>>>> On 2018年02月14日 17:28, Daniel Borkmann wrote:
>>>>>>> [ +Jason, +Jesper ]
>>>>>>>
>>>>>>> On 02/14/2018 09:43 AM, Michal Hocko wrote:
>>>>>>>> On Tue 13-02-18 18:55:33, Matthew Wilcox wrote:
>>>>>>>>> On Tue, Feb 13, 2018 at 03:59:01PM -0800, syzbot wrote:
>>>>>>>> [...]
>>>>>>>>>>     kvmalloc include/linux/mm.h:541 [inline]
>>>>>>>>>>     kvmalloc_array include/linux/mm.h:557 [inline]
>>>>>>>>>>     __ptr_ring_init_queue_alloc include/linux/ptr_ring.h:474 [inline]
>>>>>>>>>>     ptr_ring_init include/linux/ptr_ring.h:492 [inline]
>>>>>>>>>>     __cpu_map_entry_alloc kernel/bpf/cpumap.c:359 [inline]
>>>>>>>>>>     cpu_map_update_elem+0x3c3/0x8e0 kernel/bpf/cpumap.c:490
>>>>>>>>>>     map_update_elem kernel/bpf/syscall.c:698 [inline]
>>>>>>>>> Blame the BPF people, not the MM people ;-)
>>>>>>> Heh, not really. ;-)
>>>>>>>  
>>>>>>>> Yes. kvmalloc (the vmalloc part) doesn't support GFP_ATOMIC semantic.
>>>>>>> Agree, that doesn't work.
>>>>>>>
>>>>>>> Bug was added in commit 0bf7800f1799 ("ptr_ring: try vmalloc() when 
>>>>>>> kmalloc() fails").
>>>>>>>
>>>>>>> Jason, please take a look at fixing this, thanks!
>>>>>> It looks to me the only solution is to revert that commit.
>>>>> Do you really need this to be GFP_ATOMIC? I can see some callers are
>>>>> under RCU read lock but can we perhaps do the allocation outside of this
>>>>> section?
>>>> If I understand the code correctly, the code would be called by XDP 
>>>> program (usually run inside a bh) which makes it hard to do this.
>>>>
>>>> Rethink of this, we can probably test gfp and not call kvmalloc if 
>>>> GFP_ATOMIC is set in __ptr_ring_init_queue_alloc().
>>> That would be one option indeed (probably useful in any case to make the API
>>> more robust). Another one is to just not use GFP_ATOMIC in cpumap. Looking 
>>> at
>>> it, update can neither be called out of a BPF prog since prevented by 
>>> verifier
>>> nor under RCU reader side when updating this type of map from syscall path.
>>> Jesper, any concrete reason we still need GFP_ATOMIC here?
>> Allocations in cpumap (related to ptr_ring) should only be possible to
>> be initiated through userspace via bpf-syscall.
> 
> I see verifier guarantees this.
> 
>>   Thus, there isn't any
>> reason for GFP_ATOMIC here.
> 
> Want me to send a patch to remove GFP_ATOMIC here?

Sounds good, thanks Jason!

Re: WARNING in kvmalloc_node

[Daniel Borkmann]

On 02/14/2018 01:47 PM, Jason Wang wrote:
> On 2018年02月14日 20:29, Jesper Dangaard Brouer wrote:
>> On Wed, 14 Feb 2018 13:17:18 +0100
>> Daniel Borkmann  wrote:
>>> On 02/14/2018 01:02 PM, Jason Wang wrote:
>>>> On 2018年02月14日 19:51, Michal Hocko wrote:
>>>>> On Wed 14-02-18 19:47:30, Jason Wang wrote:
>>>>>> On 2018年02月14日 17:28, Daniel Borkmann wrote:
>>>>>>> [ +Jason, +Jesper ]
>>>>>>>
>>>>>>> On 02/14/2018 09:43 AM, Michal Hocko wrote:
>>>>>>>> On Tue 13-02-18 18:55:33, Matthew Wilcox wrote:
>>>>>>>>> On Tue, Feb 13, 2018 at 03:59:01PM -0800, syzbot wrote:
>>>>>>>> [...]
>>>>>>>>>>     kvmalloc include/linux/mm.h:541 [inline]
>>>>>>>>>>     kvmalloc_array include/linux/mm.h:557 [inline]
>>>>>>>>>>     __ptr_ring_init_queue_alloc include/linux/ptr_ring.h:474 [inline]
>>>>>>>>>>     ptr_ring_init include/linux/ptr_ring.h:492 [inline]
>>>>>>>>>>     __cpu_map_entry_alloc kernel/bpf/cpumap.c:359 [inline]
>>>>>>>>>>     cpu_map_update_elem+0x3c3/0x8e0 kernel/bpf/cpumap.c:490
>>>>>>>>>>     map_update_elem kernel/bpf/syscall.c:698 [inline]
>>>>>>>>> Blame the BPF people, not the MM people ;-)
>>>>>>> Heh, not really. ;-)
>>>>>>>  
>>>>>>>> Yes. kvmalloc (the vmalloc part) doesn't support GFP_ATOMIC semantic.
>>>>>>> Agree, that doesn't work.
>>>>>>>
>>>>>>> Bug was added in commit 0bf7800f1799 ("ptr_ring: try vmalloc() when 
>>>>>>> kmalloc() fails").
>>>>>>>
>>>>>>> Jason, please take a look at fixing this, thanks!
>>>>>> It looks to me the only solution is to revert that commit.
>>>>> Do you really need this to be GFP_ATOMIC? I can see some callers are
>>>>> under RCU read lock but can we perhaps do the allocation outside of this
>>>>> section?
>>>> If I understand the code correctly, the code would be called by XDP 
>>>> program (usually run inside a bh) which makes it hard to do this.
>>>>
>>>> Rethink of this, we can probably test gfp and not call kvmalloc if 
>>>> GFP_ATOMIC is set in __ptr_ring_init_queue_alloc().
>>> That would be one option indeed (probably useful in any case to make the API
>>> more robust). Another one is to just not use GFP_ATOMIC in cpumap. Looking 
>>> at
>>> it, update can neither be called out of a BPF prog since prevented by 
>>> verifier
>>> nor under RCU reader side when updating this type of map from syscall path.
>>> Jesper, any concrete reason we still need GFP_ATOMIC here?
>> Allocations in cpumap (related to ptr_ring) should only be possible to
>> be initiated through userspace via bpf-syscall.
> 
> I see verifier guarantees this.
> 
>>   Thus, there isn't any
>> reason for GFP_ATOMIC here.
> 
> Want me to send a patch to remove GFP_ATOMIC here?

Sounds good, thanks Jason!

Re: WARNING: kmalloc bug in bpf_prog_array_copy_info

[Daniel Borkmann]

On 02/14/2018 12:59 AM, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on bpf-next commit
> 7928b2cbe55b2a410a0f5c1f154610059c57b1b2 (Sun Feb 11 23:04:29 2018 +)
> Linux 4.16-rc1
> 
> So far this crash happened 362 times on bpf-next.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.

Will send a fix for this in a bit.

Re: WARNING: kmalloc bug in bpf_prog_array_copy_info

[Daniel Borkmann]

On 02/14/2018 12:59 AM, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on bpf-next commit
> 7928b2cbe55b2a410a0f5c1f154610059c57b1b2 (Sun Feb 11 23:04:29 2018 +)
> Linux 4.16-rc1
> 
> So far this crash happened 362 times on bpf-next.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.

Will send a fix for this in a bit.

Re: WARNING in kvmalloc_node

[Daniel Borkmann]

On 02/14/2018 01:02 PM, Jason Wang wrote:
> On 2018年02月14日 19:51, Michal Hocko wrote:
>> On Wed 14-02-18 19:47:30, Jason Wang wrote:
>>> On 2018年02月14日 17:28, Daniel Borkmann wrote:
>>>> [ +Jason, +Jesper ]
>>>>
>>>> On 02/14/2018 09:43 AM, Michal Hocko wrote:
>>>>> On Tue 13-02-18 18:55:33, Matthew Wilcox wrote:
>>>>>> On Tue, Feb 13, 2018 at 03:59:01PM -0800, syzbot wrote:
>>>>> [...]
>>>>>>>    kvmalloc include/linux/mm.h:541 [inline]
>>>>>>>    kvmalloc_array include/linux/mm.h:557 [inline]
>>>>>>>    __ptr_ring_init_queue_alloc include/linux/ptr_ring.h:474 [inline]
>>>>>>>    ptr_ring_init include/linux/ptr_ring.h:492 [inline]
>>>>>>>    __cpu_map_entry_alloc kernel/bpf/cpumap.c:359 [inline]
>>>>>>>    cpu_map_update_elem+0x3c3/0x8e0 kernel/bpf/cpumap.c:490
>>>>>>>    map_update_elem kernel/bpf/syscall.c:698 [inline]
>>>>>> Blame the BPF people, not the MM people ;-)
>>>> Heh, not really. ;-)
>>>>
>>>>> Yes. kvmalloc (the vmalloc part) doesn't support GFP_ATOMIC semantic.
>>>> Agree, that doesn't work.
>>>>
>>>> Bug was added in commit 0bf7800f1799 ("ptr_ring: try vmalloc() when 
>>>> kmalloc() fails").
>>>>
>>>> Jason, please take a look at fixing this, thanks!
>>> It looks to me the only solution is to revert that commit.
>> Do you really need this to be GFP_ATOMIC? I can see some callers are
>> under RCU read lock but can we perhaps do the allocation outside of this
>> section?
> 
> If I understand the code correctly, the code would be called by XDP program 
> (usually run inside a bh) which makes it hard to do this.
> 
> Rethink of this, we can probably test gfp and not call kvmalloc if GFP_ATOMIC 
> is set in __ptr_ring_init_queue_alloc().

That would be one option indeed (probably useful in any case to make the API
more robust). Another one is to just not use GFP_ATOMIC in cpumap. Looking at
it, update can neither be called out of a BPF prog since prevented by verifier
nor under RCU reader side when updating this type of map from syscall path.
Jesper, any concrete reason we still need GFP_ATOMIC here?

Re: WARNING in kvmalloc_node

[Daniel Borkmann]

On 02/14/2018 01:02 PM, Jason Wang wrote:
> On 2018年02月14日 19:51, Michal Hocko wrote:
>> On Wed 14-02-18 19:47:30, Jason Wang wrote:
>>> On 2018年02月14日 17:28, Daniel Borkmann wrote:
>>>> [ +Jason, +Jesper ]
>>>>
>>>> On 02/14/2018 09:43 AM, Michal Hocko wrote:
>>>>> On Tue 13-02-18 18:55:33, Matthew Wilcox wrote:
>>>>>> On Tue, Feb 13, 2018 at 03:59:01PM -0800, syzbot wrote:
>>>>> [...]
>>>>>>>    kvmalloc include/linux/mm.h:541 [inline]
>>>>>>>    kvmalloc_array include/linux/mm.h:557 [inline]
>>>>>>>    __ptr_ring_init_queue_alloc include/linux/ptr_ring.h:474 [inline]
>>>>>>>    ptr_ring_init include/linux/ptr_ring.h:492 [inline]
>>>>>>>    __cpu_map_entry_alloc kernel/bpf/cpumap.c:359 [inline]
>>>>>>>    cpu_map_update_elem+0x3c3/0x8e0 kernel/bpf/cpumap.c:490
>>>>>>>    map_update_elem kernel/bpf/syscall.c:698 [inline]
>>>>>> Blame the BPF people, not the MM people ;-)
>>>> Heh, not really. ;-)
>>>>
>>>>> Yes. kvmalloc (the vmalloc part) doesn't support GFP_ATOMIC semantic.
>>>> Agree, that doesn't work.
>>>>
>>>> Bug was added in commit 0bf7800f1799 ("ptr_ring: try vmalloc() when 
>>>> kmalloc() fails").
>>>>
>>>> Jason, please take a look at fixing this, thanks!
>>> It looks to me the only solution is to revert that commit.
>> Do you really need this to be GFP_ATOMIC? I can see some callers are
>> under RCU read lock but can we perhaps do the allocation outside of this
>> section?
> 
> If I understand the code correctly, the code would be called by XDP program 
> (usually run inside a bh) which makes it hard to do this.
> 
> Rethink of this, we can probably test gfp and not call kvmalloc if GFP_ATOMIC 
> is set in __ptr_ring_init_queue_alloc().

That would be one option indeed (probably useful in any case to make the API
more robust). Another one is to just not use GFP_ATOMIC in cpumap. Looking at
it, update can neither be called out of a BPF prog since prevented by verifier
nor under RCU reader side when updating this type of map from syscall path.
Jesper, any concrete reason we still need GFP_ATOMIC here?

Re: WARNING in kvmalloc_node

[Daniel Borkmann]

[ +Jason, +Jesper ]

On 02/14/2018 09:43 AM, Michal Hocko wrote:
> On Tue 13-02-18 18:55:33, Matthew Wilcox wrote:
>> On Tue, Feb 13, 2018 at 03:59:01PM -0800, syzbot wrote:
> [...]
>>>  kvmalloc include/linux/mm.h:541 [inline]
>>>  kvmalloc_array include/linux/mm.h:557 [inline]
>>>  __ptr_ring_init_queue_alloc include/linux/ptr_ring.h:474 [inline]
>>>  ptr_ring_init include/linux/ptr_ring.h:492 [inline]
>>>  __cpu_map_entry_alloc kernel/bpf/cpumap.c:359 [inline]
>>>  cpu_map_update_elem+0x3c3/0x8e0 kernel/bpf/cpumap.c:490
>>>  map_update_elem kernel/bpf/syscall.c:698 [inline]
>>
>> Blame the BPF people, not the MM people ;-)

Heh, not really. ;-)

> Yes. kvmalloc (the vmalloc part) doesn't support GFP_ATOMIC semantic.

Agree, that doesn't work.

Bug was added in commit 0bf7800f1799 ("ptr_ring: try vmalloc() when kmalloc() 
fails").

Jason, please take a look at fixing this, thanks!

Re: WARNING in kvmalloc_node

[Daniel Borkmann]

[ +Jason, +Jesper ]

On 02/14/2018 09:43 AM, Michal Hocko wrote:
> On Tue 13-02-18 18:55:33, Matthew Wilcox wrote:
>> On Tue, Feb 13, 2018 at 03:59:01PM -0800, syzbot wrote:
> [...]
>>>  kvmalloc include/linux/mm.h:541 [inline]
>>>  kvmalloc_array include/linux/mm.h:557 [inline]
>>>  __ptr_ring_init_queue_alloc include/linux/ptr_ring.h:474 [inline]
>>>  ptr_ring_init include/linux/ptr_ring.h:492 [inline]
>>>  __cpu_map_entry_alloc kernel/bpf/cpumap.c:359 [inline]
>>>  cpu_map_update_elem+0x3c3/0x8e0 kernel/bpf/cpumap.c:490
>>>  map_update_elem kernel/bpf/syscall.c:698 [inline]
>>
>> Blame the BPF people, not the MM people ;-)

Heh, not really. ;-)

> Yes. kvmalloc (the vmalloc part) doesn't support GFP_ATOMIC semantic.

Agree, that doesn't work.

Bug was added in commit 0bf7800f1799 ("ptr_ring: try vmalloc() when kmalloc() 
fails").

Jason, please take a look at fixing this, thanks!

Re: lost connection to test machine (4)

[Daniel Borkmann]

On 02/12/2018 05:03 PM, Dmitry Vyukov wrote:
> On Mon, Feb 12, 2018 at 5:00 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzbot hit the following crash on bpf-next commit
>> 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +)
>> Merge tag 'usercopy-v4.16-rc1' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
>>
>> So far this crash happened 898 times on bpf-next, net-next, upstream.
>> C reproducer is attached.
>> syzkaller reproducer is attached.
>> Raw console output is attached.
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached.
> 
> The reproducer first causes several tasks spending minutes at this stack:
> 
> [  110.762189] NMI backtrace for cpu 2
> [  110.762206] CPU: 2 PID: 3760 Comm: syz-executor Not tainted 4.15.0+ #96
> [  110.762210] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Bochs 01/01/2011
> [  110.762224] RIP: 0010:mutex_spin_on_owner+0x303/0x420
> [  110.762232] INFO: NMI handler (nmi_cpu_backtrace_handler) took too
> long to run: 1.103 msecs
> [  110.762237] RSP: 0018:88005be470e8 EFLAGS: 0246
> [  110.762268] RAX: 88006ca0 RBX:  RCX: 
> 81554165
> [  110.762275] RDX: 0001 RSI: 10d97884 RDI: 
> 
> [  110.762281] RBP: 88005be47210 R08: dc01 R09: 
> fbfff0db2b75
> [  110.762286] R10: fbfff0db2b74 R11: 86d95ba7 R12: 
> 86d95ba0
> [  110.762292] R13: ed000b7c8e25 R14: dc00 R15: 
> 880064691040
> [  110.762300] FS:  7f84ed029700() GS:88006cb0()
> knlGS:
> [  110.762305] CS:  0010 DS:  ES:  CR0: 80050033
> [  110.762311] CR2: 7fd565f7b1b0 CR3: 5bddf002 CR4: 
> 001606e0
> [  110.762316] Call Trace:
> [  110.762383]  __mutex_lock.isra.1+0x97d/0x1440
> [  110.762659]  __mutex_lock_slowpath+0xe/0x10
> [  110.762668]  mutex_lock+0x3e/0x50
> [  110.762677]  pcpu_alloc+0x846/0xfe0
> [  110.762778]  __alloc_percpu_gfp+0x27/0x30
> [  110.762801]  array_map_alloc+0x484/0x690
> [  110.762832]  SyS_bpf+0xa27/0x4770
> [  110.763190]  do_syscall_64+0x297/0x760
> [  110.763260]  entry_SYSCALL_64_after_hwframe+0x21/0x86
> 
> and later machine dies with:
> 
> [  191.484308] Kernel panic - not syncing: Out of memory and no
> killable processes...
> [  191.484308]
> [  191.485740] CPU: 3 PID: 746 Comm: kworker/3:1 Not tainted 4.15.0+ #96
> [  191.486761] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Bochs 01/01/2011
> [  191.488071] Workqueue: events pcpu_balance_workfn
> [  191.488821] Call Trace:
> [  191.489299]  dump_stack+0x175/0x225
> [  191.490590]  panic+0x22a/0x4be
> [  191.493061]  out_of_memory.cold.31+0x20/0x21
> [  191.496380]  __alloc_pages_slowpath+0x1d98/0x28a0
> [  191.503616]  __alloc_pages_nodemask+0x89c/0xc60
> [  191.507876]  pcpu_populate_chunk+0x1fd/0x9b0
> [  191.510114]  pcpu_balance_workfn+0x1019/0x1450
> [  191.517804]  process_one_work+0x9d5/0x1460
> [  191.522714]  worker_thread+0x1cc/0x1410
> [  191.529319]  kthread+0x304/0x3c0
> 
> The original message with attachments is here:
> https://groups.google.com/d/msg/syzkaller-bugs/Km3xEZu9zzU/rO-7XuwZAgAJ

[ +Dennis, +Tejun ]

Looks like we're stuck in percpu allocator with key/value size of 4 bytes
each and large number of entries (max_entries) in the reproducer in above
link.

Could we have some __GFP_NORETRY semantics and let allocations fail instead
of triggering OOM killer?

Re: lost connection to test machine (4)

[Daniel Borkmann]

On 02/12/2018 05:03 PM, Dmitry Vyukov wrote:
> On Mon, Feb 12, 2018 at 5:00 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzbot hit the following crash on bpf-next commit
>> 617aebe6a97efa539cc4b8a52adccd89596e6be0 (Sun Feb 4 00:25:42 2018 +)
>> Merge tag 'usercopy-v4.16-rc1' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux
>>
>> So far this crash happened 898 times on bpf-next, net-next, upstream.
>> C reproducer is attached.
>> syzkaller reproducer is attached.
>> Raw console output is attached.
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached.
> 
> The reproducer first causes several tasks spending minutes at this stack:
> 
> [  110.762189] NMI backtrace for cpu 2
> [  110.762206] CPU: 2 PID: 3760 Comm: syz-executor Not tainted 4.15.0+ #96
> [  110.762210] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Bochs 01/01/2011
> [  110.762224] RIP: 0010:mutex_spin_on_owner+0x303/0x420
> [  110.762232] INFO: NMI handler (nmi_cpu_backtrace_handler) took too
> long to run: 1.103 msecs
> [  110.762237] RSP: 0018:88005be470e8 EFLAGS: 0246
> [  110.762268] RAX: 88006ca0 RBX:  RCX: 
> 81554165
> [  110.762275] RDX: 0001 RSI: 10d97884 RDI: 
> 
> [  110.762281] RBP: 88005be47210 R08: dc01 R09: 
> fbfff0db2b75
> [  110.762286] R10: fbfff0db2b74 R11: 86d95ba7 R12: 
> 86d95ba0
> [  110.762292] R13: ed000b7c8e25 R14: dc00 R15: 
> 880064691040
> [  110.762300] FS:  7f84ed029700() GS:88006cb0()
> knlGS:
> [  110.762305] CS:  0010 DS:  ES:  CR0: 80050033
> [  110.762311] CR2: 7fd565f7b1b0 CR3: 5bddf002 CR4: 
> 001606e0
> [  110.762316] Call Trace:
> [  110.762383]  __mutex_lock.isra.1+0x97d/0x1440
> [  110.762659]  __mutex_lock_slowpath+0xe/0x10
> [  110.762668]  mutex_lock+0x3e/0x50
> [  110.762677]  pcpu_alloc+0x846/0xfe0
> [  110.762778]  __alloc_percpu_gfp+0x27/0x30
> [  110.762801]  array_map_alloc+0x484/0x690
> [  110.762832]  SyS_bpf+0xa27/0x4770
> [  110.763190]  do_syscall_64+0x297/0x760
> [  110.763260]  entry_SYSCALL_64_after_hwframe+0x21/0x86
> 
> and later machine dies with:
> 
> [  191.484308] Kernel panic - not syncing: Out of memory and no
> killable processes...
> [  191.484308]
> [  191.485740] CPU: 3 PID: 746 Comm: kworker/3:1 Not tainted 4.15.0+ #96
> [  191.486761] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Bochs 01/01/2011
> [  191.488071] Workqueue: events pcpu_balance_workfn
> [  191.488821] Call Trace:
> [  191.489299]  dump_stack+0x175/0x225
> [  191.490590]  panic+0x22a/0x4be
> [  191.493061]  out_of_memory.cold.31+0x20/0x21
> [  191.496380]  __alloc_pages_slowpath+0x1d98/0x28a0
> [  191.503616]  __alloc_pages_nodemask+0x89c/0xc60
> [  191.507876]  pcpu_populate_chunk+0x1fd/0x9b0
> [  191.510114]  pcpu_balance_workfn+0x1019/0x1450
> [  191.517804]  process_one_work+0x9d5/0x1460
> [  191.522714]  worker_thread+0x1cc/0x1410
> [  191.529319]  kthread+0x304/0x3c0
> 
> The original message with attachments is here:
> https://groups.google.com/d/msg/syzkaller-bugs/Km3xEZu9zzU/rO-7XuwZAgAJ

[ +Dennis, +Tejun ]

Looks like we're stuck in percpu allocator with key/value size of 4 bytes
each and large number of entries (max_entries) in the reproducer in above
link.

Could we have some __GFP_NORETRY semantics and let allocations fail instead
of triggering OOM killer?

Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192):

[Daniel Borkmann]

On 02/12/2018 06:47 AM, Yonghong Song wrote:
> On 2/11/18 11:18 AM, Mathieu Malaterre wrote:
>> On Sun, Feb 11, 2018 at 5:54 PM, Alexei Starovoitov
>>  wrote:
>>> On Sun, Feb 11, 2018 at 7:24 AM, Mathieu Malaterre  wrote:
 Alexei,

 Could you please comment on why I am seeing those memleaks being
 reported on my ppc32 system ? Should they be marked as false positive
 ?

 System is Mac Mini G4, git/master (4.15.0+), ppc.

 Thanks for your time

 $ dmesg
 ...
 [ 1281.504173] kmemleak: 36 new suspected memory leaks (see
 /sys/kernel/debug/kmemleak)

 Where:

 # cat /sys/kernel/debug/kmemleak
 unreferenced object 0xdee25000 (size 192):
    comm "systemd", pid 1, jiffies 4294894348 (age 1438.580s)
    hex dump (first 32 bytes):
  c0 56 2f 88 00 00 00 00 00 00 00 0b 00 00 00 0c  .V/.
  00 00 00 08 00 00 00 01 00 00 00 01 00 00 00 01  
    backtrace:
  [<6c69baf5>] trie_alloc+0xb0/0x150
  [] SyS_bpf+0x288/0x1458
  [<82182f53>] ret_from_syscall+0x0/0x38
 unreferenced object 0xdee25900 (size 192):
    comm "systemd", pid 1, jiffies 4294894540 (age 1437.812s)
    hex dump (first 32 bytes):
  c0 56 2f 88 00 00 00 00 00 00 00 0b 00 00 00 08  .V/.
  00 00 00 08 00 00 00 01 00 00 00 01 00 00 00 01  
    backtrace:
  [<6c69baf5>] trie_alloc+0xb0/0x150
  [] SyS_bpf+0x288/0x1458
  [<82182f53>] ret_from_syscall+0x0/0x38
>>>
>>> hmm. looks real. Is there a reproducer?
>>> Yonghong, lpm map not cleaning after itself?
>>
>> Not really. I simply boot up my machine and wait for the first kmemleak scan.
> 
> I am not able to reproduce the issue. Tried with latest net-next on FC26 with 
> kmemleak on. I only got this one after bootup,
> 'cat /sys/kernel/debug/kmemleak' or
> 'echo scan > /sys/kernel/debug/kmemleak
>  cat /sys/kernel/debug/kmemleak':
> 
> unreferenced object 0x99701a7386e0 (size 32):
>   comm "mount", pid 1856, jiffies 4294669263 (age 98.440s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace:
>     [<4668ec00>] security_sb_parse_opts_str+0x36/0x50
>     [] parse_security_options+0x3d/0x60
>     [] btrfs_mount_root+0x139/0x720
>     [] mount_fs+0x30/0x150
>     [] vfs_kern_mount.part.26+0x54/0x100
>     [<93ae5db7>] btrfs_mount+0x184/0x914
>     [] mount_fs+0x30/0x150
>     [] vfs_kern_mount.part.26+0x54/0x100
>     [<3b67b9fc>] do_mount+0x5b9/0xc70
>     [] SyS_mount+0x80/0xd0
>     [] do_syscall_64+0x5d/0x110
>     [<3d61f5fc>] entry_SYSCALL_64_after_hwframe+0x21/0x86
>     [<458a6ffa>] 0x
> 
> Not sure whether the above is a true issue or not.
> 
> However, by inspecting the code, I do find the trie_free in lpm_trie.c
> may have missed freeing the trie memory.
> 
> The change likes below should work:
> -bash-4.2$ git diff
> diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
> index 7b469d1..cecb259 100644
> --- a/kernel/bpf/lpm_trie.c
> +++ b/kernel/bpf/lpm_trie.c
> @@ -589,6 +589,7 @@ static void trie_free(struct bpf_map *map)
> 
>  unlock:
>     raw_spin_unlock(>lock);
> +   kfree(trie);
>  }
> 
>  static int trie_get_next_key(struct bpf_map *map, void *_key, void 
> *_next_key)
> -bash-4.2$
> 
> Will propose a formal patch for this soon.

Agree, good catch, and I also think that this is the issue, since this
is what kmemleak reports in terms of size (192):

struct lpm_trie {
struct bpf_map map;  /* 0   128 */
/* --- cacheline 2 boundary (128 bytes) --- */
struct lpm_trie_node * root; /*   128 8 */
size_t n_entries;/*   136 8 */
size_t max_prefixlen;/*   144 8 */
size_t data_size;/*   152 8 */
raw_spinlock_t lock; /*   160 4 */

/* size: 192, cachelines: 3, members: 6 */
/* padding: 28 */
};

Re: [kmemleak] unreferenced object 0xcd9c1a80 (size 192):

[Daniel Borkmann]

On 02/12/2018 06:47 AM, Yonghong Song wrote:
> On 2/11/18 11:18 AM, Mathieu Malaterre wrote:
>> On Sun, Feb 11, 2018 at 5:54 PM, Alexei Starovoitov
>>  wrote:
>>> On Sun, Feb 11, 2018 at 7:24 AM, Mathieu Malaterre  wrote:
 Alexei,

 Could you please comment on why I am seeing those memleaks being
 reported on my ppc32 system ? Should they be marked as false positive
 ?

 System is Mac Mini G4, git/master (4.15.0+), ppc.

 Thanks for your time

 $ dmesg
 ...
 [ 1281.504173] kmemleak: 36 new suspected memory leaks (see
 /sys/kernel/debug/kmemleak)

 Where:

 # cat /sys/kernel/debug/kmemleak
 unreferenced object 0xdee25000 (size 192):
    comm "systemd", pid 1, jiffies 4294894348 (age 1438.580s)
    hex dump (first 32 bytes):
  c0 56 2f 88 00 00 00 00 00 00 00 0b 00 00 00 0c  .V/.
  00 00 00 08 00 00 00 01 00 00 00 01 00 00 00 01  
    backtrace:
  [<6c69baf5>] trie_alloc+0xb0/0x150
  [] SyS_bpf+0x288/0x1458
  [<82182f53>] ret_from_syscall+0x0/0x38
 unreferenced object 0xdee25900 (size 192):
    comm "systemd", pid 1, jiffies 4294894540 (age 1437.812s)
    hex dump (first 32 bytes):
  c0 56 2f 88 00 00 00 00 00 00 00 0b 00 00 00 08  .V/.
  00 00 00 08 00 00 00 01 00 00 00 01 00 00 00 01  
    backtrace:
  [<6c69baf5>] trie_alloc+0xb0/0x150
  [] SyS_bpf+0x288/0x1458
  [<82182f53>] ret_from_syscall+0x0/0x38
>>>
>>> hmm. looks real. Is there a reproducer?
>>> Yonghong, lpm map not cleaning after itself?
>>
>> Not really. I simply boot up my machine and wait for the first kmemleak scan.
> 
> I am not able to reproduce the issue. Tried with latest net-next on FC26 with 
> kmemleak on. I only got this one after bootup,
> 'cat /sys/kernel/debug/kmemleak' or
> 'echo scan > /sys/kernel/debug/kmemleak
>  cat /sys/kernel/debug/kmemleak':
> 
> unreferenced object 0x99701a7386e0 (size 32):
>   comm "mount", pid 1856, jiffies 4294669263 (age 98.440s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
>   backtrace:
>     [<4668ec00>] security_sb_parse_opts_str+0x36/0x50
>     [] parse_security_options+0x3d/0x60
>     [] btrfs_mount_root+0x139/0x720
>     [] mount_fs+0x30/0x150
>     [] vfs_kern_mount.part.26+0x54/0x100
>     [<93ae5db7>] btrfs_mount+0x184/0x914
>     [] mount_fs+0x30/0x150
>     [] vfs_kern_mount.part.26+0x54/0x100
>     [<3b67b9fc>] do_mount+0x5b9/0xc70
>     [] SyS_mount+0x80/0xd0
>     [] do_syscall_64+0x5d/0x110
>     [<3d61f5fc>] entry_SYSCALL_64_after_hwframe+0x21/0x86
>     [<458a6ffa>] 0x
> 
> Not sure whether the above is a true issue or not.
> 
> However, by inspecting the code, I do find the trie_free in lpm_trie.c
> may have missed freeing the trie memory.
> 
> The change likes below should work:
> -bash-4.2$ git diff
> diff --git a/kernel/bpf/lpm_trie.c b/kernel/bpf/lpm_trie.c
> index 7b469d1..cecb259 100644
> --- a/kernel/bpf/lpm_trie.c
> +++ b/kernel/bpf/lpm_trie.c
> @@ -589,6 +589,7 @@ static void trie_free(struct bpf_map *map)
> 
>  unlock:
>     raw_spin_unlock(>lock);
> +   kfree(trie);
>  }
> 
>  static int trie_get_next_key(struct bpf_map *map, void *_key, void 
> *_next_key)
> -bash-4.2$
> 
> Will propose a formal patch for this soon.

Agree, good catch, and I also think that this is the issue, since this
is what kmemleak reports in terms of size (192):

struct lpm_trie {
struct bpf_map map;  /* 0   128 */
/* --- cacheline 2 boundary (128 bytes) --- */
struct lpm_trie_node * root; /*   128 8 */
size_t n_entries;/*   136 8 */
size_t max_prefixlen;/*   144 8 */
size_t data_size;/*   152 8 */
raw_spinlock_t lock; /*   160 4 */

/* size: 192, cachelines: 3, members: 6 */
/* padding: 28 */
};

Re: [Resend] Question: kselftests: bpf/test_maps failed

[Daniel Borkmann]

On 02/09/2018 06:14 AM, Li Zhijian wrote:
> Hi
> 
> INTEL 0-Day noticed that bpf/test_maps has different results at different 
> platforms.
> when it fails, the details are like

Sorry for the late reply and thanks for reporting! More below:

> --
>   880 Failed to create hashmap key=16 value=131072 'Cannot allocate memory'
>   881 Failed to create hashmap key=8 value=32768 'Cannot allocate memory'
>   882 Failed to create hashmap key=8 value=131072 'Cannot allocate memory'
>   883 Failed to create hashmap key=16 value=32768 'Cannot allocate memory'
>   884 Failed to create hashmap key=8 value=16384 'Cannot allocate memory'
>   885 Failed to create hashmap key=16 value=16384 'Cannot allocate memory'
>   886 Failed to create hashmap key=8 value=65536 'Cannot allocate memory'
>   887 Failed to create hashmap key=16 value=131072 'Cannot allocate memory'
>   888 Failed to create hashmap key=16 value=32768 'Cannot allocate memory'
>   889 Failed to create hashmap key=16 value=65536 'Cannot allocate memory'
>   890 Failed to create hashmap key=8 value=65536 'Cannot allocate memory'
>   891 Failed to create hashmap key=8 value=131072 'Cannot allocate memory'
>   892 Failed to create hashmap key=8 value=131072 'Cannot allocate memory'
>   893 Failed to create hashmap key=16 value=32768 'Cannot allocate memory'
>   894 Failed to create hashmap key=8 value=16384 'Cannot allocate memory'
>   895 Failed to create hashmap key=8 value=131072 'Cannot allocate memory'
>   896 Failed to create hashmap key=16 value=8192 'Cannot allocate memory'
>   897 Failed to create hashmap key=8 value=32768 'Cannot allocate memory'
>   898 Failed to create hashmap key=16 value=8192 'Cannot allocate memory'
>   899 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   900 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   901 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   902 Failed to create hashmap key=16 value=262144 'Cannot allocate memory'
>   903 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   904 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   905 test_maps: test_maps.c:955: run_parallel: Assertion `status == 0' 
> failed.
>   906 Aborted
>   907 not ok 1..3 selftests:  test_maps [FAIL]
> --
> 
> After a simply looking at the code, looks it's related to the cpu number and 
> system memory.
> 
> below are the result under different platform
> 1. Good
> model: Sandy Bridge
> nr_node: 1
> nr_cpu: 4
> memory: 6G
> 
> 2. Good
> model: qemu-system-x86_64 -enable-kvm
> nr_cpu: 2
> memory: 4G
> 
> 3. Bad
> model: Ivytown Ivy Bridge-EP
> nr_cpu: 48
> memory: 64G
> 
> 4. Bad
> model: Skylake
> nr_cpu: 104
> memory: 64G
> 
> I try to change the process number to 10 from 100, so it can pass at above 
> Skylake(4) machine.
> 
> lizhijian@haswell-OptiPlex-9020:~/lkp/linux/tools/testing/selftests/bpf$ git 
> diff
> diff --git a/tools/testing/selftests/bpf/test_maps.c 
> b/tools/testing/selftests/bpf/test_maps.c
> index 040356e..b788ca1 100644
> --- a/tools/testing/selftests/bpf/test_maps.c
> +++ b/tools/testing/selftests/bpf/test_maps.c
> @@ -960,7 +960,7 @@ static void test_map_stress(void)
>  {
>     run_parallel(100, test_hashmap, NULL);
>     run_parallel(100, test_hashmap_percpu, NULL);
> -   run_parallel(100, test_hashmap_sizes, NULL);
> +   run_parallel(10, test_hashmap_sizes, NULL);
>     run_parallel(100, test_hashmap_walk, NULL);
>  
>     run_parallel(100, test_arraymap, NULL);

Unless Alexei has some better idea, I think if the bpf_create_map() error in
the stress test is about ENOMEM, then we shouldn't fail hard via exit(), for
all other cases we should however. So probably makes sense to just check for
errno == ENOMEM in case of fd < 0 in test_hashmap_sizes() and then continue
to keep trying under stress. Feel free to send a patch, Li.

Thanks again,
Daniel

Re: [Resend] Question: kselftests: bpf/test_maps failed

[Daniel Borkmann]

On 02/09/2018 06:14 AM, Li Zhijian wrote:
> Hi
> 
> INTEL 0-Day noticed that bpf/test_maps has different results at different 
> platforms.
> when it fails, the details are like

Sorry for the late reply and thanks for reporting! More below:

> --
>   880 Failed to create hashmap key=16 value=131072 'Cannot allocate memory'
>   881 Failed to create hashmap key=8 value=32768 'Cannot allocate memory'
>   882 Failed to create hashmap key=8 value=131072 'Cannot allocate memory'
>   883 Failed to create hashmap key=16 value=32768 'Cannot allocate memory'
>   884 Failed to create hashmap key=8 value=16384 'Cannot allocate memory'
>   885 Failed to create hashmap key=16 value=16384 'Cannot allocate memory'
>   886 Failed to create hashmap key=8 value=65536 'Cannot allocate memory'
>   887 Failed to create hashmap key=16 value=131072 'Cannot allocate memory'
>   888 Failed to create hashmap key=16 value=32768 'Cannot allocate memory'
>   889 Failed to create hashmap key=16 value=65536 'Cannot allocate memory'
>   890 Failed to create hashmap key=8 value=65536 'Cannot allocate memory'
>   891 Failed to create hashmap key=8 value=131072 'Cannot allocate memory'
>   892 Failed to create hashmap key=8 value=131072 'Cannot allocate memory'
>   893 Failed to create hashmap key=16 value=32768 'Cannot allocate memory'
>   894 Failed to create hashmap key=8 value=16384 'Cannot allocate memory'
>   895 Failed to create hashmap key=8 value=131072 'Cannot allocate memory'
>   896 Failed to create hashmap key=16 value=8192 'Cannot allocate memory'
>   897 Failed to create hashmap key=8 value=32768 'Cannot allocate memory'
>   898 Failed to create hashmap key=16 value=8192 'Cannot allocate memory'
>   899 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   900 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   901 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   902 Failed to create hashmap key=16 value=262144 'Cannot allocate memory'
>   903 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   904 Failed to create hashmap key=8 value=262144 'Cannot allocate memory'
>   905 test_maps: test_maps.c:955: run_parallel: Assertion `status == 0' 
> failed.
>   906 Aborted
>   907 not ok 1..3 selftests:  test_maps [FAIL]
> --
> 
> After a simply looking at the code, looks it's related to the cpu number and 
> system memory.
> 
> below are the result under different platform
> 1. Good
> model: Sandy Bridge
> nr_node: 1
> nr_cpu: 4
> memory: 6G
> 
> 2. Good
> model: qemu-system-x86_64 -enable-kvm
> nr_cpu: 2
> memory: 4G
> 
> 3. Bad
> model: Ivytown Ivy Bridge-EP
> nr_cpu: 48
> memory: 64G
> 
> 4. Bad
> model: Skylake
> nr_cpu: 104
> memory: 64G
> 
> I try to change the process number to 10 from 100, so it can pass at above 
> Skylake(4) machine.
> 
> lizhijian@haswell-OptiPlex-9020:~/lkp/linux/tools/testing/selftests/bpf$ git 
> diff
> diff --git a/tools/testing/selftests/bpf/test_maps.c 
> b/tools/testing/selftests/bpf/test_maps.c
> index 040356e..b788ca1 100644
> --- a/tools/testing/selftests/bpf/test_maps.c
> +++ b/tools/testing/selftests/bpf/test_maps.c
> @@ -960,7 +960,7 @@ static void test_map_stress(void)
>  {
>     run_parallel(100, test_hashmap, NULL);
>     run_parallel(100, test_hashmap_percpu, NULL);
> -   run_parallel(100, test_hashmap_sizes, NULL);
> +   run_parallel(10, test_hashmap_sizes, NULL);
>     run_parallel(100, test_hashmap_walk, NULL);
>  
>     run_parallel(100, test_arraymap, NULL);

Unless Alexei has some better idea, I think if the bpf_create_map() error in
the stress test is about ENOMEM, then we shouldn't fail hard via exit(), for
all other cases we should however. So probably makes sense to just check for
errno == ENOMEM in case of fd < 0 in test_hashmap_sizes() and then continue
to keep trying under stress. Feel free to send a patch, Li.

Thanks again,
Daniel

Re: [PATCH bpf-next v8 0/5] libbpf: add XDP binding support

[Daniel Borkmann]

On 01/30/2018 09:50 PM, Eric Leblond wrote:
> Hello Daniel,
> 
> No problem with the delay in the answer. I'm doing far worse.
> 
> Here is an updated version:
> - add if_link.h in uapi and remove the definition
> - fix a commit message
> - remove uapi from a include

Fyi, this still needs to wait for a bit in the queue due to current
merge window where bpf-next is closed during that time [0]. Thanks!

  [0] https://www.spinics.net/lists/netdev/msg481490.html

Re: [PATCH bpf-next v8 0/5] libbpf: add XDP binding support

[Daniel Borkmann]

On 01/30/2018 09:50 PM, Eric Leblond wrote:
> Hello Daniel,
> 
> No problem with the delay in the answer. I'm doing far worse.
> 
> Here is an updated version:
> - add if_link.h in uapi and remove the definition
> - fix a commit message
> - remove uapi from a include

Fyi, this still needs to wait for a bit in the queue due to current
merge window where bpf-next is closed during that time [0]. Thanks!

  [0] https://www.spinics.net/lists/netdev/msg481490.html

Re: general protection fault in ___bpf_prog_run

[Daniel Borkmann]

On 01/30/2018 09:58 PM, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on bpf-next commit
> 868c36dcc949c26bc74fa4661b670d9acc6489e4 (Mon Jan 29 03:00:16 2018 +)
> Merge tag 'wireless-drivers-next-for-davem-2018-01-26' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
> 
> So far this crash happened 2 times on bpf-next.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+1eb094057b338eb1f...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for details.
> If you forward the report, please keep this part and the footer.

Really great syzkaller report !

Fixed by: http://patchwork.ozlabs.org/patch/867748/

Re: general protection fault in ___bpf_prog_run

[Daniel Borkmann]

On 01/30/2018 09:58 PM, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on bpf-next commit
> 868c36dcc949c26bc74fa4661b670d9acc6489e4 (Mon Jan 29 03:00:16 2018 +)
> Merge tag 'wireless-drivers-next-for-davem-2018-01-26' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
> 
> So far this crash happened 2 times on bpf-next.
> C reproducer is attached.
> syzkaller reproducer is attached.
> Raw console output is attached.
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached.
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+1eb094057b338eb1f...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for details.
> If you forward the report, please keep this part and the footer.

Really great syzkaller report !

Fixed by: http://patchwork.ozlabs.org/patch/867748/

Re: general protection fault in ___bpf_prog_run

[Daniel Borkmann]

On 01/30/2018 09:58 PM, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on bpf-next commit
> 868c36dcc949c26bc74fa4661b670d9acc6489e4 (Mon Jan 29 03:00:16 2018 +)
> Merge tag 'wireless-drivers-next-for-davem-2018-01-26' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next

Thanks for the report, looking into it right now.

Re: general protection fault in ___bpf_prog_run

[Daniel Borkmann]

On 01/30/2018 09:58 PM, syzbot wrote:
> Hello,
> 
> syzbot hit the following crash on bpf-next commit
> 868c36dcc949c26bc74fa4661b670d9acc6489e4 (Mon Jan 29 03:00:16 2018 +)
> Merge tag 'wireless-drivers-next-for-davem-2018-01-26' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next

Thanks for the report, looking into it right now.

Re: net: hang in unregister_netdevice: waiting for lo to become free

[Daniel Borkmann]

On 01/30/2018 07:32 PM, Cong Wang wrote:
> On Tue, Jan 30, 2018 at 4:09 AM, Dmitry Vyukov  wrote:
>> Hello,
>>
>> The following program creates a hang in unregister_netdevice.
>> cleanup_net work hangs there forever periodically printing
>> "unregister_netdevice: waiting for lo to become free. Usage count = 3"
>> and creation of any new network namespaces hangs forever.
> 
> Interestingly, this is not reproducible on net-next.

The most recent change on netns refcnt was 4ee806d51176 ("net: tcp: close
sock if net namespace is exiting") in net/net-next from 5 days ago, maybe
fixed due to that?

Re: net: hang in unregister_netdevice: waiting for lo to become free

[Daniel Borkmann]

On 01/30/2018 07:32 PM, Cong Wang wrote:
> On Tue, Jan 30, 2018 at 4:09 AM, Dmitry Vyukov  wrote:
>> Hello,
>>
>> The following program creates a hang in unregister_netdevice.
>> cleanup_net work hangs there forever periodically printing
>> "unregister_netdevice: waiting for lo to become free. Usage count = 3"
>> and creation of any new network namespaces hangs forever.
> 
> Interestingly, this is not reproducible on net-next.

The most recent change on netns refcnt was 4ee806d51176 ("net: tcp: close
sock if net namespace is exiting") in net/net-next from 5 days ago, maybe
fixed due to that?

Re: [PATCH bpf-next v7 3/5] libbpf: add error reporting in XDP

[Daniel Borkmann]

Hi Eric,

On 01/27/2018 11:32 AM, Eric Leblond wrote:
> On Sat, 2018-01-27 at 02:28 +0100, Daniel Borkmann wrote:
>> On 01/25/2018 01:05 AM, Eric Leblond wrote:
>>> Parse netlink ext attribute to get the error message returned by
>>> the card. Code is partially take from libnl.
>>>
>>> We add netlink.h to the uapi include of tools. And we need to
>>> avoid include of userspace netlink header to have a successful
>>> build of sample so nlattr.h has a define to avoid
>>> the inclusion. Using a direct define could have been an issue
>>> as NLMSGERR_ATTR_MAX can change in the future.
>>>
>>> We also define SOL_NETLINK if not defined to avoid to have to
>>> copy socket.h for a fixed value.
>>>
>>> Signed-off-by: Eric Leblond <e...@regit.org>
>>> Acked-by: Alexei Starovoitov <a...@kernel.org>
>>>
>>> remote rtne
>>>
>>> Signed-off-by: Eric Leblond <e...@regit.org>
>>
>> Some leftover artifact from squashing commits?
> 
> Outch
> 
>>>  samples/bpf/Makefile   |   2 +-
>>>  tools/lib/bpf/Build|   2 +-
>>>  tools/lib/bpf/bpf.c|  13 +++-
>>>  tools/lib/bpf/nlattr.c | 187
>>> +
>>>  tools/lib/bpf/nlattr.h |  72 +++
>>>  5 files changed, 273 insertions(+), 3 deletions(-)
>>>  create mode 100644 tools/lib/bpf/nlattr.c
>>>  create mode 100644 tools/lib/bpf/nlattr.h
>>>
>>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>>> index 7f61a3d57fa7..5c4cd3745282 100644
>>> --- a/samples/bpf/Makefile
>>> +++ b/samples/bpf/Makefile
>>> @@ -45,7 +45,7 @@ hostprogs-y += xdp_rxq_info
>>>  hostprogs-y += syscall_tp
>>>  
>>>  # Libbpf dependencies
>>> -LIBBPF := ../../tools/lib/bpf/bpf.o
>>> +LIBBPF := ../../tools/lib/bpf/bpf.o ../../tools/lib/bpf/nlattr.o
>>>  CGROUP_HELPERS :=
>>> ../../tools/testing/selftests/bpf/cgroup_helpers.o
>>>  
>>>  test_lru_dist-objs := test_lru_dist.o $(LIBBPF)
>>> diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
>>> index d8749756352d..64c679d67109 100644
>>> --- a/tools/lib/bpf/Build
>>> +++ b/tools/lib/bpf/Build
>>> @@ -1 +1 @@
>>> -libbpf-y := libbpf.o bpf.o
>>> +libbpf-y := libbpf.o bpf.o nlattr.o
>>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>>> index 749a447ec9ed..765fd95b0657 100644
>>> --- a/tools/lib/bpf/bpf.c
>>> +++ b/tools/lib/bpf/bpf.c
>>> @@ -27,7 +27,7 @@
>>>  #include "bpf.h"
>>>  #include "libbpf.h"
>>>  #include "nlattr.h"
>>> -#include 
>>> +#include 
>>
>> Okay, so here it's put back from prior added uapi/linux/rtnetlink.h
>> into linux/rtnetlink.h. Could you add this properly in the first
>> commit rather than relative adjustment/fix within the same set?
> 
> Yes, sure.
> 
>>>  #include 
>>>  #include 
>>>  
>>> @@ -37,6 +37,10 @@
>>>  #define IFLA_XDP_FLAGS 3
>>>  #endif
>>>  
>>> +#ifndef SOL_NETLINK
>>> +#define SOL_NETLINK 270
>>> +#endif
>>
>> This would need include/linux/socket.h into tools/ include infra
>> as well, no?
> 
> Yes, and I fear a lot of dependencies.

Sorry for the delay! So, once you pull these two headers in, are there more
follow-up dependencies with other headers required on your old test system?
I'd also be fine with keeping SOL_NETLINK here as is, but I would try to
have the if_link.h in the tools/ include infra, so we have all XDP definitions
available and up to date from the lib's pov. The dependency for if_link.h
seems minimal and probably enough to to only get in this single header. Could
you give that a try?

Thanks a lot,
Daniel

Re: [PATCH bpf-next v7 3/5] libbpf: add error reporting in XDP

[Daniel Borkmann]

Hi Eric,

On 01/27/2018 11:32 AM, Eric Leblond wrote:
> On Sat, 2018-01-27 at 02:28 +0100, Daniel Borkmann wrote:
>> On 01/25/2018 01:05 AM, Eric Leblond wrote:
>>> Parse netlink ext attribute to get the error message returned by
>>> the card. Code is partially take from libnl.
>>>
>>> We add netlink.h to the uapi include of tools. And we need to
>>> avoid include of userspace netlink header to have a successful
>>> build of sample so nlattr.h has a define to avoid
>>> the inclusion. Using a direct define could have been an issue
>>> as NLMSGERR_ATTR_MAX can change in the future.
>>>
>>> We also define SOL_NETLINK if not defined to avoid to have to
>>> copy socket.h for a fixed value.
>>>
>>> Signed-off-by: Eric Leblond 
>>> Acked-by: Alexei Starovoitov 
>>>
>>> remote rtne
>>>
>>> Signed-off-by: Eric Leblond 
>>
>> Some leftover artifact from squashing commits?
> 
> Outch
> 
>>>  samples/bpf/Makefile   |   2 +-
>>>  tools/lib/bpf/Build|   2 +-
>>>  tools/lib/bpf/bpf.c|  13 +++-
>>>  tools/lib/bpf/nlattr.c | 187
>>> +
>>>  tools/lib/bpf/nlattr.h |  72 +++
>>>  5 files changed, 273 insertions(+), 3 deletions(-)
>>>  create mode 100644 tools/lib/bpf/nlattr.c
>>>  create mode 100644 tools/lib/bpf/nlattr.h
>>>
>>> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
>>> index 7f61a3d57fa7..5c4cd3745282 100644
>>> --- a/samples/bpf/Makefile
>>> +++ b/samples/bpf/Makefile
>>> @@ -45,7 +45,7 @@ hostprogs-y += xdp_rxq_info
>>>  hostprogs-y += syscall_tp
>>>  
>>>  # Libbpf dependencies
>>> -LIBBPF := ../../tools/lib/bpf/bpf.o
>>> +LIBBPF := ../../tools/lib/bpf/bpf.o ../../tools/lib/bpf/nlattr.o
>>>  CGROUP_HELPERS :=
>>> ../../tools/testing/selftests/bpf/cgroup_helpers.o
>>>  
>>>  test_lru_dist-objs := test_lru_dist.o $(LIBBPF)
>>> diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
>>> index d8749756352d..64c679d67109 100644
>>> --- a/tools/lib/bpf/Build
>>> +++ b/tools/lib/bpf/Build
>>> @@ -1 +1 @@
>>> -libbpf-y := libbpf.o bpf.o
>>> +libbpf-y := libbpf.o bpf.o nlattr.o
>>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>>> index 749a447ec9ed..765fd95b0657 100644
>>> --- a/tools/lib/bpf/bpf.c
>>> +++ b/tools/lib/bpf/bpf.c
>>> @@ -27,7 +27,7 @@
>>>  #include "bpf.h"
>>>  #include "libbpf.h"
>>>  #include "nlattr.h"
>>> -#include 
>>> +#include 
>>
>> Okay, so here it's put back from prior added uapi/linux/rtnetlink.h
>> into linux/rtnetlink.h. Could you add this properly in the first
>> commit rather than relative adjustment/fix within the same set?
> 
> Yes, sure.
> 
>>>  #include 
>>>  #include 
>>>  
>>> @@ -37,6 +37,10 @@
>>>  #define IFLA_XDP_FLAGS 3
>>>  #endif
>>>  
>>> +#ifndef SOL_NETLINK
>>> +#define SOL_NETLINK 270
>>> +#endif
>>
>> This would need include/linux/socket.h into tools/ include infra
>> as well, no?
> 
> Yes, and I fear a lot of dependencies.

Sorry for the delay! So, once you pull these two headers in, are there more
follow-up dependencies with other headers required on your old test system?
I'd also be fine with keeping SOL_NETLINK here as is, but I would try to
have the if_link.h in the tools/ include infra, so we have all XDP definitions
available and up to date from the lib's pov. The dependency for if_link.h
seems minimal and probably enough to to only get in this single header. Could
you give that a try?

Thanks a lot,
Daniel

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

[Daniel Borkmann]

On 01/29/2018 06:36 PM, Greg KH wrote:
> On Mon, Jan 29, 2018 at 04:36:35PM +0100, Daniel Borkmann wrote:
>> On 01/29/2018 12:40 AM, Daniel Borkmann wrote:
>>> On 01/28/2018 03:45 PM, Greg KH wrote:
>>>> On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
>>>>> On 01/24/2018 11:07 AM, David Woodhouse wrote:
>>>>>> On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
>>>>>>> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
>> [...]
>>>>>>> Applied to bpf tree, thanks Alexei!
>>>>>>
>>>>>> For stable too?
>>>>>
>>>>> Yes, this will go into stable as well; batch of backports will come 
>>>>> Thurs/Fri.
>>>>
>>>> Any word on these?  Worse case, a simple list of git commit ids to
>>>> backport is all I need.
>>>
>>> Sorry for the delay! There are various conflicts all over the place, so I 
>>> had
>>> to backport manually. I just flushed out tested 4.14 batch, I'll see to get 
>>> 4.9
>>> out hopefully tonight as well, and the rest for 4.4 on Mon.
>>
>> While 4.14 and 4.9 BPF backports are tested and out since yesterday, and I
>> saw Greg queued them up (thanks!), it looks like plain 4.4.113 doesn't even
>> boot on my machine. While I can shortly see the kernel log, my screen turns
>> black shortly thereafter and nothing reacts anymore. No such problems with
>> 4.9 and 4.14 stables seen. (using x86_64, i7-6600U) Is this a known issue?
> 
> Not that I know of, sorry.  Odd graphics issue perhaps?
> 
> If you have some test programs I can run, I can look into doing the
> backports, I still have a laptop around here that runs 4.4 :)
> 
> There's always a virtual machine as well, have you tried that?

I've switched to an arm64 node now, that's working fine with 4.4, so patches
will come later tonight.

Thanks,
Daniel

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

[Daniel Borkmann]

On 01/29/2018 06:36 PM, Greg KH wrote:
> On Mon, Jan 29, 2018 at 04:36:35PM +0100, Daniel Borkmann wrote:
>> On 01/29/2018 12:40 AM, Daniel Borkmann wrote:
>>> On 01/28/2018 03:45 PM, Greg KH wrote:
>>>> On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
>>>>> On 01/24/2018 11:07 AM, David Woodhouse wrote:
>>>>>> On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
>>>>>>> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
>> [...]
>>>>>>> Applied to bpf tree, thanks Alexei!
>>>>>>
>>>>>> For stable too?
>>>>>
>>>>> Yes, this will go into stable as well; batch of backports will come 
>>>>> Thurs/Fri.
>>>>
>>>> Any word on these?  Worse case, a simple list of git commit ids to
>>>> backport is all I need.
>>>
>>> Sorry for the delay! There are various conflicts all over the place, so I 
>>> had
>>> to backport manually. I just flushed out tested 4.14 batch, I'll see to get 
>>> 4.9
>>> out hopefully tonight as well, and the rest for 4.4 on Mon.
>>
>> While 4.14 and 4.9 BPF backports are tested and out since yesterday, and I
>> saw Greg queued them up (thanks!), it looks like plain 4.4.113 doesn't even
>> boot on my machine. While I can shortly see the kernel log, my screen turns
>> black shortly thereafter and nothing reacts anymore. No such problems with
>> 4.9 and 4.14 stables seen. (using x86_64, i7-6600U) Is this a known issue?
> 
> Not that I know of, sorry.  Odd graphics issue perhaps?
> 
> If you have some test programs I can run, I can look into doing the
> backports, I still have a laptop around here that runs 4.4 :)
> 
> There's always a virtual machine as well, have you tried that?

I've switched to an arm64 node now, that's working fine with 4.4, so patches
will come later tonight.

Thanks,
Daniel

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

[Daniel Borkmann]

On 01/29/2018 12:40 AM, Daniel Borkmann wrote:
> On 01/28/2018 03:45 PM, Greg KH wrote:
>> On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
>>> On 01/24/2018 11:07 AM, David Woodhouse wrote:
>>>> On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
>>>>> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
[...]
>>>>> Applied to bpf tree, thanks Alexei!
>>>>
>>>> For stable too?
>>>
>>> Yes, this will go into stable as well; batch of backports will come 
>>> Thurs/Fri.
>>
>> Any word on these?  Worse case, a simple list of git commit ids to
>> backport is all I need.
> 
> Sorry for the delay! There are various conflicts all over the place, so I had
> to backport manually. I just flushed out tested 4.14 batch, I'll see to get 
> 4.9
> out hopefully tonight as well, and the rest for 4.4 on Mon.

While 4.14 and 4.9 BPF backports are tested and out since yesterday, and I
saw Greg queued them up (thanks!), it looks like plain 4.4.113 doesn't even
boot on my machine. While I can shortly see the kernel log, my screen turns
black shortly thereafter and nothing reacts anymore. No such problems with
4.9 and 4.14 stables seen. (using x86_64, i7-6600U) Is this a known issue?

Thanks,
Daniel

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

[Daniel Borkmann]

On 01/29/2018 12:40 AM, Daniel Borkmann wrote:
> On 01/28/2018 03:45 PM, Greg KH wrote:
>> On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
>>> On 01/24/2018 11:07 AM, David Woodhouse wrote:
>>>> On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
>>>>> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
[...]
>>>>> Applied to bpf tree, thanks Alexei!
>>>>
>>>> For stable too?
>>>
>>> Yes, this will go into stable as well; batch of backports will come 
>>> Thurs/Fri.
>>
>> Any word on these?  Worse case, a simple list of git commit ids to
>> backport is all I need.
> 
> Sorry for the delay! There are various conflicts all over the place, so I had
> to backport manually. I just flushed out tested 4.14 batch, I'll see to get 
> 4.9
> out hopefully tonight as well, and the rest for 4.4 on Mon.

While 4.14 and 4.9 BPF backports are tested and out since yesterday, and I
saw Greg queued them up (thanks!), it looks like plain 4.4.113 doesn't even
boot on my machine. While I can shortly see the kernel log, my screen turns
black shortly thereafter and nothing reacts anymore. No such problems with
4.9 and 4.14 stables seen. (using x86_64, i7-6600U) Is this a known issue?

Thanks,
Daniel

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

[Daniel Borkmann]

On 01/28/2018 03:45 PM, Greg KH wrote:
> On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
>> On 01/24/2018 11:07 AM, David Woodhouse wrote:
>>> On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
>>>> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
>>>>>
>>>>> The BPF interpreter has been used as part of the spectre 2 attack 
>>>>> CVE-2017-5715.
>>>>>
>>>>> A quote from goolge project zero blog:
>>>>> "At this point, it would normally be necessary to locate gadgets in
>>>>> the host kernel code that can be used to actually leak data by reading
>>>>> from an attacker-controlled location, shifting and masking the result
>>>>> appropriately and then using the result of that as offset to an
>>>>> attacker-controlled address for a load. But piecing gadgets together
>>>>> and figuring out which ones work in a speculation context seems annoying.
>>>>> So instead, we decided to use the eBPF interpreter, which is built into
>>>>> the host kernel - while there is no legitimate way to invoke it from 
>>>>> inside
>>>>> a VM, the presence of the code in the host kernel's text section is 
>>>>> sufficient
>>>>> to make it usable for the attack, just like with ordinary ROP gadgets."
>>>>>
>>>>> To make attacker job harder introduce BPF_JIT_ALWAYS_ON config
>>>>> option that removes interpreter from the kernel in favor of JIT-only mode.
>>>>> So far eBPF JIT is supported by:
>>>>> x64, arm64, arm32, sparc64, s390, powerpc64, mips64
>>>>>
>>>>> The start of JITed program is randomized and code page is marked as 
>>>>> read-only.
>>>>> In addition "constant blinding" can be turned on with 
>>>>> net.core.bpf_jit_harden
>>>>>
>>>>> v2->v3:
>>>>> - move __bpf_prog_ret0 under ifdef (Daniel)
>>>>>
>>>>> v1->v2:
>>>>> - fix init order, test_bpf and cBPF (Daniel's feedback)
>>>>> - fix offloaded bpf (Jakub's feedback)
>>>>> - add 'return 0' dummy in case something can invoke prog->bpf_func
>>>>> - retarget bpf tree. For bpf-next the patch would need one extra hunk.
>>>>>   It will be sent when the trees are merged back to net-next
>>>>>
>>>>> Considered doing:
>>>>>   int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT;
>>>>> but it seems better to land the patch as-is and in bpf-next remove
>>>>> bpf_jit_enable global variable from all JITs, consolidate in one place
>>>>> and remove this jit_init() function.
>>>>>
>>>>> Signed-off-by: Alexei Starovoitov <a...@kernel.org>
>>>>
>>>> Applied to bpf tree, thanks Alexei!
>>>
>>> For stable too?
>>
>> Yes, this will go into stable as well; batch of backports will come 
>> Thurs/Fri.
> 
> Any word on these?  Worse case, a simple list of git commit ids to
> backport is all I need.

Sorry for the delay! There are various conflicts all over the place, so I had
to backport manually. I just flushed out tested 4.14 batch, I'll see to get 4.9
out hopefully tonight as well, and the rest for 4.4 on Mon.

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

[Daniel Borkmann]

On 01/28/2018 03:45 PM, Greg KH wrote:
> On Wed, Jan 24, 2018 at 11:10:50AM +0100, Daniel Borkmann wrote:
>> On 01/24/2018 11:07 AM, David Woodhouse wrote:
>>> On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
>>>> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
>>>>>
>>>>> The BPF interpreter has been used as part of the spectre 2 attack 
>>>>> CVE-2017-5715.
>>>>>
>>>>> A quote from goolge project zero blog:
>>>>> "At this point, it would normally be necessary to locate gadgets in
>>>>> the host kernel code that can be used to actually leak data by reading
>>>>> from an attacker-controlled location, shifting and masking the result
>>>>> appropriately and then using the result of that as offset to an
>>>>> attacker-controlled address for a load. But piecing gadgets together
>>>>> and figuring out which ones work in a speculation context seems annoying.
>>>>> So instead, we decided to use the eBPF interpreter, which is built into
>>>>> the host kernel - while there is no legitimate way to invoke it from 
>>>>> inside
>>>>> a VM, the presence of the code in the host kernel's text section is 
>>>>> sufficient
>>>>> to make it usable for the attack, just like with ordinary ROP gadgets."
>>>>>
>>>>> To make attacker job harder introduce BPF_JIT_ALWAYS_ON config
>>>>> option that removes interpreter from the kernel in favor of JIT-only mode.
>>>>> So far eBPF JIT is supported by:
>>>>> x64, arm64, arm32, sparc64, s390, powerpc64, mips64
>>>>>
>>>>> The start of JITed program is randomized and code page is marked as 
>>>>> read-only.
>>>>> In addition "constant blinding" can be turned on with 
>>>>> net.core.bpf_jit_harden
>>>>>
>>>>> v2->v3:
>>>>> - move __bpf_prog_ret0 under ifdef (Daniel)
>>>>>
>>>>> v1->v2:
>>>>> - fix init order, test_bpf and cBPF (Daniel's feedback)
>>>>> - fix offloaded bpf (Jakub's feedback)
>>>>> - add 'return 0' dummy in case something can invoke prog->bpf_func
>>>>> - retarget bpf tree. For bpf-next the patch would need one extra hunk.
>>>>>   It will be sent when the trees are merged back to net-next
>>>>>
>>>>> Considered doing:
>>>>>   int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT;
>>>>> but it seems better to land the patch as-is and in bpf-next remove
>>>>> bpf_jit_enable global variable from all JITs, consolidate in one place
>>>>> and remove this jit_init() function.
>>>>>
>>>>> Signed-off-by: Alexei Starovoitov 
>>>>
>>>> Applied to bpf tree, thanks Alexei!
>>>
>>> For stable too?
>>
>> Yes, this will go into stable as well; batch of backports will come 
>> Thurs/Fri.
> 
> Any word on these?  Worse case, a simple list of git commit ids to
> backport is all I need.

Sorry for the delay! There are various conflicts all over the place, so I had
to backport manually. I just flushed out tested 4.14 batch, I'll see to get 4.9
out hopefully tonight as well, and the rest for 4.4 on Mon.

Re: [PATCH bpf-next v7 3/5] libbpf: add error reporting in XDP

[Daniel Borkmann]

On 01/25/2018 01:05 AM, Eric Leblond wrote:
> Parse netlink ext attribute to get the error message returned by
> the card. Code is partially take from libnl.
> 
> We add netlink.h to the uapi include of tools. And we need to
> avoid include of userspace netlink header to have a successful
> build of sample so nlattr.h has a define to avoid
> the inclusion. Using a direct define could have been an issue
> as NLMSGERR_ATTR_MAX can change in the future.
> 
> We also define SOL_NETLINK if not defined to avoid to have to
> copy socket.h for a fixed value.
> 
> Signed-off-by: Eric Leblond 
> Acked-by: Alexei Starovoitov 
> 
> remote rtne
> 
> Signed-off-by: Eric Leblond 

Some leftover artifact from squashing commits?

>  samples/bpf/Makefile   |   2 +-
>  tools/lib/bpf/Build|   2 +-
>  tools/lib/bpf/bpf.c|  13 +++-
>  tools/lib/bpf/nlattr.c | 187 
> +
>  tools/lib/bpf/nlattr.h |  72 +++
>  5 files changed, 273 insertions(+), 3 deletions(-)
>  create mode 100644 tools/lib/bpf/nlattr.c
>  create mode 100644 tools/lib/bpf/nlattr.h
> 
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 7f61a3d57fa7..5c4cd3745282 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -45,7 +45,7 @@ hostprogs-y += xdp_rxq_info
>  hostprogs-y += syscall_tp
>  
>  # Libbpf dependencies
> -LIBBPF := ../../tools/lib/bpf/bpf.o
> +LIBBPF := ../../tools/lib/bpf/bpf.o ../../tools/lib/bpf/nlattr.o
>  CGROUP_HELPERS := ../../tools/testing/selftests/bpf/cgroup_helpers.o
>  
>  test_lru_dist-objs := test_lru_dist.o $(LIBBPF)
> diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
> index d8749756352d..64c679d67109 100644
> --- a/tools/lib/bpf/Build
> +++ b/tools/lib/bpf/Build
> @@ -1 +1 @@
> -libbpf-y := libbpf.o bpf.o
> +libbpf-y := libbpf.o bpf.o nlattr.o
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 749a447ec9ed..765fd95b0657 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -27,7 +27,7 @@
>  #include "bpf.h"
>  #include "libbpf.h"
>  #include "nlattr.h"
> -#include 
> +#include 

Okay, so here it's put back from prior added uapi/linux/rtnetlink.h
into linux/rtnetlink.h. Could you add this properly in the first
commit rather than relative adjustment/fix within the same set?

>  #include 
>  #include 
>  
> @@ -37,6 +37,10 @@
>  #define IFLA_XDP_FLAGS   3
>  #endif
>  
> +#ifndef SOL_NETLINK
> +#define SOL_NETLINK 270
> +#endif

This would need include/linux/socket.h into tools/ include infra
as well, no?

>  /*
>   * When building perf, unistd.h is overridden. __NR_bpf is
>   * required to be defined explicitly.
> @@ -441,6 +445,7 @@ int bpf_set_link_xdp_fd(int ifindex, int fd, __u32 flags)
>   struct nlmsghdr *nh;
>   struct nlmsgerr *err;
>   socklen_t addrlen;

Re: [PATCH bpf-next v7 3/5] libbpf: add error reporting in XDP

[Daniel Borkmann]

On 01/25/2018 01:05 AM, Eric Leblond wrote:
> Parse netlink ext attribute to get the error message returned by
> the card. Code is partially take from libnl.
> 
> We add netlink.h to the uapi include of tools. And we need to
> avoid include of userspace netlink header to have a successful
> build of sample so nlattr.h has a define to avoid
> the inclusion. Using a direct define could have been an issue
> as NLMSGERR_ATTR_MAX can change in the future.
> 
> We also define SOL_NETLINK if not defined to avoid to have to
> copy socket.h for a fixed value.
> 
> Signed-off-by: Eric Leblond 
> Acked-by: Alexei Starovoitov 
> 
> remote rtne
> 
> Signed-off-by: Eric Leblond 

Some leftover artifact from squashing commits?

>  samples/bpf/Makefile   |   2 +-
>  tools/lib/bpf/Build|   2 +-
>  tools/lib/bpf/bpf.c|  13 +++-
>  tools/lib/bpf/nlattr.c | 187 
> +
>  tools/lib/bpf/nlattr.h |  72 +++
>  5 files changed, 273 insertions(+), 3 deletions(-)
>  create mode 100644 tools/lib/bpf/nlattr.c
>  create mode 100644 tools/lib/bpf/nlattr.h
> 
> diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
> index 7f61a3d57fa7..5c4cd3745282 100644
> --- a/samples/bpf/Makefile
> +++ b/samples/bpf/Makefile
> @@ -45,7 +45,7 @@ hostprogs-y += xdp_rxq_info
>  hostprogs-y += syscall_tp
>  
>  # Libbpf dependencies
> -LIBBPF := ../../tools/lib/bpf/bpf.o
> +LIBBPF := ../../tools/lib/bpf/bpf.o ../../tools/lib/bpf/nlattr.o
>  CGROUP_HELPERS := ../../tools/testing/selftests/bpf/cgroup_helpers.o
>  
>  test_lru_dist-objs := test_lru_dist.o $(LIBBPF)
> diff --git a/tools/lib/bpf/Build b/tools/lib/bpf/Build
> index d8749756352d..64c679d67109 100644
> --- a/tools/lib/bpf/Build
> +++ b/tools/lib/bpf/Build
> @@ -1 +1 @@
> -libbpf-y := libbpf.o bpf.o
> +libbpf-y := libbpf.o bpf.o nlattr.o
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 749a447ec9ed..765fd95b0657 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -27,7 +27,7 @@
>  #include "bpf.h"
>  #include "libbpf.h"
>  #include "nlattr.h"
> -#include 
> +#include 

Okay, so here it's put back from prior added uapi/linux/rtnetlink.h
into linux/rtnetlink.h. Could you add this properly in the first
commit rather than relative adjustment/fix within the same set?

>  #include 
>  #include 
>  
> @@ -37,6 +37,10 @@
>  #define IFLA_XDP_FLAGS   3
>  #endif
>  
> +#ifndef SOL_NETLINK
> +#define SOL_NETLINK 270
> +#endif

This would need include/linux/socket.h into tools/ include infra
as well, no?

>  /*
>   * When building perf, unistd.h is overridden. __NR_bpf is
>   * required to be defined explicitly.
> @@ -441,6 +445,7 @@ int bpf_set_link_xdp_fd(int ifindex, int fd, __u32 flags)
>   struct nlmsghdr *nh;
>   struct nlmsgerr *err;
>   socklen_t addrlen;

Re: [PATCH bpf-next v7 2/5] libbpf: add function to setup XDP

[Daniel Borkmann]

On 01/25/2018 01:05 AM, Eric Leblond wrote:
> Most of the code is taken from set_link_xdp_fd() in bpf_load.c and
> slightly modified to be library compliant.
> 
> Signed-off-by: Eric Leblond 
> Acked-by: Alexei Starovoitov 
> ---
>  tools/lib/bpf/bpf.c| 127 
> +
>  tools/lib/bpf/libbpf.c |   2 +
>  tools/lib/bpf/libbpf.h |   4 ++
>  3 files changed, 133 insertions(+)
> 
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 5128677e4117..749a447ec9ed 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -25,6 +25,17 @@
>  #include 
>  #include 
>  #include "bpf.h"
> +#include "libbpf.h"
> +#include "nlattr.h"
> +#include 

Doesn't libbpf pull in already -I$(srctree)/tools/include/uapi? Seems the
other headers don't need 'uapi/' path prefix.

> +#include 
> +#include 
> +
> +#ifndef IFLA_XDP_MAX
> +#define IFLA_XDP 43
> +#define IFLA_XDP_FD  1
> +#define IFLA_XDP_FLAGS   3
> +#endif

Hm, given we pull in tools/include/uapi/linux/netlink.h, shouldn't we also
get include/uapi/linux/if_link.h dependency in here, so above ifdef workaround
can be avoided?

>  /*
>   * When building perf, unistd.h is overridden. __NR_bpf is
> @@ -46,7 +57,9 @@
>  # endif
>  #endif
>  
> +#ifndef min
>  #define min(x, y) ((x) < (y) ? (x) : (y))
> +#endif
>  
>  static inline __u64 ptr_to_u64(const void *ptr)
>  {
> @@ -413,3 +426,117 @@ int bpf_obj_get_info_by_fd(int prog_fd, void *info, 
> __u32 *info_len)
>  
>   return err;
>  }
> +
> +int bpf_set_link_xdp_fd(int ifindex, int fd, __u32 flags)
> +{
> + struct sockaddr_nl sa;
> + int sock, seq = 0, len, ret = -1;
> + char buf[4096];
> + struct nlattr *nla, *nla_xdp;
> + struct {
[...]

Re: [PATCH bpf-next v7 2/5] libbpf: add function to setup XDP

[Daniel Borkmann]

On 01/25/2018 01:05 AM, Eric Leblond wrote:
> Most of the code is taken from set_link_xdp_fd() in bpf_load.c and
> slightly modified to be library compliant.
> 
> Signed-off-by: Eric Leblond 
> Acked-by: Alexei Starovoitov 
> ---
>  tools/lib/bpf/bpf.c| 127 
> +
>  tools/lib/bpf/libbpf.c |   2 +
>  tools/lib/bpf/libbpf.h |   4 ++
>  3 files changed, 133 insertions(+)
> 
> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
> index 5128677e4117..749a447ec9ed 100644
> --- a/tools/lib/bpf/bpf.c
> +++ b/tools/lib/bpf/bpf.c
> @@ -25,6 +25,17 @@
>  #include 
>  #include 
>  #include "bpf.h"
> +#include "libbpf.h"
> +#include "nlattr.h"
> +#include 

Doesn't libbpf pull in already -I$(srctree)/tools/include/uapi? Seems the
other headers don't need 'uapi/' path prefix.

> +#include 
> +#include 
> +
> +#ifndef IFLA_XDP_MAX
> +#define IFLA_XDP 43
> +#define IFLA_XDP_FD  1
> +#define IFLA_XDP_FLAGS   3
> +#endif

Hm, given we pull in tools/include/uapi/linux/netlink.h, shouldn't we also
get include/uapi/linux/if_link.h dependency in here, so above ifdef workaround
can be avoided?

>  /*
>   * When building perf, unistd.h is overridden. __NR_bpf is
> @@ -46,7 +57,9 @@
>  # endif
>  #endif
>  
> +#ifndef min
>  #define min(x, y) ((x) < (y) ? (x) : (y))
> +#endif
>  
>  static inline __u64 ptr_to_u64(const void *ptr)
>  {
> @@ -413,3 +426,117 @@ int bpf_obj_get_info_by_fd(int prog_fd, void *info, 
> __u32 *info_len)
>  
>   return err;
>  }
> +
> +int bpf_set_link_xdp_fd(int ifindex, int fd, __u32 flags)
> +{
> + struct sockaddr_nl sa;
> + int sock, seq = 0, len, ret = -1;
> + char buf[4096];
> + struct nlattr *nla, *nla_xdp;
> + struct {
[...]

Re: [PATCH net-next v1] samples/bpf: Partially fixes the bpf.o build

[Daniel Borkmann]

On 01/26/2018 09:30 AM, Mickaël Salaün wrote:
> On 26/01/2018 03:16, Alexei Starovoitov wrote:
>> On Fri, Jan 26, 2018 at 01:39:30AM +0100, Mickaël Salaün wrote:
>>> Do not build lib/bpf/bpf.o with this Makefile but use the one from the
>>> library directory.  This avoid making a buggy bpf.o file (e.g. missing
>>> symbols).
>>
>> could you provide an example?
>> What symbols will be missing?
>> I don't think there is an issue with existing Makefile.
> 
> You can run this commands:
> make -C samples/bpf; nm tools/lib/bpf/bpf.o > a; make -C tools/lib/bpf;
> nm tools/lib/bpf/bpf.o > b; diff -u a b
> 
> Symbols like bzero and sys_bpf are missing with the samples/bpf
> Makefile, which makes the bpf.o shrink from 25K to 7K.

I've applied it to bpf-next, thanks Mickaël!

Re: [PATCH net-next v1] samples/bpf: Partially fixes the bpf.o build

[Daniel Borkmann]

On 01/26/2018 09:30 AM, Mickaël Salaün wrote:
> On 26/01/2018 03:16, Alexei Starovoitov wrote:
>> On Fri, Jan 26, 2018 at 01:39:30AM +0100, Mickaël Salaün wrote:
>>> Do not build lib/bpf/bpf.o with this Makefile but use the one from the
>>> library directory.  This avoid making a buggy bpf.o file (e.g. missing
>>> symbols).
>>
>> could you provide an example?
>> What symbols will be missing?
>> I don't think there is an issue with existing Makefile.
> 
> You can run this commands:
> make -C samples/bpf; nm tools/lib/bpf/bpf.o > a; make -C tools/lib/bpf;
> nm tools/lib/bpf/bpf.o > b; diff -u a b
> 
> Symbols like bzero and sys_bpf are missing with the samples/bpf
> Makefile, which makes the bpf.o shrink from 25K to 7K.

I've applied it to bpf-next, thanks Mickaël!

Re: [PATCH] bpf, doc: Correct one wrong value in "Register value tracking"

[Daniel Borkmann]

On 01/24/2018 08:48 AM, Wang YanQing wrote:
> If we then OR this with 0x40, then the value of 6th bit (0th is first bit)
> become known, so the right mask is 0xbf instead of 0xcf.
> 
> Signed-off-by: Wang YanQing 

Applied to bpf-next, thanks Wang!

Re: [PATCH] bpf, doc: Correct one wrong value in "Register value tracking"

[Daniel Borkmann]

On 01/24/2018 08:48 AM, Wang YanQing wrote:
> If we then OR this with 0x40, then the value of 6th bit (0th is first bit)
> become known, so the right mask is 0xbf instead of 0xcf.
> 
> Signed-off-by: Wang YanQing 

Applied to bpf-next, thanks Wang!

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

[Daniel Borkmann]

On 01/24/2018 11:07 AM, David Woodhouse wrote:
> On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
>> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
>>>
>>> The BPF interpreter has been used as part of the spectre 2 attack 
>>> CVE-2017-5715.
>>>
>>> A quote from goolge project zero blog:
>>> "At this point, it would normally be necessary to locate gadgets in
>>> the host kernel code that can be used to actually leak data by reading
>>> from an attacker-controlled location, shifting and masking the result
>>> appropriately and then using the result of that as offset to an
>>> attacker-controlled address for a load. But piecing gadgets together
>>> and figuring out which ones work in a speculation context seems annoying.
>>> So instead, we decided to use the eBPF interpreter, which is built into
>>> the host kernel - while there is no legitimate way to invoke it from inside
>>> a VM, the presence of the code in the host kernel's text section is 
>>> sufficient
>>> to make it usable for the attack, just like with ordinary ROP gadgets."
>>>
>>> To make attacker job harder introduce BPF_JIT_ALWAYS_ON config
>>> option that removes interpreter from the kernel in favor of JIT-only mode.
>>> So far eBPF JIT is supported by:
>>> x64, arm64, arm32, sparc64, s390, powerpc64, mips64
>>>
>>> The start of JITed program is randomized and code page is marked as 
>>> read-only.
>>> In addition "constant blinding" can be turned on with 
>>> net.core.bpf_jit_harden
>>>
>>> v2->v3:
>>> - move __bpf_prog_ret0 under ifdef (Daniel)
>>>
>>> v1->v2:
>>> - fix init order, test_bpf and cBPF (Daniel's feedback)
>>> - fix offloaded bpf (Jakub's feedback)
>>> - add 'return 0' dummy in case something can invoke prog->bpf_func
>>> - retarget bpf tree. For bpf-next the patch would need one extra hunk.
>>>   It will be sent when the trees are merged back to net-next
>>>
>>> Considered doing:
>>>   int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT;
>>> but it seems better to land the patch as-is and in bpf-next remove
>>> bpf_jit_enable global variable from all JITs, consolidate in one place
>>> and remove this jit_init() function.
>>>
>>> Signed-off-by: Alexei Starovoitov <a...@kernel.org>
>>
>> Applied to bpf tree, thanks Alexei!
> 
> For stable too?

Yes, this will go into stable as well; batch of backports will come Thurs/Fri.

Re: [PATCH v3 bpf] bpf: introduce BPF_JIT_ALWAYS_ON config

[Daniel Borkmann]

On 01/24/2018 11:07 AM, David Woodhouse wrote:
> On Tue, 2018-01-09 at 22:39 +0100, Daniel Borkmann wrote:
>> On 01/09/2018 07:04 PM, Alexei Starovoitov wrote:
>>>
>>> The BPF interpreter has been used as part of the spectre 2 attack 
>>> CVE-2017-5715.
>>>
>>> A quote from goolge project zero blog:
>>> "At this point, it would normally be necessary to locate gadgets in
>>> the host kernel code that can be used to actually leak data by reading
>>> from an attacker-controlled location, shifting and masking the result
>>> appropriately and then using the result of that as offset to an
>>> attacker-controlled address for a load. But piecing gadgets together
>>> and figuring out which ones work in a speculation context seems annoying.
>>> So instead, we decided to use the eBPF interpreter, which is built into
>>> the host kernel - while there is no legitimate way to invoke it from inside
>>> a VM, the presence of the code in the host kernel's text section is 
>>> sufficient
>>> to make it usable for the attack, just like with ordinary ROP gadgets."
>>>
>>> To make attacker job harder introduce BPF_JIT_ALWAYS_ON config
>>> option that removes interpreter from the kernel in favor of JIT-only mode.
>>> So far eBPF JIT is supported by:
>>> x64, arm64, arm32, sparc64, s390, powerpc64, mips64
>>>
>>> The start of JITed program is randomized and code page is marked as 
>>> read-only.
>>> In addition "constant blinding" can be turned on with 
>>> net.core.bpf_jit_harden
>>>
>>> v2->v3:
>>> - move __bpf_prog_ret0 under ifdef (Daniel)
>>>
>>> v1->v2:
>>> - fix init order, test_bpf and cBPF (Daniel's feedback)
>>> - fix offloaded bpf (Jakub's feedback)
>>> - add 'return 0' dummy in case something can invoke prog->bpf_func
>>> - retarget bpf tree. For bpf-next the patch would need one extra hunk.
>>>   It will be sent when the trees are merged back to net-next
>>>
>>> Considered doing:
>>>   int bpf_jit_enable __read_mostly = BPF_EBPF_JIT_DEFAULT;
>>> but it seems better to land the patch as-is and in bpf-next remove
>>> bpf_jit_enable global variable from all JITs, consolidate in one place
>>> and remove this jit_init() function.
>>>
>>> Signed-off-by: Alexei Starovoitov 
>>
>> Applied to bpf tree, thanks Alexei!
> 
> For stable too?

Yes, this will go into stable as well; batch of backports will come Thurs/Fri.

Re: [PATCH bpf-next 0/4] libbpf: add XDP binding support

[Daniel Borkmann]

On 01/20/2018 09:28 AM, Éric Leblond wrote:
> Hi,
> 
> Le 20 janv. 2018 9:21 AM, Daniel Borkmann <dan...@iogearbox.net> a écrit :
> 
> On 01/20/2018 03:27 AM, Alexei Starovoitov wrote:
>  > On Sat, Jan 20, 2018 at 03:00:37AM +0100, Daniel Borkmann wrote:
>  >> On 01/19/2018 12:43 AM, Eric Leblond wrote:
>  >>> Hello,
>  >>>
>  >>> This patchset rebases the libbpf code on latest bpf-next code and
> addresses
>  >>> remarks by Daniel.
>  >>
>  >> Ok, I think it's a good start. We should later on clean up the
>  >> netlink handling code a bit, but that's all internal and can be
>  >> done in a second step. Applied to bpf-next, thanks Eric.
>  >
>  > Sorry, Eric, Daniel.
>  > I had to revert this patch set. It breaks build on systems
>  > where headers are not the most recent.
> 
> Oops, sorry.
> 
>  > Since libbpf is used by perf it has to be built cleanly on centos7 at 
> least.
>  >
>  > The errors I got:
>  > bpf.c: In function ‘bpf_set_link_xdp_fd’:
>  > bpf.c:456:23: error: ‘SOL_NETLINK’ undeclared (first use in this 
> function)
>  >   if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
>  >^~~
>  > bpf.c:456:23: note: each undeclared identifier is reported only once 
> for
> each function it appears in
>  > bpf.c:456:36: error: ‘NETLINK_EXT_ACK’ undeclared (first use in this
> function)
>  >   if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
>  > ^~~
>  > nlattr.c: In function ‘nla_dump_errormsg’:
>  > nlattr.c:152:34: error: ‘NLMSGERR_ATTR_MAX’ undeclared (first use in 
> this
> function)
>  >   struct nla_policy extack_policy[NLMSGERR_ATTR_MAX + 1] = {
> 
> Yeah, fully agree, thanks for catching this, Alexei!
> 
> What's the recommended solution here ? Include some kernel tree files or 
> define 
> constant if not defined ?

I think typical way is to pull such headers into tools/include/.

Cheers,
Daniel

Re: [PATCH bpf-next 0/4] libbpf: add XDP binding support

[Daniel Borkmann]

On 01/20/2018 09:28 AM, Éric Leblond wrote:
> Hi,
> 
> Le 20 janv. 2018 9:21 AM, Daniel Borkmann  a écrit :
> 
> On 01/20/2018 03:27 AM, Alexei Starovoitov wrote:
>  > On Sat, Jan 20, 2018 at 03:00:37AM +0100, Daniel Borkmann wrote:
>  >> On 01/19/2018 12:43 AM, Eric Leblond wrote:
>  >>> Hello,
>  >>>
>  >>> This patchset rebases the libbpf code on latest bpf-next code and
> addresses
>  >>> remarks by Daniel.
>  >>
>  >> Ok, I think it's a good start. We should later on clean up the
>  >> netlink handling code a bit, but that's all internal and can be
>  >> done in a second step. Applied to bpf-next, thanks Eric.
>  >
>  > Sorry, Eric, Daniel.
>  > I had to revert this patch set. It breaks build on systems
>  > where headers are not the most recent.
> 
> Oops, sorry.
> 
>  > Since libbpf is used by perf it has to be built cleanly on centos7 at 
> least.
>  >
>  > The errors I got:
>  > bpf.c: In function ‘bpf_set_link_xdp_fd’:
>  > bpf.c:456:23: error: ‘SOL_NETLINK’ undeclared (first use in this 
> function)
>  >   if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
>  >^~~
>  > bpf.c:456:23: note: each undeclared identifier is reported only once 
> for
> each function it appears in
>  > bpf.c:456:36: error: ‘NETLINK_EXT_ACK’ undeclared (first use in this
> function)
>  >   if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
>  > ^~~
>  > nlattr.c: In function ‘nla_dump_errormsg’:
>  > nlattr.c:152:34: error: ‘NLMSGERR_ATTR_MAX’ undeclared (first use in 
> this
> function)
>  >   struct nla_policy extack_policy[NLMSGERR_ATTR_MAX + 1] = {
> 
> Yeah, fully agree, thanks for catching this, Alexei!
> 
> What's the recommended solution here ? Include some kernel tree files or 
> define 
> constant if not defined ?

I think typical way is to pull such headers into tools/include/.

Cheers,
Daniel

Re: [PATCH bpf-next 0/4] libbpf: add XDP binding support

[Daniel Borkmann]

On 01/20/2018 03:27 AM, Alexei Starovoitov wrote:
> On Sat, Jan 20, 2018 at 03:00:37AM +0100, Daniel Borkmann wrote:
>> On 01/19/2018 12:43 AM, Eric Leblond wrote:
>>> Hello,
>>>
>>> This patchset rebases the libbpf code on latest bpf-next code and addresses
>>> remarks by Daniel.
>>
>> Ok, I think it's a good start. We should later on clean up the
>> netlink handling code a bit, but that's all internal and can be
>> done in a second step. Applied to bpf-next, thanks Eric.
> 
> Sorry, Eric, Daniel.
> I had to revert this patch set. It breaks build on systems
> where headers are not the most recent.
> 
> Since libbpf is used by perf it has to be built cleanly on centos7 at least.
> 
> The errors I got:
> bpf.c: In function ‘bpf_set_link_xdp_fd’:
> bpf.c:456:23: error: ‘SOL_NETLINK’ undeclared (first use in this function)
>   if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
>^~~
> bpf.c:456:23: note: each undeclared identifier is reported only once for each 
> function it appears in
> bpf.c:456:36: error: ‘NETLINK_EXT_ACK’ undeclared (first use in this function)
>   if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
> ^~~
> nlattr.c: In function ‘nla_dump_errormsg’:
> nlattr.c:152:34: error: ‘NLMSGERR_ATTR_MAX’ undeclared (first use in this 
> function)
>   struct nla_policy extack_policy[NLMSGERR_ATTR_MAX + 1] = {

Yeah, fully agree, thanks for catching this, Alexei!

Re: [PATCH bpf-next 0/4] libbpf: add XDP binding support

[Daniel Borkmann]

On 01/20/2018 03:27 AM, Alexei Starovoitov wrote:
> On Sat, Jan 20, 2018 at 03:00:37AM +0100, Daniel Borkmann wrote:
>> On 01/19/2018 12:43 AM, Eric Leblond wrote:
>>> Hello,
>>>
>>> This patchset rebases the libbpf code on latest bpf-next code and addresses
>>> remarks by Daniel.
>>
>> Ok, I think it's a good start. We should later on clean up the
>> netlink handling code a bit, but that's all internal and can be
>> done in a second step. Applied to bpf-next, thanks Eric.
> 
> Sorry, Eric, Daniel.
> I had to revert this patch set. It breaks build on systems
> where headers are not the most recent.
> 
> Since libbpf is used by perf it has to be built cleanly on centos7 at least.
> 
> The errors I got:
> bpf.c: In function ‘bpf_set_link_xdp_fd’:
> bpf.c:456:23: error: ‘SOL_NETLINK’ undeclared (first use in this function)
>   if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
>^~~
> bpf.c:456:23: note: each undeclared identifier is reported only once for each 
> function it appears in
> bpf.c:456:36: error: ‘NETLINK_EXT_ACK’ undeclared (first use in this function)
>   if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
> ^~~
> nlattr.c: In function ‘nla_dump_errormsg’:
> nlattr.c:152:34: error: ‘NLMSGERR_ATTR_MAX’ undeclared (first use in this 
> function)
>   struct nla_policy extack_policy[NLMSGERR_ATTR_MAX + 1] = {

Yeah, fully agree, thanks for catching this, Alexei!

Re: [PATCH bpf-next 0/4] libbpf: add XDP binding support

[Daniel Borkmann]

On 01/19/2018 12:43 AM, Eric Leblond wrote:
> Hello,
> 
> This patchset rebases the libbpf code on latest bpf-next code and addresses
> remarks by Daniel.

Ok, I think it's a good start. We should later on clean up the
netlink handling code a bit, but that's all internal and can be
done in a second step. Applied to bpf-next, thanks Eric.

Re: [PATCH bpf-next 0/4] libbpf: add XDP binding support

[Daniel Borkmann]

On 01/19/2018 12:43 AM, Eric Leblond wrote:
> Hello,
> 
> This patchset rebases the libbpf code on latest bpf-next code and addresses
> remarks by Daniel.

Ok, I think it's a good start. We should later on clean up the
netlink handling code a bit, but that's all internal and can be
done in a second step. Applied to bpf-next, thanks Eric.

Re: [PATCH] selftests: bpf: update .gitignore with missing generated files

[Daniel Borkmann]

On 01/19/2018 01:36 AM, Shuah Khan wrote:
> Update .gitignore with missing generated files.
> 
> Signed-off-by: Shuah Khan 

Applied to bpf-next, thanks Shuah!

Re: [PATCH] selftests: bpf: update .gitignore with missing generated files

[Daniel Borkmann]

On 01/19/2018 01:36 AM, Shuah Khan wrote:
> Update .gitignore with missing generated files.
> 
> Signed-off-by: Shuah Khan 

Applied to bpf-next, thanks Shuah!

Re: [PATCH bpf-next] bpftool: recognize BPF_PROG_TYPE_CGROUP_DEVICE programs

[Daniel Borkmann]

On 01/19/2018 03:37 PM, Quentin Monnet wrote:
> 2018-01-19 14:17 UTC+ ~ Roman Gushchin <g...@fb.com>
>> On Mon, Jan 15, 2018 at 07:32:01PM +, Quentin Monnet wrote:
> 
> [...]
> 
>>> Looks good, thanks Roman!
>>> Would you mind updating the map names as well? It seems the
>>> BPF_MAP_TYPE_CPUMAP is missing from the list in map.c.
>>
>> Hello, Quentin!
>>
>>
>> Here is the patch.
>>
>>
>> Thanks!
>>
>> --
>>
>> From 16245383a894038a63cc1ad4b77629ba704aaa38 Mon Sep 17 00:00:00 2001
>> From: Roman Gushchin <g...@fb.com>
>> Date: Fri, 19 Jan 2018 14:07:38 +
>> Subject: [PATCH bpf-next] bpftool: recognize BPF_MAP_TYPE_CPUMAP maps
>>
>> Add BPF_MAP_TYPE_CPUMAP map type to the list
>> of map type recognized by bpftool and define
>> corresponding text representation.
>>
>> Signed-off-by: Roman Gushchin <g...@fb.com>
>> Cc: Quentin Monnet <quentin.mon...@netronome.com>
>> Cc: Jakub Kicinski <jakub.kicin...@netronome.com>
>> Cc: Daniel Borkmann <dan...@iogearbox.net>
>> Cc: Alexei Starovoitov <a...@kernel.org>
>> ---
>>  tools/bpf/bpftool/map.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
>> index a152c1a5c94c..f95fa67bb498 100644
>> --- a/tools/bpf/bpftool/map.c
>> +++ b/tools/bpf/bpftool/map.c
>> @@ -66,6 +66,7 @@ static const char * const map_type_name[] = {
>>  [BPF_MAP_TYPE_HASH_OF_MAPS] = "hash_of_maps",
>>  [BPF_MAP_TYPE_DEVMAP]   = "devmap",
>>  [BPF_MAP_TYPE_SOCKMAP]  = "sockmap",
>> +[BPF_MAP_TYPE_CPUMAP]   = "cpumap",
>>  };
>>  
>>  static unsigned int get_possible_cpus(void)
>>
> 
> Good, thank you!
> 
> Acked-by: Quentin Monnet <quentin.mon...@netronome.com>

Applied to bpf-next, thanks for following up Roman!

Re: [PATCH bpf-next] bpftool: recognize BPF_PROG_TYPE_CGROUP_DEVICE programs

[Daniel Borkmann]

On 01/19/2018 03:37 PM, Quentin Monnet wrote:
> 2018-01-19 14:17 UTC+ ~ Roman Gushchin 
>> On Mon, Jan 15, 2018 at 07:32:01PM +, Quentin Monnet wrote:
> 
> [...]
> 
>>> Looks good, thanks Roman!
>>> Would you mind updating the map names as well? It seems the
>>> BPF_MAP_TYPE_CPUMAP is missing from the list in map.c.
>>
>> Hello, Quentin!
>>
>>
>> Here is the patch.
>>
>>
>> Thanks!
>>
>> --
>>
>> From 16245383a894038a63cc1ad4b77629ba704aaa38 Mon Sep 17 00:00:00 2001
>> From: Roman Gushchin 
>> Date: Fri, 19 Jan 2018 14:07:38 +
>> Subject: [PATCH bpf-next] bpftool: recognize BPF_MAP_TYPE_CPUMAP maps
>>
>> Add BPF_MAP_TYPE_CPUMAP map type to the list
>> of map type recognized by bpftool and define
>> corresponding text representation.
>>
>> Signed-off-by: Roman Gushchin 
>> Cc: Quentin Monnet 
>> Cc: Jakub Kicinski 
>> Cc: Daniel Borkmann 
>> Cc: Alexei Starovoitov 
>> ---
>>  tools/bpf/bpftool/map.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/tools/bpf/bpftool/map.c b/tools/bpf/bpftool/map.c
>> index a152c1a5c94c..f95fa67bb498 100644
>> --- a/tools/bpf/bpftool/map.c
>> +++ b/tools/bpf/bpftool/map.c
>> @@ -66,6 +66,7 @@ static const char * const map_type_name[] = {
>>  [BPF_MAP_TYPE_HASH_OF_MAPS] = "hash_of_maps",
>>  [BPF_MAP_TYPE_DEVMAP]   = "devmap",
>>  [BPF_MAP_TYPE_SOCKMAP]  = "sockmap",
>> +[BPF_MAP_TYPE_CPUMAP]   = "cpumap",
>>  };
>>  
>>  static unsigned int get_possible_cpus(void)
>>
> 
> Good, thank you!
> 
> Acked-by: Quentin Monnet 

Applied to bpf-next, thanks for following up Roman!

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

[Daniel Borkmann]

On 01/18/2018 02:10 PM, Dmitry Vyukov wrote:
> On Wed, Jan 17, 2018 at 12:09 PM, Dmitry Vyukov <dvyu...@google.com> wrote:
>> On Wed, Jan 17, 2018 at 10:49 AM, Daniel Borkmann <dan...@iogearbox.net> 
>> wrote:
>>> Don't know if there's such a possibility, but it would be nice if we could
>>> target fuzzing for specific subsystems in related subtrees directly (e.g.
>>> for bpf in bpf and bpf-next trees as one example). Dmitry?
>>
>> Hi Daniel,
>>
>> It's doable.
>> Let's start with one bpf tree. Will it be bpf or bpf-next? Which one
>> contains more ongoing work? What's the exact git repo address/branch,
>> so that I don't second guess?

I'm actually thinking that bpf tree [1] would be my preferred choice.
While most of the development happens in bpf-next, after the merge
window it will all end up in bpf eventually anyway and we'd still have
~8 weeks for targeted fuzzing on that before a release goes out. The
other advantage I see on bpf tree itself would be that we'd uncover
issues from fixes that go into bpf tree earlier like the recent
max_entries overflow reports where syzkaller fired multiple times after
the commit causing it went already into Linus' tree. Meaning, we'd miss
out on that if we would choose bpf-next only, therefore my preferred
choice would be on bpf.

  [1] git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git

>> Also what syscalls it makes sense to enable there to target it at bpf
>> specifically? As far as I understand effects of bpf are far beyond the
>> bpf call and proper testing requires some sockets and other stuff. For

Yes, correct. For example, the ones in ...

  * syzbot+93c4904c5c70348a6...@syzkaller.appspotmail.com
  * syzbot+48340bb518e88849e...@syzkaller.appspotmail.com

... are a great find (!), and they all require runtime testing, so
interactions with sockets are definitely needed as well (e.g. the
SO_ATTACH_BPF and writes to trigger traffic going through). Another
option is to have a basic code template to attach to a loopback device
e.g. in a netns and have a tc clsact qdisc with cls_bpf filter
attached, so the fd would be passed to cls_bpf setup and then traffic
goes over loopback to trigger prog run. Same could be for generic XDP
as another example. Unlike socket filters this is root only though,
but it would have more functionality available to fuzz into and I
see robustness here as critically important. There's also a good
bunch of use cases available in BPF kernel selftests which is under
tools/testing/selftests/bpf/ to get a rough picture for fuzzing, but
it doesn't cover all prog types, maps etc though. But overall, I think
it's fine to first start out small and see how it goes.

>> sockets, will it be enough to enable ip/ipv6? Because if we enable all
>> of sctp/dccp/tipc/pptp/etc, it will sure will be finding lots of bugs
>> there as well. Does bpf affect incoming network packets?

Yes, see also comment above. For socket filters this definitely makes
sense as well and there were some interactions in the past in the proto
handlers that were buggy e.g. for odd historic reasons socket filters
allow to truncate skbs (back from classic BPF times), and that required
a reload of some of the prior referenced headers since underlying data
could have changed in the meantime (aka use after free) and some handlers
got that wrong, so probably makes sense to include some of the protos,
too, to cover changes there.

>> Also are there any sysctl's, command line arguments, etc that need to
>> be tuned. I know there are net.core.bpf_jit_enable/harden, but I don't
>> know what's the most relevant combination. Ideally, we test all of
>> them, but let start with one of them because it requires separate
>> instances (since the setting is global and test programs can't just
>> flip it randomly).

Right, I think the current one you set in syzkaller is fine for now.

>> Also do you want testing from root or not from root? We generally
>> don't test under root, because syzkaller comes up with legal ways to
>> shut everything down even if we try to contain it (e.g. kill init
>> somehow or shut down network using netlink). But if we limit syscall
>> surface, then root may work and allow testing staging bpf features.

If you have a chance to testing under both, root and non-root, that
would be best. non-root has a restricted set of features available,
so coverage would be increased under root, but I see both equally
important (to mention one, coming back to the max_elem overflow example
from earlier, this got only triggered for non-root).

Btw, I recently checked out the bpf API model in syzkaller and it
was all in line with latest upstream, very nice to see that!

One more thought on future work could also be to experiment with
syzkaller to have it additionally generate BPF progs 

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

[Daniel Borkmann]

On 01/18/2018 02:10 PM, Dmitry Vyukov wrote:
> On Wed, Jan 17, 2018 at 12:09 PM, Dmitry Vyukov  wrote:
>> On Wed, Jan 17, 2018 at 10:49 AM, Daniel Borkmann  
>> wrote:
>>> Don't know if there's such a possibility, but it would be nice if we could
>>> target fuzzing for specific subsystems in related subtrees directly (e.g.
>>> for bpf in bpf and bpf-next trees as one example). Dmitry?
>>
>> Hi Daniel,
>>
>> It's doable.
>> Let's start with one bpf tree. Will it be bpf or bpf-next? Which one
>> contains more ongoing work? What's the exact git repo address/branch,
>> so that I don't second guess?

I'm actually thinking that bpf tree [1] would be my preferred choice.
While most of the development happens in bpf-next, after the merge
window it will all end up in bpf eventually anyway and we'd still have
~8 weeks for targeted fuzzing on that before a release goes out. The
other advantage I see on bpf tree itself would be that we'd uncover
issues from fixes that go into bpf tree earlier like the recent
max_entries overflow reports where syzkaller fired multiple times after
the commit causing it went already into Linus' tree. Meaning, we'd miss
out on that if we would choose bpf-next only, therefore my preferred
choice would be on bpf.

  [1] git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git

>> Also what syscalls it makes sense to enable there to target it at bpf
>> specifically? As far as I understand effects of bpf are far beyond the
>> bpf call and proper testing requires some sockets and other stuff. For

Yes, correct. For example, the ones in ...

  * syzbot+93c4904c5c70348a6...@syzkaller.appspotmail.com
  * syzbot+48340bb518e88849e...@syzkaller.appspotmail.com

... are a great find (!), and they all require runtime testing, so
interactions with sockets are definitely needed as well (e.g. the
SO_ATTACH_BPF and writes to trigger traffic going through). Another
option is to have a basic code template to attach to a loopback device
e.g. in a netns and have a tc clsact qdisc with cls_bpf filter
attached, so the fd would be passed to cls_bpf setup and then traffic
goes over loopback to trigger prog run. Same could be for generic XDP
as another example. Unlike socket filters this is root only though,
but it would have more functionality available to fuzz into and I
see robustness here as critically important. There's also a good
bunch of use cases available in BPF kernel selftests which is under
tools/testing/selftests/bpf/ to get a rough picture for fuzzing, but
it doesn't cover all prog types, maps etc though. But overall, I think
it's fine to first start out small and see how it goes.

>> sockets, will it be enough to enable ip/ipv6? Because if we enable all
>> of sctp/dccp/tipc/pptp/etc, it will sure will be finding lots of bugs
>> there as well. Does bpf affect incoming network packets?

Yes, see also comment above. For socket filters this definitely makes
sense as well and there were some interactions in the past in the proto
handlers that were buggy e.g. for odd historic reasons socket filters
allow to truncate skbs (back from classic BPF times), and that required
a reload of some of the prior referenced headers since underlying data
could have changed in the meantime (aka use after free) and some handlers
got that wrong, so probably makes sense to include some of the protos,
too, to cover changes there.

>> Also are there any sysctl's, command line arguments, etc that need to
>> be tuned. I know there are net.core.bpf_jit_enable/harden, but I don't
>> know what's the most relevant combination. Ideally, we test all of
>> them, but let start with one of them because it requires separate
>> instances (since the setting is global and test programs can't just
>> flip it randomly).

Right, I think the current one you set in syzkaller is fine for now.

>> Also do you want testing from root or not from root? We generally
>> don't test under root, because syzkaller comes up with legal ways to
>> shut everything down even if we try to contain it (e.g. kill init
>> somehow or shut down network using netlink). But if we limit syscall
>> surface, then root may work and allow testing staging bpf features.

If you have a chance to testing under both, root and non-root, that
would be best. non-root has a restricted set of features available,
so coverage would be increased under root, but I see both equally
important (to mention one, coming back to the max_elem overflow example
from earlier, this got only triggered for non-root).

Btw, I recently checked out the bpf API model in syzkaller and it
was all in line with latest upstream, very nice to see that!

One more thought on future work could also be to experiment with
syzkaller to have it additionally generate BPF progs in C that it
would then try to load and pass traffic t

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

[Daniel Borkmann]

On 01/17/2018 10:32 AM, Pavel Machek wrote:
> On Fri 2018-01-12 17:58:01, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 19d28fbd306e7ae7c1acf05c3e6968b56f0d196b
> 
> What an useful way to describe kernel version.
> 
> Could we get reasonable subject line? 4.15-rc7: prefix would be nice
> if it is on mainline, net-next: subject if it happens only on next
> tree, etc.

Don't know if there's such a possibility, but it would be nice if we could
target fuzzing for specific subsystems in related subtrees directly (e.g.
for bpf in bpf and bpf-next trees as one example). Dmitry?

Anyway, thanks for all the great work on improving syzkaller!

Cheers,
Daniel

P.s.: The fixes are already in bpf tree and will go out later today for 4.15
  (and once in mainline, then for stable as well).

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

[Daniel Borkmann]

On 01/17/2018 10:32 AM, Pavel Machek wrote:
> On Fri 2018-01-12 17:58:01, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 19d28fbd306e7ae7c1acf05c3e6968b56f0d196b
> 
> What an useful way to describe kernel version.
> 
> Could we get reasonable subject line? 4.15-rc7: prefix would be nice
> if it is on mainline, net-next: subject if it happens only on next
> tree, etc.

Don't know if there's such a possibility, but it would be nice if we could
target fuzzing for specific subsystems in related subtrees directly (e.g.
for bpf in bpf and bpf-next trees as one example). Dmitry?

Anyway, thanks for all the great work on improving syzkaller!

Cheers,
Daniel

P.s.: The fixes are already in bpf tree and will go out later today for 4.15
  (and once in mainline, then for stable as well).

Re: [bpf-next PATCH 0/3] libbpf: cleanups to Makefile

[Daniel Borkmann]

On 01/17/2018 12:20 AM, Jesper Dangaard Brouer wrote:
> This patchset contains some small improvements and cleanup for
> the Makefile in tools/lib/bpf/.
> 
> It worries me that the libbpf.so shared library is not versioned, but
> it not addressed in this patchset.

Looks good; applied it to bpf-next, thanks Jesper!

Re: [bpf-next PATCH 0/3] libbpf: cleanups to Makefile

[Daniel Borkmann]

On 01/17/2018 12:20 AM, Jesper Dangaard Brouer wrote:
> This patchset contains some small improvements and cleanup for
> the Makefile in tools/lib/bpf/.
> 
> It worries me that the libbpf.so shared library is not versioned, but
> it not addressed in this patchset.

Looks good; applied it to bpf-next, thanks Jesper!

Re: [PATCH] samples/bpf: Fix trailing semicolon

[Daniel Borkmann]

On 01/16/2018 03:15 PM, Luis de Bethencourt wrote:
> The trailing semicolon is an empty statement that does no operation.
> Removing it since it doesn't do anything.
> 
> Signed-off-by: Luis de Bethencourt 

Applied to bpf-next, thanks Luis!

Re: [PATCH] samples/bpf: Fix trailing semicolon

[Daniel Borkmann]

On 01/16/2018 03:15 PM, Luis de Bethencourt wrote:
> The trailing semicolon is an empty statement that does no operation.
> Removing it since it doesn't do anything.
> 
> Signed-off-by: Luis de Bethencourt 

Applied to bpf-next, thanks Luis!

Re: [PATCH bpf-next] bpftool: recognize BPF_PROG_TYPE_CGROUP_DEVICE programs

[Daniel Borkmann]

On 01/15/2018 08:49 PM, Roman Gushchin wrote:
> On Mon, Jan 15, 2018 at 07:32:01PM +, Quentin Monnet wrote:
>> 2018-01-15 19:16 UTC+ ~ Roman Gushchin <g...@fb.com>
>>> Bpftool doesn't recognize BPF_PROG_TYPE_CGROUP_DEVICE programs,
>>> so the prog show command prints the numeric type value:
>>>
>>> $ bpftool prog show
>>> 1: type 15  name bpf_prog1  tag ac9f93dbfd6d9b74
>>> loaded_at Jan 15/07:58  uid 0
>>> xlated 96B  jited 105B  memlock 4096B
>>>
>>> This patch defines the corresponding textual representation:
>>>
>>> $ bpftool prog show
>>> 1: cgroup_device  name bpf_prog1  tag ac9f93dbfd6d9b74
>>> loaded_at Jan 15/07:58  uid 0
>>> xlated 96B  jited 105B  memlock 4096B
>>>
>>> Signed-off-by: Roman Gushchin <g...@fb.com>
>>> Cc: Jakub Kicinski <jakub.kicin...@netronome.com>
>>> Cc: Quentin Monnet <quentin.mon...@netronome.com>
>>> Cc: Daniel Borkmann <dan...@iogearbox.net>
>>> Cc: Alexei Starovoitov <a...@kernel.org>
>>> ---
>>>  tools/bpf/bpftool/prog.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
>>> index c6a28be4665c..099e21cf1b5c 100644
>>> --- a/tools/bpf/bpftool/prog.c
>>> +++ b/tools/bpf/bpftool/prog.c
>>> @@ -66,6 +66,7 @@ static const char * const prog_type_name[] = {
>>> [BPF_PROG_TYPE_LWT_XMIT]= "lwt_xmit",
>>> [BPF_PROG_TYPE_SOCK_OPS]= "sock_ops",
>>> [BPF_PROG_TYPE_SK_SKB]  = "sk_skb",
>>> +   [BPF_PROG_TYPE_CGROUP_DEVICE]   = "cgroup_device",
>>>  };
>>>  
>>>  static void print_boot_time(__u64 nsecs, char *buf, unsigned int size)
>>
>> Looks good, thanks Roman!
>> Would you mind updating the map names as well? It seems the
>> BPF_MAP_TYPE_CPUMAP is missing from the list in map.c.
> 
> Hello, Quentin!
> 
> Sure, I'll take a look.

Ok, I presume this comes in as a separate one anyway, so I've applied
this one into bpf-next already, thanks Roman!

Re: [PATCH bpf-next] bpftool: recognize BPF_PROG_TYPE_CGROUP_DEVICE programs

[Daniel Borkmann]

On 01/15/2018 08:49 PM, Roman Gushchin wrote:
> On Mon, Jan 15, 2018 at 07:32:01PM +, Quentin Monnet wrote:
>> 2018-01-15 19:16 UTC+ ~ Roman Gushchin 
>>> Bpftool doesn't recognize BPF_PROG_TYPE_CGROUP_DEVICE programs,
>>> so the prog show command prints the numeric type value:
>>>
>>> $ bpftool prog show
>>> 1: type 15  name bpf_prog1  tag ac9f93dbfd6d9b74
>>> loaded_at Jan 15/07:58  uid 0
>>> xlated 96B  jited 105B  memlock 4096B
>>>
>>> This patch defines the corresponding textual representation:
>>>
>>> $ bpftool prog show
>>> 1: cgroup_device  name bpf_prog1  tag ac9f93dbfd6d9b74
>>> loaded_at Jan 15/07:58  uid 0
>>>     xlated 96B  jited 105B  memlock 4096B
>>>
>>> Signed-off-by: Roman Gushchin 
>>> Cc: Jakub Kicinski 
>>> Cc: Quentin Monnet 
>>> Cc: Daniel Borkmann 
>>> Cc: Alexei Starovoitov 
>>> ---
>>>  tools/bpf/bpftool/prog.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
>>> index c6a28be4665c..099e21cf1b5c 100644
>>> --- a/tools/bpf/bpftool/prog.c
>>> +++ b/tools/bpf/bpftool/prog.c
>>> @@ -66,6 +66,7 @@ static const char * const prog_type_name[] = {
>>> [BPF_PROG_TYPE_LWT_XMIT]= "lwt_xmit",
>>> [BPF_PROG_TYPE_SOCK_OPS]= "sock_ops",
>>> [BPF_PROG_TYPE_SK_SKB]  = "sk_skb",
>>> +   [BPF_PROG_TYPE_CGROUP_DEVICE]   = "cgroup_device",
>>>  };
>>>  
>>>  static void print_boot_time(__u64 nsecs, char *buf, unsigned int size)
>>
>> Looks good, thanks Roman!
>> Would you mind updating the map names as well? It seems the
>> BPF_MAP_TYPE_CPUMAP is missing from the list in map.c.
> 
> Hello, Quentin!
> 
> Sure, I'll take a look.

Ok, I presume this comes in as a separate one anyway, so I've applied
this one into bpf-next already, thanks Roman!

Re: KASAN: use-after-free Write in array_map_update_elem

[Daniel Borkmann]

On 01/15/2018 04:07 PM, Dmitry Vyukov wrote:
> On Mon, Jan 15, 2018 at 3:58 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 8418f88764046d0e8ca6a3c04a69a0e57189aa1e
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+a2215ab5e92b3bb1c...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> audit: type=1400 audit(1515680378.393:8): avc:  denied  { sys_admin } for
>> pid=3508 comm="syzkaller203412" capability=21
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> audit: type=1400 audit(1515680378.446:9): avc:  denied  { sys_chroot } for
>> pid=3509 comm="syzkaller203412" capability=18
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> ==
>> BUG: KASAN: use-after-free in memcpy include/linux/string.h:344 [inline]
>> BUG: KASAN: use-after-free in array_map_update_elem+0x197/0x240
>> kernel/bpf/arraymap.c:249
>> Write of size 1 at addr 8801cb125bc0 by task syzkaller203412/3509
>>
>> CPU: 1 PID: 3509 Comm: syzkaller203412 Not tainted 4.15.0-rc7-next-20180111+
>> #94
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>>  kasan_report_error mm/kasan/report.c:354 [inline]
>>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>>  memcpy include/linux/string.h:344 [inline]
>>  array_map_update_elem+0x197/0x240 kernel/bpf/arraymap.c:249
>>  map_update_elem kernel/bpf/syscall.c:687 [inline]
>>  SYSC_bpf kernel/bpf/syscall.c:1811 [inline]
>>  SyS_bpf+0x32df/0x4400 kernel/bpf/syscall.c:1782
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>> RIP: 0033:0x440ac9
>> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
>> RAX: ffda RBX: 7ffe6a583b10 RCX: 00440ac9
>> RDX: 0020 RSI: 20eaf000 RDI: 0002
>> RBP:  R08:  R09: 
>> R10:  R11: 0203 R12: 004022a0
>> R13: 00402330 R14:  R15: 
>>
>> Allocated by task 3071:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
>>  getname_flags+0xcb/0x580 fs/namei.c:138
>>  user_path_at_empty+0x2d/0x50 fs/namei.c:2587
>>  user_path_at include/linux/namei.h:57 [inline]
>>  SYSC_faccessat fs/open.c:384 [inline]
>>  SyS_faccessat fs/open.c:353 [inline]
>>  SYSC_access fs/open.c:431 [inline]
>>  SyS_access+0x22c/0x6a0 fs/open.c:429
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> Freed by task 3071:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>>  __cache_free mm/slab.c:3485 [inline]
>>  kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
>>  putname+0xee/0x130 fs/namei.c:258
>>  filename_lookup+0x315/0x500 fs/namei.c:2342
>>  user_path_at_empty+0x40/0x50 fs/namei.c:2587
>>  user_path_at include/linux/namei.h:57 [inline]
>>  SYSC_faccessat fs/open.c:384 [inline]
>>  SyS_faccessat fs/open.c:353 [inline]
>>  SYSC_access fs/open.c:431 [inline]
>>  SyS_access+0x22c/0x6a0 fs/open.c:429
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> The buggy address belongs to the object at 8801cb124e40
>>  which belongs to the cache names_cache of size 4096
>> The buggy address is located 3456 bytes inside of
>>  4096-byte region [8801cb124e40, 8801cb125e40)
>> The buggy address belongs to the page:
>> page:ea00072c4900 count:1 mapcount:0 mapping:8801cb124e40 index:0x0
>> compound_mapcount: 0
>> flags: 0x2fffc008100(slab|head)
>> raw: 02fffc008100 8801cb124e40  00010001
>> raw: ea000729bc20 ea000729bca0 8801dae30600 
>> page 

Re: KASAN: use-after-free Write in array_map_update_elem

[Daniel Borkmann]

On 01/15/2018 04:07 PM, Dmitry Vyukov wrote:
> On Mon, Jan 15, 2018 at 3:58 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 8418f88764046d0e8ca6a3c04a69a0e57189aa1e
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+a2215ab5e92b3bb1c...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> audit: type=1400 audit(1515680378.393:8): avc:  denied  { sys_admin } for
>> pid=3508 comm="syzkaller203412" capability=21
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> audit: type=1400 audit(1515680378.446:9): avc:  denied  { sys_chroot } for
>> pid=3509 comm="syzkaller203412" capability=18
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> ==
>> BUG: KASAN: use-after-free in memcpy include/linux/string.h:344 [inline]
>> BUG: KASAN: use-after-free in array_map_update_elem+0x197/0x240
>> kernel/bpf/arraymap.c:249
>> Write of size 1 at addr 8801cb125bc0 by task syzkaller203412/3509
>>
>> CPU: 1 PID: 3509 Comm: syzkaller203412 Not tainted 4.15.0-rc7-next-20180111+
>> #94
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>>  kasan_report_error mm/kasan/report.c:354 [inline]
>>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>>  memcpy include/linux/string.h:344 [inline]
>>  array_map_update_elem+0x197/0x240 kernel/bpf/arraymap.c:249
>>  map_update_elem kernel/bpf/syscall.c:687 [inline]
>>  SYSC_bpf kernel/bpf/syscall.c:1811 [inline]
>>  SyS_bpf+0x32df/0x4400 kernel/bpf/syscall.c:1782
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>> RIP: 0033:0x440ac9
>> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
>> RAX: ffda RBX: 7ffe6a583b10 RCX: 00440ac9
>> RDX: 0020 RSI: 20eaf000 RDI: 0002
>> RBP:  R08:  R09: 
>> R10:  R11: 0203 R12: 004022a0
>> R13: 00402330 R14:  R15: 
>>
>> Allocated by task 3071:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
>>  getname_flags+0xcb/0x580 fs/namei.c:138
>>  user_path_at_empty+0x2d/0x50 fs/namei.c:2587
>>  user_path_at include/linux/namei.h:57 [inline]
>>  SYSC_faccessat fs/open.c:384 [inline]
>>  SyS_faccessat fs/open.c:353 [inline]
>>  SYSC_access fs/open.c:431 [inline]
>>  SyS_access+0x22c/0x6a0 fs/open.c:429
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> Freed by task 3071:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>>  __cache_free mm/slab.c:3485 [inline]
>>  kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
>>  putname+0xee/0x130 fs/namei.c:258
>>  filename_lookup+0x315/0x500 fs/namei.c:2342
>>  user_path_at_empty+0x40/0x50 fs/namei.c:2587
>>  user_path_at include/linux/namei.h:57 [inline]
>>  SYSC_faccessat fs/open.c:384 [inline]
>>  SyS_faccessat fs/open.c:353 [inline]
>>  SYSC_access fs/open.c:431 [inline]
>>  SyS_access+0x22c/0x6a0 fs/open.c:429
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> The buggy address belongs to the object at 8801cb124e40
>>  which belongs to the cache names_cache of size 4096
>> The buggy address is located 3456 bytes inside of
>>  4096-byte region [8801cb124e40, 8801cb125e40)
>> The buggy address belongs to the page:
>> page:ea00072c4900 count:1 mapcount:0 mapping:8801cb124e40 index:0x0
>> compound_mapcount: 0
>> flags: 0x2fffc008100(slab|head)
>> raw: 02fffc008100 8801cb124e40  00010001
>> raw: ea000729bc20 ea000729bca0 8801dae30600 
>> page dumped because: kasan: bad access detected
>>
>> Memory 

Re: KASAN: slab-out-of-bounds Write in array_map_update_elem

[Daniel Borkmann]

On 01/15/2018 04:07 PM, Dmitry Vyukov wrote:
> On Mon, Jan 15, 2018 at 3:58 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 4147d50978df60f34d444c647dde9e5b34a4315e
>> git://git.cmpxchg.org/linux-mmots.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+23dc48712d6941968...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> audit: type=1400 audit(1515679662.716:8): avc:  denied  { sys_admin } for
>> pid=3485 comm="syzkaller377846" capability=21
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> audit: type=1400 audit(1515679662.770:9): avc:  denied  { sys_chroot } for
>> pid=3486 comm="syzkaller377846" capability=18
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> ==
>> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
>> BUG: KASAN: slab-out-of-bounds in array_map_update_elem+0x197/0x240
>> kernel/bpf/arraymap.c:249
>> Write of size 1 at addr 8801cb0a3900 by task syzkaller377846/3486
>>
>> CPU: 1 PID: 3486 Comm: syzkaller377846 Not tainted 4.15.0-rc7-mm1+ #53
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>>  kasan_report_error mm/kasan/report.c:354 [inline]
>>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>>  memcpy include/linux/string.h:344 [inline]
>>  array_map_update_elem+0x197/0x240 kernel/bpf/arraymap.c:249
>>  map_update_elem kernel/bpf/syscall.c:687 [inline]
>>  SYSC_bpf kernel/bpf/syscall.c:1811 [inline]
>>  SyS_bpf+0x32df/0x4400 kernel/bpf/syscall.c:1782
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>> RIP: 0033:0x440ac9
>> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
>> RAX: ffda RBX: 7ffc88b23300 RCX: 00440ac9
>> RDX: 0020 RSI: 20eaf000 RDI: 0002
>> RBP:  R08:  R09: 
>> R10:  R11: 0203 R12: 004022a0
>> R13: 00402330 R14:  R15: 
>>
>> Allocated by task 3072:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
>>  getname_kernel+0x54/0x340 fs/namei.c:218
>>  open_exec+0x17/0x60 fs/exec.c:877
>>  load_elf_binary+0x1348/0x4c10 fs/binfmt_elf.c:780
>>  search_binary_handler+0x142/0x6b0 fs/exec.c:1639
>>  exec_binprm fs/exec.c:1681 [inline]
>>  do_execveat_common.isra.30+0x1711/0x22a0 fs/exec.c:1803
>>  do_execve fs/exec.c:1848 [inline]
>>  SYSC_execve fs/exec.c:1929 [inline]
>>  SyS_execve+0x39/0x50 fs/exec.c:1924
>>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>>  return_from_SYSCALL_64+0x0/0x75
>>
>> Freed by task 3072:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>>  __cache_free mm/slab.c:3485 [inline]
>>  kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
>>  putname+0xee/0x130 fs/namei.c:258
>>  open_exec+0x41/0x60 fs/exec.c:882
>>  load_elf_binary+0x1348/0x4c10 fs/binfmt_elf.c:780
>>  search_binary_handler+0x142/0x6b0 fs/exec.c:1639
>>  exec_binprm fs/exec.c:1681 [inline]
>>  do_execveat_common.isra.30+0x1711/0x22a0 fs/exec.c:1803
>>  do_execve fs/exec.c:1848 [inline]
>>  SYSC_execve fs/exec.c:1929 [inline]
>>  SyS_execve+0x39/0x50 fs/exec.c:1924
>>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>>  return_from_SYSCALL_64+0x0/0x75
>>
>> The buggy address belongs to the object at 8801cb0a2380
>>  which belongs to the cache names_cache of size 4096
>> The buggy address is located 1408 bytes to the right of
>>  4096-byte region [8801cb0a2380, 8801cb0a3380)
>> The buggy address belongs to the page:
>> page:ea00072c2880 count:1 mapcount:0 mapping:8801cb0a2380 

Re: KASAN: slab-out-of-bounds Write in array_map_update_elem

[Daniel Borkmann]

On 01/15/2018 04:07 PM, Dmitry Vyukov wrote:
> On Mon, Jan 15, 2018 at 3:58 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 4147d50978df60f34d444c647dde9e5b34a4315e
>> git://git.cmpxchg.org/linux-mmots.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+23dc48712d6941968...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> audit: type=1400 audit(1515679662.716:8): avc:  denied  { sys_admin } for
>> pid=3485 comm="syzkaller377846" capability=21
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> audit: type=1400 audit(1515679662.770:9): avc:  denied  { sys_chroot } for
>> pid=3486 comm="syzkaller377846" capability=18
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> ==
>> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
>> BUG: KASAN: slab-out-of-bounds in array_map_update_elem+0x197/0x240
>> kernel/bpf/arraymap.c:249
>> Write of size 1 at addr 8801cb0a3900 by task syzkaller377846/3486
>>
>> CPU: 1 PID: 3486 Comm: syzkaller377846 Not tainted 4.15.0-rc7-mm1+ #53
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>>  kasan_report_error mm/kasan/report.c:354 [inline]
>>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>>  memcpy+0x37/0x50 mm/kasan/kasan.c:303
>>  memcpy include/linux/string.h:344 [inline]
>>  array_map_update_elem+0x197/0x240 kernel/bpf/arraymap.c:249
>>  map_update_elem kernel/bpf/syscall.c:687 [inline]
>>  SYSC_bpf kernel/bpf/syscall.c:1811 [inline]
>>  SyS_bpf+0x32df/0x4400 kernel/bpf/syscall.c:1782
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>> RIP: 0033:0x440ac9
>> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
>> RAX: ffda RBX: 7ffc88b23300 RCX: 00440ac9
>> RDX: 0020 RSI: 20eaf000 RDI: 0002
>> RBP:  R08:  R09: 
>> R10:  R11: 0203 R12: 004022a0
>> R13: 00402330 R14:  R15: 
>>
>> Allocated by task 3072:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
>>  getname_kernel+0x54/0x340 fs/namei.c:218
>>  open_exec+0x17/0x60 fs/exec.c:877
>>  load_elf_binary+0x1348/0x4c10 fs/binfmt_elf.c:780
>>  search_binary_handler+0x142/0x6b0 fs/exec.c:1639
>>  exec_binprm fs/exec.c:1681 [inline]
>>  do_execveat_common.isra.30+0x1711/0x22a0 fs/exec.c:1803
>>  do_execve fs/exec.c:1848 [inline]
>>  SYSC_execve fs/exec.c:1929 [inline]
>>  SyS_execve+0x39/0x50 fs/exec.c:1924
>>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>>  return_from_SYSCALL_64+0x0/0x75
>>
>> Freed by task 3072:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>>  __cache_free mm/slab.c:3485 [inline]
>>  kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
>>  putname+0xee/0x130 fs/namei.c:258
>>  open_exec+0x41/0x60 fs/exec.c:882
>>  load_elf_binary+0x1348/0x4c10 fs/binfmt_elf.c:780
>>  search_binary_handler+0x142/0x6b0 fs/exec.c:1639
>>  exec_binprm fs/exec.c:1681 [inline]
>>  do_execveat_common.isra.30+0x1711/0x22a0 fs/exec.c:1803
>>  do_execve fs/exec.c:1848 [inline]
>>  SYSC_execve fs/exec.c:1929 [inline]
>>  SyS_execve+0x39/0x50 fs/exec.c:1924
>>  do_syscall_64+0x273/0x920 arch/x86/entry/common.c:285
>>  return_from_SYSCALL_64+0x0/0x75
>>
>> The buggy address belongs to the object at 8801cb0a2380
>>  which belongs to the cache names_cache of size 4096
>> The buggy address is located 1408 bytes to the right of
>>  4096-byte region [8801cb0a2380, 8801cb0a3380)
>> The buggy address belongs to the page:
>> page:ea00072c2880 count:1 mapcount:0 mapping:8801cb0a2380 index:0x0
>> compound_mapcount: 0
>> flags: 

Re: BUG: unable to handle kernel paging request in check_memory_region

[Daniel Borkmann]

On 01/13/2018 08:29 AM, Dmitry Vyukov wrote:
> On Fri, Jan 12, 2018 at 11:58 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> c92a9a461dff6140c539c61e457aa97df29517d6
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+32b24f3e7c9000c48...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
> 
> 
> Daniel, is it the same bug that was fixed by "bpf, array: fix overflow
> in max_entries and undefined behavior in index_mask"?

And also here, fixed by:

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1

>> audit: type=1400 audit(1515790631.378:9): avc:  denied  { sys_chroot } for
>> pid=3510 comm="syzkaller602893" capability=18
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> BUG: unable to handle kernel paging request at ed004e875e33
>> IP: bytes_is_nonzero mm/kasan/kasan.c:166 [inline]
>> IP: memory_is_nonzero mm/kasan/kasan.c:184 [inline]
>> IP: memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
>> IP: memory_is_poisoned mm/kasan/kasan.c:241 [inline]
>> IP: check_memory_region_inline mm/kasan/kasan.c:257 [inline]
>> IP: check_memory_region+0x61/0x190 mm/kasan/kasan.c:267
>> PGD 21ffee067 P4D 21ffee067 PUD 21ffec067 PMD 0
>> Oops:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 3510 Comm: syzkaller602893 Not tainted 4.15.0-rc7+ #259
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> RIP: 0010:bytes_is_nonzero mm/kasan/kasan.c:166 [inline]
>> RIP: 0010:memory_is_nonzero mm/kasan/kasan.c:184 [inline]
>> RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
>> RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
>> RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
>> RIP: 0010:check_memory_region+0x61/0x190 mm/kasan/kasan.c:267
>> RSP: 0018:8801bfa0 EFLAGS: 00010202
>> RAX: ed004e875e33 RBX: 8802743af19b RCX: 817deb1c
>> RDX:  RSI: 0004 RDI: 8802743af198
>> RBP: 8801bfa77780 R08: 11004e875e33 R09: ed004e875e33
>> R10: 0001 R11: ed004e875e33 R12: ed004e875e34
>> R13: 8802743af198 R14: 8801bfc9f000 R15: 8801c135a680
>> FS:  01a1d880() GS:8801db20() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: ed004e875e33 CR3: 0001bfe22003 CR4: 001606f0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: fffe0ff0 DR7: 0400
>> Call Trace:
>>  memcpy+0x23/0x50 mm/kasan/kasan.c:302
>>  memcpy include/linux/string.h:344 [inline]
>>  map_lookup_elem+0x4dc/0xbd0 kernel/bpf/syscall.c:584
>>  SYSC_bpf kernel/bpf/syscall.c:1711 [inline]
>>  SyS_bpf+0x922/0x4400 kernel/bpf/syscall.c:1685
>>  entry_SYSCALL_64_fastpath+0x23/0x9a
>> RIP: 0033:0x440ac9
>> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
>> RAX: ffda RBX:  RCX: 00440ac9
>> RDX: 0018 RSI: 20eed000 RDI: 0001
>> RBP:  R08:  R09: 
>> R10:  R11: 0203 R12: 004022a0
>> R13: 00402330 R14:  R15: 
>> Code: 89 f8 49 c1 e8 03 49 89 db 49 c1 eb 03 4d 01 cb 4d 01 c1 4d 8d 63 01
>> 4c 89 c8 4d 89 e2 4d 29 ca 49 83 fa 10 7f 3d 4d 85 d2 74 33 <41> 80 39 00 75
>> 21 48 b8 01 00 00 00 00 fc ff df 4d 01 d1 49 01
>> RIP: bytes_is_nonzero mm/kasan/kasan.c:166 [inline] RSP: 8801bfa0
>> RIP: memory_is_nonzero mm/kasan/kasan.c:184 [inline] RSP: 8801bfa0
>> RIP: memory_is_poisoned_n mm/kasan/kasan.c:210 [inline] RSP:
>> 8801bfa0
>> RIP: memory_is_poisoned mm/kasan/kasan.c:241 [inline] RSP: 8801bfa0
>> RIP: check_memory_region_inline mm/kasan/kasan.c:257 [inline] RSP:
>> 8801bfa0
>> RIP: check_memory_region+0x61/0x190 mm/kasan/kasan.c:267 RSP:
>> 8801bfa0
>> CR2: ed004e875e33
>> ---[ end trace 769bd3705f3abe78 ]---
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may 

Re: BUG: unable to handle kernel paging request in check_memory_region

[Daniel Borkmann]

On 01/13/2018 08:29 AM, Dmitry Vyukov wrote:
> On Fri, Jan 12, 2018 at 11:58 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> c92a9a461dff6140c539c61e457aa97df29517d6
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+32b24f3e7c9000c48...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
> 
> 
> Daniel, is it the same bug that was fixed by "bpf, array: fix overflow
> in max_entries and undefined behavior in index_mask"?

And also here, fixed by:

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1

>> audit: type=1400 audit(1515790631.378:9): avc:  denied  { sys_chroot } for
>> pid=3510 comm="syzkaller602893" capability=18
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns
>> permissive=1
>> BUG: unable to handle kernel paging request at ed004e875e33
>> IP: bytes_is_nonzero mm/kasan/kasan.c:166 [inline]
>> IP: memory_is_nonzero mm/kasan/kasan.c:184 [inline]
>> IP: memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
>> IP: memory_is_poisoned mm/kasan/kasan.c:241 [inline]
>> IP: check_memory_region_inline mm/kasan/kasan.c:257 [inline]
>> IP: check_memory_region+0x61/0x190 mm/kasan/kasan.c:267
>> PGD 21ffee067 P4D 21ffee067 PUD 21ffec067 PMD 0
>> Oops:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 0 PID: 3510 Comm: syzkaller602893 Not tainted 4.15.0-rc7+ #259
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> RIP: 0010:bytes_is_nonzero mm/kasan/kasan.c:166 [inline]
>> RIP: 0010:memory_is_nonzero mm/kasan/kasan.c:184 [inline]
>> RIP: 0010:memory_is_poisoned_n mm/kasan/kasan.c:210 [inline]
>> RIP: 0010:memory_is_poisoned mm/kasan/kasan.c:241 [inline]
>> RIP: 0010:check_memory_region_inline mm/kasan/kasan.c:257 [inline]
>> RIP: 0010:check_memory_region+0x61/0x190 mm/kasan/kasan.c:267
>> RSP: 0018:8801bfa0 EFLAGS: 00010202
>> RAX: ed004e875e33 RBX: 8802743af19b RCX: 817deb1c
>> RDX:  RSI: 0004 RDI: 8802743af198
>> RBP: 8801bfa77780 R08: 11004e875e33 R09: ed004e875e33
>> R10: 0001 R11: ed004e875e33 R12: ed004e875e34
>> R13: 8802743af198 R14: 8801bfc9f000 R15: 8801c135a680
>> FS:  01a1d880() GS:8801db20() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: ed004e875e33 CR3: 0001bfe22003 CR4: 001606f0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: fffe0ff0 DR7: 0400
>> Call Trace:
>>  memcpy+0x23/0x50 mm/kasan/kasan.c:302
>>  memcpy include/linux/string.h:344 [inline]
>>  map_lookup_elem+0x4dc/0xbd0 kernel/bpf/syscall.c:584
>>  SYSC_bpf kernel/bpf/syscall.c:1711 [inline]
>>  SyS_bpf+0x922/0x4400 kernel/bpf/syscall.c:1685
>>  entry_SYSCALL_64_fastpath+0x23/0x9a
>> RIP: 0033:0x440ac9
>> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
>> RAX: ffda RBX:  RCX: 00440ac9
>> RDX: 0018 RSI: 20eed000 RDI: 0001
>> RBP:  R08:  R09: 
>> R10:  R11: 0203 R12: 004022a0
>> R13: 00402330 R14:  R15: 
>> Code: 89 f8 49 c1 e8 03 49 89 db 49 c1 eb 03 4d 01 cb 4d 01 c1 4d 8d 63 01
>> 4c 89 c8 4d 89 e2 4d 29 ca 49 83 fa 10 7f 3d 4d 85 d2 74 33 <41> 80 39 00 75
>> 21 48 b8 01 00 00 00 00 fc ff df 4d 01 d1 49 01
>> RIP: bytes_is_nonzero mm/kasan/kasan.c:166 [inline] RSP: 8801bfa0
>> RIP: memory_is_nonzero mm/kasan/kasan.c:184 [inline] RSP: 8801bfa0
>> RIP: memory_is_poisoned_n mm/kasan/kasan.c:210 [inline] RSP:
>> 8801bfa0
>> RIP: memory_is_poisoned mm/kasan/kasan.c:241 [inline] RSP: 8801bfa0
>> RIP: check_memory_region_inline mm/kasan/kasan.c:257 [inline] RSP:
>> 8801bfa0
>> RIP: check_memory_region+0x61/0x190 mm/kasan/kasan.c:267 RSP:
>> 8801bfa0
>> CR2: ed004e875e33
>> ---[ end trace 769bd3705f3abe78 ]---
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.

Re: general protection fault in __bpf_map_put

[Daniel Borkmann]

On 01/13/2018 08:16 AM, Dmitry Vyukov wrote:
> On Wed, Jan 10, 2018 at 1:58 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> b4464bcab38d3f7fe995a7cb960eeac6889bec08
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+d2f5524fb46fd3b31...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
> 
> Daniel, is it the same bug that was fixed by "bpf, array: fix overflow
> in max_entries and undefined behavior in index_mask"?

Yes, fixed by:

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1

>> audit: type=1400 audit(1515571663.627:11): avc:  denied  { map_read
>> map_write } for  pid=3537 comm="syzkaller597104"
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=bpf
>> permissive=1
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 1 PID: 23 Comm: kworker/1:1 Not tainted 4.15.0-rc7-next-20180110+ #93
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Workqueue: events bpf_map_free_deferred
>> RIP: 0010:__bpf_map_put+0x64/0x2e0 kernel/bpf/syscall.c:233
>> RSP: 0018:8801d98b7458 EFLAGS: 00010293
>> RAX: 8801d98ac600 RBX: ad6001bc0dd1 RCX: 817e4454
>> RDX:  RSI: 0001 RDI: ad6001bc0dd1
>> RBP: 8801d98b74e8 R08: 11003b316e6a R09: 
>> R10:  R11:  R12: 11003b316e8c
>> R13: dc00 R14: dc00 R15: 0001
>> FS:  () GS:8801db30() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 204f9fe4 CR3: 06822003 CR4: 001606e0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: fffe0ff0 DR7: 0400
>> Call Trace:
>>  bpf_map_put+0x1a/0x20 kernel/bpf/syscall.c:243
>>  bpf_map_fd_put_ptr+0x15/0x20 kernel/bpf/map_in_map.c:96
>>  fd_array_map_delete_elem kernel/bpf/arraymap.c:420 [inline]
>>  bpf_fd_array_map_clear kernel/bpf/arraymap.c:461 [inline]
>>  array_of_map_free+0x100/0x180 kernel/bpf/arraymap.c:618
>>  bpf_map_free_deferred+0xb0/0xe0 kernel/bpf/syscall.c:217
>>  process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2112
>>  worker_thread+0x223/0x1990 kernel/workqueue.c:2246
>>  kthread+0x33c/0x400 kernel/kthread.c:238
>>  ret_from_fork+0x4b/0x60 arch/x86/entry/entry_64.S:547
>> Code: b5 41 48 c7 45 80 1d 2c 59 86 48 c7 45 88 f0 43 7e 81 c7 00 f1 f1 f1
>> f1 c7 40 04 00 f2 f2 f2 c7 40 08 f3 f3 f3 f3 e8 9c 1e f2 ff  ff 4b 48 74
>> 2f e8 91 1e f2 ff 48 b8 00 00 00 00 00 fc ff df
>> RIP: __bpf_map_put+0x64/0x2e0 kernel/bpf/syscall.c:233 RSP: 8801d98b7458
>> ---[ end trace 61592f27aaa1e096 ]---
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkal...@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> 

Re: general protection fault in __bpf_map_put

[Daniel Borkmann]

On 01/13/2018 08:16 AM, Dmitry Vyukov wrote:
> On Wed, Jan 10, 2018 at 1:58 PM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> b4464bcab38d3f7fe995a7cb960eeac6889bec08
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+d2f5524fb46fd3b31...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
> 
> Daniel, is it the same bug that was fixed by "bpf, array: fix overflow
> in max_entries and undefined behavior in index_mask"?

Yes, fixed by:

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1

>> audit: type=1400 audit(1515571663.627:11): avc:  denied  { map_read
>> map_write } for  pid=3537 comm="syzkaller597104"
>> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023
>> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=bpf
>> permissive=1
>> kasan: CONFIG_KASAN_INLINE enabled
>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>> general protection fault:  [#1] SMP KASAN
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Modules linked in:
>> CPU: 1 PID: 23 Comm: kworker/1:1 Not tainted 4.15.0-rc7-next-20180110+ #93
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Workqueue: events bpf_map_free_deferred
>> RIP: 0010:__bpf_map_put+0x64/0x2e0 kernel/bpf/syscall.c:233
>> RSP: 0018:8801d98b7458 EFLAGS: 00010293
>> RAX: 8801d98ac600 RBX: ad6001bc0dd1 RCX: 817e4454
>> RDX:  RSI: 0001 RDI: ad6001bc0dd1
>> RBP: 8801d98b74e8 R08: 11003b316e6a R09: 
>> R10:  R11:  R12: 11003b316e8c
>> R13: dc00 R14: dc00 R15: 0001
>> FS:  () GS:8801db30() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 204f9fe4 CR3: 06822003 CR4: 001606e0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: fffe0ff0 DR7: 0400
>> Call Trace:
>>  bpf_map_put+0x1a/0x20 kernel/bpf/syscall.c:243
>>  bpf_map_fd_put_ptr+0x15/0x20 kernel/bpf/map_in_map.c:96
>>  fd_array_map_delete_elem kernel/bpf/arraymap.c:420 [inline]
>>  bpf_fd_array_map_clear kernel/bpf/arraymap.c:461 [inline]
>>  array_of_map_free+0x100/0x180 kernel/bpf/arraymap.c:618
>>  bpf_map_free_deferred+0xb0/0xe0 kernel/bpf/syscall.c:217
>>  process_one_work+0xbbf/0x1af0 kernel/workqueue.c:2112
>>  worker_thread+0x223/0x1990 kernel/workqueue.c:2246
>>  kthread+0x33c/0x400 kernel/kthread.c:238
>>  ret_from_fork+0x4b/0x60 arch/x86/entry/entry_64.S:547
>> Code: b5 41 48 c7 45 80 1d 2c 59 86 48 c7 45 88 f0 43 7e 81 c7 00 f1 f1 f1
>> f1 c7 40 04 00 f2 f2 f2 c7 40 08 f3 f3 f3 f3 e8 9c 1e f2 ff  ff 4b 48 74
>> 2f e8 91 1e f2 ff 48 b8 00 00 00 00 00 fc ff df
>> RIP: __bpf_map_put+0x64/0x2e0 kernel/bpf/syscall.c:233 RSP: 8801d98b7458
>> ---[ end trace 61592f27aaa1e096 ]---
>> Kernel panic - not syncing: Fatal exception
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>
>>
>> ---
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to syzkal...@googlegroups.com.
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> If you want to test a patch for this bug, please reply with:
>> #syz test: git://repo/address.git branch
>> and provide the patch inline or as an attachment.
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/94eb2c06de30df3d1605626b941b%40google.com.
>> For more options, visit 

Re: divide error in ___bpf_prog_run

[Daniel Borkmann]

On 01/13/2018 02:58 AM, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on 19d28fbd306e7ae7c1acf05c3e6968b56f0d196b
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

Fixed by:

http://patchwork.ozlabs.org/patch/860270/
http://patchwork.ozlabs.org/patch/860275/

Will get them in as soon as DaveM pulled the current batch into net.

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+48340bb518e88849e...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for details.
> If you forward the report, please keep this part and the footer.
> 
> divide error:  [#1] SMP KASAN
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 3501 Comm: syzkaller702501 Not tainted 4.15.0-rc7+ #185
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> RIP: 0010:___bpf_prog_run+0x3cc7/0x6100 kernel/bpf/core.c:976
> RSP: 0018:8801c7927200 EFLAGS: 00010246
> RAX:  RBX: dc00 RCX: 
> RDX:  RSI: c9002030 RDI: c9002049
> RBP: 8801c7927308 R08: 110038f24dd9 R09: 0002
> R10: 8801c7927388 R11:  R12: 8801c7927340
> R13: c9002048 R14: 8801c7927340 R15: fffc
> FS:  02255880() GS:8801db20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20fd3000 CR3: 0001c2284004 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  __bpf_prog_run160+0xde/0x150 kernel/bpf/core.c:1346
>  bpf_prog_run_save_cb include/linux/filter.h:556 [inline]
>  sk_filter_trim_cap+0x33c/0x9c0 net/core/filter.c:103
>  sk_filter include/linux/filter.h:685 [inline]
>  netlink_unicast+0x1b8/0x6b0 net/netlink/af_netlink.c:1336
>  nlmsg_unicast include/net/netlink.h:608 [inline]
>  rtnl_unicast net/core/rtnetlink.c:700 [inline]
>  rtnl_stats_get+0x7bb/0xa10 net/core/rtnetlink.c:4363
>  rtnetlink_rcv_msg+0x57f/0xb10 net/core/rtnetlink.c:4530
>  netlink_rcv_skb+0x224/0x470 net/netlink/af_netlink.c:2441
>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4548
>  netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
>  netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1334
>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
>  sock_sendmsg_nosec net/socket.c:630 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:640
>  sock_write_iter+0x31a/0x5d0 net/socket.c:909
>  call_write_iter include/linux/fs.h:1772 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x684/0x970 fs/read_write.c:482
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x43ffc9
> RSP: 002b:7ffe602ec9f8 EFLAGS: 0217 ORIG_RAX: 0001
> RAX: ffda RBX:  RCX: 0043ffc9
> RDX: 0026 RSI: 20fd3000 RDI: 0004
> RBP: 006ca018 R08:  R09: 
> R10: 0004 R11: 0217 R12: 00401930
> R13: 004019c0 R14:  R15: 
> Code: 89 85 58 ff ff ff 41 0f b6 55 01 c0 ea 04 0f b6 d2 4d 8d 34 d4 4c 89 f2 
> 48 c1 ea 03 80 3c 1a 00 0f 85 ee 1e 00 00 41 8b 0e 31 d2 <48> f7 f1 48 89 85 
> 58 ff ff ff 41 0f b6 45 01 83 e0 0f 4d 8d 34
> RIP: ___bpf_prog_run+0x3cc7/0x6100 kernel/bpf/core.c:976 RSP: 8801c7927200
> ---[ end trace 274313e5f69f4eff ]---
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug report.
> Note: all commands must start from beginning of the line in the email body.

Re: divide error in ___bpf_prog_run

[Daniel Borkmann]

On 01/13/2018 02:58 AM, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on 19d28fbd306e7ae7c1acf05c3e6968b56f0d196b
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

Fixed by:

http://patchwork.ozlabs.org/patch/860270/
http://patchwork.ozlabs.org/patch/860275/

Will get them in as soon as DaveM pulled the current batch into net.

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+48340bb518e88849e...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for details.
> If you forward the report, please keep this part and the footer.
> 
> divide error:  [#1] SMP KASAN
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 3501 Comm: syzkaller702501 Not tainted 4.15.0-rc7+ #185
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> RIP: 0010:___bpf_prog_run+0x3cc7/0x6100 kernel/bpf/core.c:976
> RSP: 0018:8801c7927200 EFLAGS: 00010246
> RAX:  RBX: dc00 RCX: 
> RDX:  RSI: c9002030 RDI: c9002049
> RBP: 8801c7927308 R08: 110038f24dd9 R09: 0002
> R10: 8801c7927388 R11:  R12: 8801c7927340
> R13: c9002048 R14: 8801c7927340 R15: fffc
> FS:  02255880() GS:8801db20() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20fd3000 CR3: 0001c2284004 CR4: 001606f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  __bpf_prog_run160+0xde/0x150 kernel/bpf/core.c:1346
>  bpf_prog_run_save_cb include/linux/filter.h:556 [inline]
>  sk_filter_trim_cap+0x33c/0x9c0 net/core/filter.c:103
>  sk_filter include/linux/filter.h:685 [inline]
>  netlink_unicast+0x1b8/0x6b0 net/netlink/af_netlink.c:1336
>  nlmsg_unicast include/net/netlink.h:608 [inline]
>  rtnl_unicast net/core/rtnetlink.c:700 [inline]
>  rtnl_stats_get+0x7bb/0xa10 net/core/rtnetlink.c:4363
>  rtnetlink_rcv_msg+0x57f/0xb10 net/core/rtnetlink.c:4530
>  netlink_rcv_skb+0x224/0x470 net/netlink/af_netlink.c:2441
>  rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:4548
>  netlink_unicast_kernel net/netlink/af_netlink.c:1308 [inline]
>  netlink_unicast+0x4c4/0x6b0 net/netlink/af_netlink.c:1334
>  netlink_sendmsg+0xa4a/0xe60 net/netlink/af_netlink.c:1897
>  sock_sendmsg_nosec net/socket.c:630 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:640
>  sock_write_iter+0x31a/0x5d0 net/socket.c:909
>  call_write_iter include/linux/fs.h:1772 [inline]
>  new_sync_write fs/read_write.c:469 [inline]
>  __vfs_write+0x684/0x970 fs/read_write.c:482
>  vfs_write+0x189/0x510 fs/read_write.c:544
>  SYSC_write fs/read_write.c:589 [inline]
>  SyS_write+0xef/0x220 fs/read_write.c:581
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x43ffc9
> RSP: 002b:7ffe602ec9f8 EFLAGS: 0217 ORIG_RAX: 0001
> RAX: ffda RBX:  RCX: 0043ffc9
> RDX: 0026 RSI: 20fd3000 RDI: 0004
> RBP: 006ca018 R08:  R09: 
> R10: 0004 R11: 0217 R12: 00401930
> R13: 004019c0 R14:  R15: 
> Code: 89 85 58 ff ff ff 41 0f b6 55 01 c0 ea 04 0f b6 d2 4d 8d 34 d4 4c 89 f2 
> 48 c1 ea 03 80 3c 1a 00 0f 85 ee 1e 00 00 41 8b 0e 31 d2 <48> f7 f1 48 89 85 
> 58 ff ff ff 41 0f b6 45 01 83 e0 0f 4d 8d 34
> RIP: ___bpf_prog_run+0x3cc7/0x6100 kernel/bpf/core.c:976 RSP: 8801c7927200
> ---[ end trace 274313e5f69f4eff ]---
> 
> 
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> 
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address.git branch
> and provide the patch inline or as an attachment.
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug report.
> Note: all commands must start from beginning of the line in the email body.

Re: KASAN: slab-out-of-bounds Read in map_lookup_elem

[Daniel Borkmann]

On 01/13/2018 02:58 AM, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on 19d28fbd306e7ae7c1acf05c3e6968b56f0d196b
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

Fixed here as well:

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e631b5eb810eae085...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1515782899.456:8): avc:  denied  { sys_admin } for  
> pid=3501 comm="syzkaller937663" capability=21  
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns 
> permissive=1
> audit: type=1400 audit(1515782899.512:9): avc:  denied  { sys_chroot } for  
> pid=3502 comm="syzkaller937663" capability=18  
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns 
> permissive=1
> ==
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: slab-out-of-bounds in map_lookup_elem+0x4dc/0xbd0 
> kernel/bpf/syscall.c:584
> Read of size 2097153 at addr 8801bfc7e690 by task syzkaller937663/3502
> 
> CPU: 0 PID: 3502 Comm: syzkaller937663 Not tainted 4.15.0-rc7+ #185
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x23/0x50 mm/kasan/kasan.c:302
>  memcpy include/linux/string.h:344 [inline]
>  map_lookup_elem+0x4dc/0xbd0 kernel/bpf/syscall.c:584
>  SYSC_bpf kernel/bpf/syscall.c:1808 [inline]
>  SyS_bpf+0x922/0x4400 kernel/bpf/syscall.c:1782
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x440ab9
> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
> RAX: ffda RBX: 7fffc494ea60 RCX: 00440ab9
> RDX: 0018 RSI: 20eab000 RDI: 0001
> RBP:  R08:  R09: 
> R10:  R11: 0203 R12: 00402290
> R13: 00402320 R14:  R15: 
> 
> Allocated by task 3502:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  __do_kmalloc_node mm/slab.c:3672 [inline]
>  __kmalloc_node+0x47/0x70 mm/slab.c:3679
>  kmalloc_node include/linux/slab.h:541 [inline]
>  bpf_map_area_alloc+0x32/0x80 kernel/bpf/syscall.c:123
>  array_map_alloc+0x351/0xa00 kernel/bpf/arraymap.c:96
>  find_and_alloc_map kernel/bpf/syscall.c:105 [inline]
>  map_create kernel/bpf/syscall.c:404 [inline]
>  SYSC_bpf kernel/bpf/syscall.c:1805 [inline]
>  SyS_bpf+0x7f8/0x4400 kernel/bpf/syscall.c:1782
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> 
> Freed by task 1966:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3488 [inline]
>  kfree+0xd6/0x260 mm/slab.c:3803
>  seq_release fs/seq_file.c:366 [inline]
>  single_release+0x80/0xb0 fs/seq_file.c:602
>  __fput+0x327/0x7e0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x296/0x310 arch/x86/entry/common.c:162
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x98/0x9a
> 
> The buggy address belongs to the object at 8801bfc7e5c0
>  which belongs to the cache kmalloc-256 of size 256
> The buggy address is located 208 bytes inside of
>  256-byte region [8801bfc7e5c0, 8801bfc7e6c0)
> The buggy address belongs to the page:
> page:ea0006ff1f80 count:1 mapcount:0 mapping:8801bfc7e0c0 index:0x0
> flags: 0x2fffc000100(slab)
> raw: 02fffc000100 8801bfc7e0c0  0001000c
> raw: ea00070149e0 ea0006ff2be0 8801dac007c0 
> page dumped because: kasan: bad access 

Re: KASAN: slab-out-of-bounds Read in map_lookup_elem

[Daniel Borkmann]

On 01/13/2018 02:58 AM, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on 19d28fbd306e7ae7c1acf05c3e6968b56f0d196b
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

Fixed here as well:

https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+e631b5eb810eae085...@syzkaller.appspotmail.com
> It will help syzbot understand when the bug is fixed. See footer for details.
> If you forward the report, please keep this part and the footer.
> 
> audit: type=1400 audit(1515782899.456:8): avc:  denied  { sys_admin } for  
> pid=3501 comm="syzkaller937663" capability=21  
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns 
> permissive=1
> audit: type=1400 audit(1515782899.512:9): avc:  denied  { sys_chroot } for  
> pid=3502 comm="syzkaller937663" capability=18  
> scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 
> tcontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tclass=cap_userns 
> permissive=1
> ==
> BUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:344 [inline]
> BUG: KASAN: slab-out-of-bounds in map_lookup_elem+0x4dc/0xbd0 
> kernel/bpf/syscall.c:584
> Read of size 2097153 at addr 8801bfc7e690 by task syzkaller937663/3502
> 
> CPU: 0 PID: 3502 Comm: syzkaller937663 Not tainted 4.15.0-rc7+ #185
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:17 [inline]
>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351 [inline]
>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>  check_memory_region_inline mm/kasan/kasan.c:260 [inline]
>  check_memory_region+0x137/0x190 mm/kasan/kasan.c:267
>  memcpy+0x23/0x50 mm/kasan/kasan.c:302
>  memcpy include/linux/string.h:344 [inline]
>  map_lookup_elem+0x4dc/0xbd0 kernel/bpf/syscall.c:584
>  SYSC_bpf kernel/bpf/syscall.c:1808 [inline]
>  SyS_bpf+0x922/0x4400 kernel/bpf/syscall.c:1782
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> RIP: 0033:0x440ab9
> RSP: 002b:007dff68 EFLAGS: 0203 ORIG_RAX: 0141
> RAX: ffda RBX: 7fffc494ea60 RCX: 00440ab9
> RDX: 0018 RSI: 20eab000 RDI: 0001
> RBP:  R08:  R09: 
> R10:  R11: 0203 R12: 00402290
> R13: 00402320 R14:  R15: 
> 
> Allocated by task 3502:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>  __do_kmalloc_node mm/slab.c:3672 [inline]
>  __kmalloc_node+0x47/0x70 mm/slab.c:3679
>  kmalloc_node include/linux/slab.h:541 [inline]
>  bpf_map_area_alloc+0x32/0x80 kernel/bpf/syscall.c:123
>  array_map_alloc+0x351/0xa00 kernel/bpf/arraymap.c:96
>  find_and_alloc_map kernel/bpf/syscall.c:105 [inline]
>  map_create kernel/bpf/syscall.c:404 [inline]
>  SYSC_bpf kernel/bpf/syscall.c:1805 [inline]
>  SyS_bpf+0x7f8/0x4400 kernel/bpf/syscall.c:1782
>  entry_SYSCALL_64_fastpath+0x23/0x9a
> 
> Freed by task 1966:
>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>  set_track mm/kasan/kasan.c:459 [inline]
>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>  __cache_free mm/slab.c:3488 [inline]
>  kfree+0xd6/0x260 mm/slab.c:3803
>  seq_release fs/seq_file.c:366 [inline]
>  single_release+0x80/0xb0 fs/seq_file.c:602
>  __fput+0x327/0x7e0 fs/file_table.c:210
>  fput+0x15/0x20 fs/file_table.c:244
>  task_work_run+0x199/0x270 kernel/task_work.c:113
>  tracehook_notify_resume include/linux/tracehook.h:191 [inline]
>  exit_to_usermode_loop+0x296/0x310 arch/x86/entry/common.c:162
>  prepare_exit_to_usermode arch/x86/entry/common.c:195 [inline]
>  syscall_return_slowpath+0x490/0x550 arch/x86/entry/common.c:264
>  entry_SYSCALL_64_fastpath+0x98/0x9a
> 
> The buggy address belongs to the object at 8801bfc7e5c0
>  which belongs to the cache kmalloc-256 of size 256
> The buggy address is located 208 bytes inside of
>  256-byte region [8801bfc7e5c0, 8801bfc7e6c0)
> The buggy address belongs to the page:
> page:ea0006ff1f80 count:1 mapcount:0 mapping:8801bfc7e0c0 index:0x0
> flags: 0x2fffc000100(slab)
> raw: 02fffc000100 8801bfc7e0c0  0001000c
> raw: ea00070149e0 ea0006ff2be0 8801dac007c0 
> page dumped because: kasan: bad access 

Re: linux-next: build failure after merge of the net-next tree

[Daniel Borkmann]

On 01/12/2018 04:56 PM, Alexei Starovoitov wrote:
> On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote:
>> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
>>> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
>>>> From: Alexei Starovoitov <alexei.starovoi...@gmail.com>
>>>> Date: Wed, 10 Jan 2018 17:58:54 -0800
>>>>
>>>>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> After merging the net-next tree, today's linux-next build (x86_64
>>>>>> allmodconfig) failed like this:
>>>>>>
>>>>>> kernel/bpf/verifier.o: In function `bpf_check':
>>>>>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
>>>>>>
>>>>>> Caused by commit
>>>>>>
>>>>>>   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
>>>>>>
>>>>>> interacting with commit
>>>>>>
>>>>>>   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
>>>>>>
>>>>>> from the bpf and net trees.
>>>>>>
>>>>>> I have just reverted commit 290af86629b2 for today.  A better solution
>>>>>> would be nice (lie fixing this in a merge between the net-next and net
>>>>>> trees).
>>>>>
>>>>> that's due to 'endif' from 290af86629b2 needs to be moved above
>>>>> bpf_patch_call_args() definition.
>>>>
>>>> That doesn't fix it, because then you'd need to expose
>>>> interpreters_args as well and obviously that can't be right.
>>>>
>>>> Instead, we should never call bpf_patch_call_args() when JIT always on
>>>> is enabled.  So if we fail to JIT the subprogs we should fail
>>>> immediately.
>>>
>>> right, as I was trying to say one extra hunk would be needed for net-next.
>>> I was reading this patch:
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index a2b211262c25..ca80559c4ec3 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env 
>>> *env)
>>> depth = get_callee_stack_depth(env, insn, i);
>>> if (depth < 0)
>>> return depth;
>>> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
>>> +   return -ENOTSUPP;
>>> +#else
>>> bpf_patch_call_args(insn, depth);
>>> +#endif
>>> }
>>> return 0;
>>>
>>> but below should be fine too.
>>> Will test it asap.
>>>
>>>> This is the net --> net-next merge resolution I am about to use to fix
>>>> this:
>>>>
>>>> ...
>>>>  +static int fixup_call_args(struct bpf_verifier_env *env)
>>>>  +{
>>>>  + struct bpf_prog *prog = env->prog;
>>>>  + struct bpf_insn *insn = prog->insnsi;
>>>> -  int i, depth;
>>>> ++ int i, depth, err;
>>>>  +
>>>> -  if (env->prog->jit_requested)
>>>> -  if (jit_subprogs(env) == 0)
>>>> ++ err = 0;
>>
>> Looks fine to me. The only thing I was wondering was whether we should
>> set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
>> if for some reason we would missed to set prog->jit_requested bit under
>> CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
>> calls in the prog. But that also means for bpf_prog_load() that right
>> after bpf_check() returned, we would go into bpf_prog_select_runtime()
>> since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
>> from there wouldn't do anything either since prog->jit_requested was
>> not set in the first place, therefore we return with -ENOTSUPP from
>> there. So the resolution looks fine to me, we can leave it as is.
> 
> jit_subprogs() can fail, so err = -ENOTSUPP is necessary.

But if jit_subprogs() fails, then the err is propagated at the end of
the function (the 'return err' I mean).

Re: linux-next: build failure after merge of the net-next tree

[Daniel Borkmann]

On 01/12/2018 04:56 PM, Alexei Starovoitov wrote:
> On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote:
>> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
>>> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
>>>> From: Alexei Starovoitov 
>>>> Date: Wed, 10 Jan 2018 17:58:54 -0800
>>>>
>>>>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> After merging the net-next tree, today's linux-next build (x86_64
>>>>>> allmodconfig) failed like this:
>>>>>>
>>>>>> kernel/bpf/verifier.o: In function `bpf_check':
>>>>>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
>>>>>>
>>>>>> Caused by commit
>>>>>>
>>>>>>   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
>>>>>>
>>>>>> interacting with commit
>>>>>>
>>>>>>   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
>>>>>>
>>>>>> from the bpf and net trees.
>>>>>>
>>>>>> I have just reverted commit 290af86629b2 for today.  A better solution
>>>>>> would be nice (lie fixing this in a merge between the net-next and net
>>>>>> trees).
>>>>>
>>>>> that's due to 'endif' from 290af86629b2 needs to be moved above
>>>>> bpf_patch_call_args() definition.
>>>>
>>>> That doesn't fix it, because then you'd need to expose
>>>> interpreters_args as well and obviously that can't be right.
>>>>
>>>> Instead, we should never call bpf_patch_call_args() when JIT always on
>>>> is enabled.  So if we fail to JIT the subprogs we should fail
>>>> immediately.
>>>
>>> right, as I was trying to say one extra hunk would be needed for net-next.
>>> I was reading this patch:
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index a2b211262c25..ca80559c4ec3 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env 
>>> *env)
>>> depth = get_callee_stack_depth(env, insn, i);
>>> if (depth < 0)
>>> return depth;
>>> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
>>> +   return -ENOTSUPP;
>>> +#else
>>> bpf_patch_call_args(insn, depth);
>>> +#endif
>>> }
>>> return 0;
>>>
>>> but below should be fine too.
>>> Will test it asap.
>>>
>>>> This is the net --> net-next merge resolution I am about to use to fix
>>>> this:
>>>>
>>>> ...
>>>>  +static int fixup_call_args(struct bpf_verifier_env *env)
>>>>  +{
>>>>  + struct bpf_prog *prog = env->prog;
>>>>  + struct bpf_insn *insn = prog->insnsi;
>>>> -  int i, depth;
>>>> ++ int i, depth, err;
>>>>  +
>>>> -  if (env->prog->jit_requested)
>>>> -  if (jit_subprogs(env) == 0)
>>>> ++ err = 0;
>>
>> Looks fine to me. The only thing I was wondering was whether we should
>> set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
>> if for some reason we would missed to set prog->jit_requested bit under
>> CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
>> calls in the prog. But that also means for bpf_prog_load() that right
>> after bpf_check() returned, we would go into bpf_prog_select_runtime()
>> since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
>> from there wouldn't do anything either since prog->jit_requested was
>> not set in the first place, therefore we return with -ENOTSUPP from
>> there. So the resolution looks fine to me, we can leave it as is.
> 
> jit_subprogs() can fail, so err = -ENOTSUPP is necessary.

But if jit_subprogs() fails, then the err is propagated at the end of
the function (the 'return err' I mean).

Re: linux-next: build failure after merge of the net-next tree

[Daniel Borkmann]

On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
>> From: Alexei Starovoitov 
>> Date: Wed, 10 Jan 2018 17:58:54 -0800
>>
>>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
 Hi all,

 After merging the net-next tree, today's linux-next build (x86_64
 allmodconfig) failed like this:

 kernel/bpf/verifier.o: In function `bpf_check':
 verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'

 Caused by commit

   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")

 interacting with commit

   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")

 from the bpf and net trees.

 I have just reverted commit 290af86629b2 for today.  A better solution
 would be nice (lie fixing this in a merge between the net-next and net
 trees).
>>>
>>> that's due to 'endif' from 290af86629b2 needs to be moved above
>>> bpf_patch_call_args() definition.
>>
>> That doesn't fix it, because then you'd need to expose
>> interpreters_args as well and obviously that can't be right.
>>
>> Instead, we should never call bpf_patch_call_args() when JIT always on
>> is enabled.  So if we fail to JIT the subprogs we should fail
>> immediately.
> 
> right, as I was trying to say one extra hunk would be needed for net-next.
> I was reading this patch:
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index a2b211262c25..ca80559c4ec3 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env 
> *env)
> depth = get_callee_stack_depth(env, insn, i);
> if (depth < 0)
> return depth;
> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
> +   return -ENOTSUPP;
> +#else
> bpf_patch_call_args(insn, depth);
> +#endif
> }
> return 0;
> 
> but below should be fine too.
> Will test it asap.
> 
>> This is the net --> net-next merge resolution I am about to use to fix
>> this:
>>
>> ...
>>  +static int fixup_call_args(struct bpf_verifier_env *env)
>>  +{
>>  +   struct bpf_prog *prog = env->prog;
>>  +   struct bpf_insn *insn = prog->insnsi;
>> -int i, depth;
>> ++   int i, depth, err;
>>  +
>> -if (env->prog->jit_requested)
>> -if (jit_subprogs(env) == 0)
>> ++   err = 0;

Looks fine to me. The only thing I was wondering was whether we should
set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
if for some reason we would missed to set prog->jit_requested bit under
CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
calls in the prog. But that also means for bpf_prog_load() that right
after bpf_check() returned, we would go into bpf_prog_select_runtime()
since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
from there wouldn't do anything either since prog->jit_requested was
not set in the first place, therefore we return with -ENOTSUPP from
there. So the resolution looks fine to me, we can leave it as is.

>> ++   if (env->prog->jit_requested) {
>> ++   err = jit_subprogs(env);
>> ++   if (err == 0)
>>  +   return 0;
>> - 
>> ++   }
>> ++#ifndef CONFIG_BPF_JIT_ALWAYS_ON
>>  +   for (i = 0; i < prog->len; i++, insn++) {
>>  +   if (insn->code != (BPF_JMP | BPF_CALL) ||
>>  +   insn->src_reg != BPF_PSEUDO_CALL)
>>  +   continue;
>>  +   depth = get_callee_stack_depth(env, insn, i);
>>  +   if (depth < 0)
>>  +   return depth;
>>  +   bpf_patch_call_args(insn, depth);
>>  +   }
>> -return 0;
>> ++   err = 0;
>> ++#endif
>> ++   return err;
>>  +}
>>  +
>>   /* fixup insn->imm field of bpf_call instructions
>>* and inline eligible helpers as explicit sequence of BPF instructions
>>*

Re: linux-next: build failure after merge of the net-next tree

[Daniel Borkmann]

On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
>> From: Alexei Starovoitov 
>> Date: Wed, 10 Jan 2018 17:58:54 -0800
>>
>>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
 Hi all,

 After merging the net-next tree, today's linux-next build (x86_64
 allmodconfig) failed like this:

 kernel/bpf/verifier.o: In function `bpf_check':
 verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'

 Caused by commit

   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")

 interacting with commit

   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")

 from the bpf and net trees.

 I have just reverted commit 290af86629b2 for today.  A better solution
 would be nice (lie fixing this in a merge between the net-next and net
 trees).
>>>
>>> that's due to 'endif' from 290af86629b2 needs to be moved above
>>> bpf_patch_call_args() definition.
>>
>> That doesn't fix it, because then you'd need to expose
>> interpreters_args as well and obviously that can't be right.
>>
>> Instead, we should never call bpf_patch_call_args() when JIT always on
>> is enabled.  So if we fail to JIT the subprogs we should fail
>> immediately.
> 
> right, as I was trying to say one extra hunk would be needed for net-next.
> I was reading this patch:
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index a2b211262c25..ca80559c4ec3 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env 
> *env)
> depth = get_callee_stack_depth(env, insn, i);
> if (depth < 0)
> return depth;
> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
> +   return -ENOTSUPP;
> +#else
> bpf_patch_call_args(insn, depth);
> +#endif
> }
> return 0;
> 
> but below should be fine too.
> Will test it asap.
> 
>> This is the net --> net-next merge resolution I am about to use to fix
>> this:
>>
>> ...
>>  +static int fixup_call_args(struct bpf_verifier_env *env)
>>  +{
>>  +   struct bpf_prog *prog = env->prog;
>>  +   struct bpf_insn *insn = prog->insnsi;
>> -int i, depth;
>> ++   int i, depth, err;
>>  +
>> -if (env->prog->jit_requested)
>> -if (jit_subprogs(env) == 0)
>> ++   err = 0;

Looks fine to me. The only thing I was wondering was whether we should
set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
if for some reason we would missed to set prog->jit_requested bit under
CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
calls in the prog. But that also means for bpf_prog_load() that right
after bpf_check() returned, we would go into bpf_prog_select_runtime()
since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
from there wouldn't do anything either since prog->jit_requested was
not set in the first place, therefore we return with -ENOTSUPP from
there. So the resolution looks fine to me, we can leave it as is.

>> ++   if (env->prog->jit_requested) {
>> ++   err = jit_subprogs(env);
>> ++   if (err == 0)
>>  +   return 0;
>> - 
>> ++   }
>> ++#ifndef CONFIG_BPF_JIT_ALWAYS_ON
>>  +   for (i = 0; i < prog->len; i++, insn++) {
>>  +   if (insn->code != (BPF_JMP | BPF_CALL) ||
>>  +   insn->src_reg != BPF_PSEUDO_CALL)
>>  +   continue;
>>  +   depth = get_callee_stack_depth(env, insn, i);
>>  +   if (depth < 0)
>>  +   return depth;
>>  +   bpf_patch_call_args(insn, depth);
>>  +   }
>> -return 0;
>> ++   err = 0;
>> ++#endif
>> ++   return err;
>>  +}
>>  +
>>   /* fixup insn->imm field of bpf_call instructions
>>* and inline eligible helpers as explicit sequence of BPF instructions
>>*

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Daniel Borkmann]

On 01/11/2018 04:58 PM, Dan Williams wrote:
> On Thu, Jan 11, 2018 at 1:54 AM, Jiri Kosina  wrote:
>> On Tue, 9 Jan 2018, Josh Poimboeuf wrote:
>>> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
 On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina  wrote:
> On Fri, 5 Jan 2018, Dan Williams wrote:
>
> [ ... snip ... ]
>> Andi Kleen (1):
>>   x86, barrier: stop speculation for failed access_ok
>>
>> Dan Williams (13):
>>   x86: implement nospec_barrier()
>>   [media] uvcvideo: prevent bounds-check bypass via speculative 
>> execution
>>   carl9170: prevent bounds-check bypass via speculative execution
>>   p54: prevent bounds-check bypass via speculative execution
>>   qla2xxx: prevent bounds-check bypass via speculative execution
>>   cw1200: prevent bounds-check bypass via speculative execution
>>   Thermal/int340x: prevent bounds-check bypass via speculative 
>> execution
>>   ipv6: prevent bounds-check bypass via speculative execution
>>   ipv4: prevent bounds-check bypass via speculative execution
>>   vfs, fdtable: prevent bounds-check bypass via speculative execution
>>   net: mpls: prevent bounds-check bypass via speculative execution
>>   udf: prevent bounds-check bypass via speculative execution
>>   userns: prevent bounds-check bypass via speculative execution
>>
>> Mark Rutland (4):
>>   asm-generic/barrier: add generic nospec helpers
>>   Documentation: document nospec helpers
>>   arm64: implement nospec_ptr()
>>   arm: implement nospec_ptr()
>
> So considering the recent publication of [1], how come we all of a sudden
> don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and
> LDX_MEM_##SIZEOP, and something comparable for eBPF JIT?
>
> Is this going to be handled in eBPF in some other way?
>
> Without that in place, and considering Jann Horn's paper, it would seem
> like PTI doesn't really lock it down fully, right?

 Here is the latest (v3) bpf fix:

 https://patchwork.ozlabs.org/patch/856645/

 I currently have v2 on my 'nospec' branch and will move that to v3 for
 the next update, unless it goes upstream before then.
>>
>> Daniel, I guess you're planning to send this still for 4.15?
> 
> It's pending in the bpf.git tree:
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=b2157399cc9

Sorry for the delay, just noticed the question now since not on Cc either:
It made it into in DaveM's tree already and part of his latest pull-req
to Linus.

>>> That patch seems specific to CONFIG_BPF_SYSCALL.  Is the bpf() syscall
>>> the only attack vector?  Or are there other ways to run bpf programs
>>> that we should be worried about?
>>
>> Seems like Alexei is probably the only person in the whole universe who
>> isn't CCed here ... let's fix that.
> 
> He will be cc'd on v2 of this series which will be available later today.

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Daniel Borkmann]

On 01/11/2018 04:58 PM, Dan Williams wrote:
> On Thu, Jan 11, 2018 at 1:54 AM, Jiri Kosina  wrote:
>> On Tue, 9 Jan 2018, Josh Poimboeuf wrote:
>>> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote:
 On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina  wrote:
> On Fri, 5 Jan 2018, Dan Williams wrote:
>
> [ ... snip ... ]
>> Andi Kleen (1):
>>   x86, barrier: stop speculation for failed access_ok
>>
>> Dan Williams (13):
>>   x86: implement nospec_barrier()
>>   [media] uvcvideo: prevent bounds-check bypass via speculative 
>> execution
>>   carl9170: prevent bounds-check bypass via speculative execution
>>   p54: prevent bounds-check bypass via speculative execution
>>   qla2xxx: prevent bounds-check bypass via speculative execution
>>   cw1200: prevent bounds-check bypass via speculative execution
>>   Thermal/int340x: prevent bounds-check bypass via speculative 
>> execution
>>   ipv6: prevent bounds-check bypass via speculative execution
>>   ipv4: prevent bounds-check bypass via speculative execution
>>   vfs, fdtable: prevent bounds-check bypass via speculative execution
>>   net: mpls: prevent bounds-check bypass via speculative execution
>>   udf: prevent bounds-check bypass via speculative execution
>>   userns: prevent bounds-check bypass via speculative execution
>>
>> Mark Rutland (4):
>>   asm-generic/barrier: add generic nospec helpers
>>   Documentation: document nospec helpers
>>   arm64: implement nospec_ptr()
>>   arm: implement nospec_ptr()
>
> So considering the recent publication of [1], how come we all of a sudden
> don't need the barriers in ___bpf_prog_run(), namely for LD_IMM_DW and
> LDX_MEM_##SIZEOP, and something comparable for eBPF JIT?
>
> Is this going to be handled in eBPF in some other way?
>
> Without that in place, and considering Jann Horn's paper, it would seem
> like PTI doesn't really lock it down fully, right?

 Here is the latest (v3) bpf fix:

 https://patchwork.ozlabs.org/patch/856645/

 I currently have v2 on my 'nospec' branch and will move that to v3 for
 the next update, unless it goes upstream before then.
>>
>> Daniel, I guess you're planning to send this still for 4.15?
> 
> It's pending in the bpf.git tree:
> 
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=b2157399cc9

Sorry for the delay, just noticed the question now since not on Cc either:
It made it into in DaveM's tree already and part of his latest pull-req
to Linus.

>>> That patch seems specific to CONFIG_BPF_SYSCALL.  Is the bpf() syscall
>>> the only attack vector?  Or are there other ways to run bpf programs
>>> that we should be worried about?
>>
>> Seems like Alexei is probably the only person in the whole universe who
>> isn't CCed here ... let's fix that.
> 
> He will be cc'd on v2 of this series which will be available later today.

Re: KASAN: use-after-free Read in __bpf_prog_put

[Daniel Borkmann]

Hi Dmitry,

On 01/11/2018 11:22 AM, Dmitry Vyukov wrote:
> On Thu, Jan 11, 2018 at 11:17 AM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 4147d50978df60f34d444c647dde9e5b34a4315e
>> git://git.cmpxchg.org/linux-mmots.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> Unfortunately, I don't have any reproducer for this bug yet.
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+d85bfb332db8f0794...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> netlink: 3 bytes leftover after parsing attributes in process
>> `syz-executor5'.
>> ==
>> BUG: KASAN: use-after-free in __bpf_prog_put+0x5e8/0x640
>> kernel/bpf/syscall.c:944
>> netlink: 'syz-executor5': attribute type 5 has an invalid length.
>> Read of size 8 at addr 8801d3619658 by task syz-executor0/12398
>>
>> CPU: 1 PID: 12398 Comm: syz-executor0 Not tainted 4.15.0-rc7-mm1+ #53
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>>  kasan_report_error mm/kasan/report.c:354 [inline]
>>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>>  __bpf_prog_put+0x5e8/0x640 kernel/bpf/syscall.c:944
>>  bpf_prog_put+0x1a/0x20 kernel/bpf/syscall.c:961
>>  prog_fd_array_put_ptr+0x15/0x20 kernel/bpf/arraymap.c:446
>>  fd_array_map_delete_elem+0xc8/0x110 kernel/bpf/arraymap.c:420
>>  map_delete_elem kernel/bpf/syscall.c:737 [inline]
>>  SYSC_bpf kernel/bpf/syscall.c:1814 [inline]
>>  SyS_bpf+0x22ea/0x4400 kernel/bpf/syscall.c:1782
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>> RIP: 0033:0x452ac9
>> RSP: 002b:7fb70df60c58 EFLAGS: 0212 ORIG_RAX: 0141
>> RAX: ffda RBX: 0071bea0 RCX: 00452ac9
>> RDX: 0010 RSI: 20f02ff0 RDI: 0003
>> RBP: 03aa R08:  R09: 
>> R10:  R11: 0212 R12: 006f3890
>> R13:  R14: 7fb70df616d4 R15: 
>>
>> Allocated by task 11996:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
>>  kmem_cache_zalloc include/linux/slab.h:694 [inline]
>>  get_empty_filp+0xfb/0x4f0 fs/file_table.c:122
>>  path_openat+0xed/0x3530 fs/namei.c:3514
>>  do_filp_open+0x25b/0x3b0 fs/namei.c:3572
>>  do_sys_open+0x502/0x6d0 fs/open.c:1059
>>  SYSC_open fs/open.c:1077 [inline]
>>  SyS_open+0x2d/0x40 fs/open.c:1072
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> Freed by task 11994:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>>  __cache_free mm/slab.c:3485 [inline]
>>  kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
>>  file_free_rcu+0x5c/0x70 fs/file_table.c:49
>>  __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
>>  rcu_do_batch kernel/rcu/tree.c:2675 [inline]
>>  invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
>>  __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
>>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
>>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>>
>> The buggy address belongs to the object at 8801d36195c0
>>  which belongs to the cache filp of size 456
>> The buggy address is located 152 bytes inside of
>>  456-byte region [8801d36195c0, 8801d3619788)
>> The buggy address belongs to the page:
>> page:ea00074d8640 count:1 mapcount:0 mapping:8801d36190c0 index:0x0
>> flags: 0x2fffc000100(slab)
>> raw: 02fffc000100 8801d36190c0  00010006
>> raw: ea00074c49a0 ea000747a160 8801dae30180 
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>>  8801d3619500: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>  8801d3619580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
>>>
>>> 8801d3619600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> ^
>>  8801d3619680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>  8801d3619700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==
> 
> 
> Is it the same as "general 

Re: KASAN: use-after-free Read in __bpf_prog_put

[Daniel Borkmann]

Hi Dmitry,

On 01/11/2018 11:22 AM, Dmitry Vyukov wrote:
> On Thu, Jan 11, 2018 at 11:17 AM, syzbot
>  wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 4147d50978df60f34d444c647dde9e5b34a4315e
>> git://git.cmpxchg.org/linux-mmots.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> Unfortunately, I don't have any reproducer for this bug yet.
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+d85bfb332db8f0794...@syzkaller.appspotmail.com
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> netlink: 3 bytes leftover after parsing attributes in process
>> `syz-executor5'.
>> ==
>> BUG: KASAN: use-after-free in __bpf_prog_put+0x5e8/0x640
>> kernel/bpf/syscall.c:944
>> netlink: 'syz-executor5': attribute type 5 has an invalid length.
>> Read of size 8 at addr 8801d3619658 by task syz-executor0/12398
>>
>> CPU: 1 PID: 12398 Comm: syz-executor0 Not tainted 4.15.0-rc7-mm1+ #53
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  print_address_description+0x73/0x250 mm/kasan/report.c:256
>>  kasan_report_error mm/kasan/report.c:354 [inline]
>>  kasan_report+0x23b/0x360 mm/kasan/report.c:412
>>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>>  __bpf_prog_put+0x5e8/0x640 kernel/bpf/syscall.c:944
>>  bpf_prog_put+0x1a/0x20 kernel/bpf/syscall.c:961
>>  prog_fd_array_put_ptr+0x15/0x20 kernel/bpf/arraymap.c:446
>>  fd_array_map_delete_elem+0xc8/0x110 kernel/bpf/arraymap.c:420
>>  map_delete_elem kernel/bpf/syscall.c:737 [inline]
>>  SYSC_bpf kernel/bpf/syscall.c:1814 [inline]
>>  SyS_bpf+0x22ea/0x4400 kernel/bpf/syscall.c:1782
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>> RIP: 0033:0x452ac9
>> RSP: 002b:7fb70df60c58 EFLAGS: 0212 ORIG_RAX: 0141
>> RAX: ffda RBX: 0071bea0 RCX: 00452ac9
>> RDX: 0010 RSI: 20f02ff0 RDI: 0003
>> RBP: 03aa R08:  R09: 
>> R10:  R11: 0212 R12: 006f3890
>> R13:  R14: 7fb70df616d4 R15: 
>>
>> Allocated by task 11996:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
>>  kmem_cache_zalloc include/linux/slab.h:694 [inline]
>>  get_empty_filp+0xfb/0x4f0 fs/file_table.c:122
>>  path_openat+0xed/0x3530 fs/namei.c:3514
>>  do_filp_open+0x25b/0x3b0 fs/namei.c:3572
>>  do_sys_open+0x502/0x6d0 fs/open.c:1059
>>  SYSC_open fs/open.c:1077 [inline]
>>  SyS_open+0x2d/0x40 fs/open.c:1072
>>  entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> Freed by task 11994:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>  set_track mm/kasan/kasan.c:459 [inline]
>>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>>  __cache_free mm/slab.c:3485 [inline]
>>  kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
>>  file_free_rcu+0x5c/0x70 fs/file_table.c:49
>>  __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
>>  rcu_do_batch kernel/rcu/tree.c:2675 [inline]
>>  invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
>>  __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
>>  rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
>>  __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>>
>> The buggy address belongs to the object at 8801d36195c0
>>  which belongs to the cache filp of size 456
>> The buggy address is located 152 bytes inside of
>>  456-byte region [8801d36195c0, 8801d3619788)
>> The buggy address belongs to the page:
>> page:ea00074d8640 count:1 mapcount:0 mapping:8801d36190c0 index:0x0
>> flags: 0x2fffc000100(slab)
>> raw: 02fffc000100 8801d36190c0  00010006
>> raw: ea00074c49a0 ea000747a160 8801dae30180 
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>>  8801d3619500: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>  8801d3619580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
>>>
>>> 8801d3619600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> ^
>>  8801d3619680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>  8801d3619700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==
> 
> 
> Is it the same as "general protection fault in __bpf_prog_put"?
> 

Re: WARNING in ___bpf_prog_run

[Daniel Borkmann]

On 01/10/2018 06:31 PM, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on b4464bcab38d3f7fe995a7cb960eeac6889bec08
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

Fix coming in a bit, thanks.

Re: WARNING in ___bpf_prog_run

[Daniel Borkmann]

On 01/10/2018 06:31 PM, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on b4464bcab38d3f7fe995a7cb960eeac6889bec08
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

Fix coming in a bit, thanks.

Re: general protection fault in cgroup_fd_array_put_ptr

[Daniel Borkmann]

On 01/10/2018 04:30 PM, Daniel Borkmann wrote:
> On 01/10/2018 01:58 PM, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on b4464bcab38d3f7fe995a7cb960eeac6889bec08
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
> 
> Currently looking into all of the reports. Looks they're all related to fd 
> array
> map. Will get back once I have some more data & managed to reproduce.

Ok, I know what's going on. Very roughly, we need something like the below
to check for overflows, this definitely fixes it for me. Cooking a proper
patch and doing some more analysis around it.

diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index aaa3198..454f52c 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -76,11 +76,17 @@ static struct bpf_map *array_map_alloc(union bpf_attr *attr)
max_entries = attr->max_entries;
index_mask = roundup_pow_of_two(max_entries) - 1;

-   if (unpriv)
+   if (unpriv) {
/* round up array size to nearest power of 2,
 * since cpu will speculate within index_mask limits
 */
max_entries = index_mask + 1;
+   if (max_entries < attr->max_entries)
+   return ERR_PTR(-E2BIG);
+   }

array_size = sizeof(*array);
if (percpu)

Re: general protection fault in cgroup_fd_array_put_ptr

[Daniel Borkmann]

On 01/10/2018 04:30 PM, Daniel Borkmann wrote:
> On 01/10/2018 01:58 PM, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on b4464bcab38d3f7fe995a7cb960eeac6889bec08
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
> 
> Currently looking into all of the reports. Looks they're all related to fd 
> array
> map. Will get back once I have some more data & managed to reproduce.

Ok, I know what's going on. Very roughly, we need something like the below
to check for overflows, this definitely fixes it for me. Cooking a proper
patch and doing some more analysis around it.

diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index aaa3198..454f52c 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -76,11 +76,17 @@ static struct bpf_map *array_map_alloc(union bpf_attr *attr)
max_entries = attr->max_entries;
index_mask = roundup_pow_of_two(max_entries) - 1;

-   if (unpriv)
+   if (unpriv) {
/* round up array size to nearest power of 2,
 * since cpu will speculate within index_mask limits
 */
max_entries = index_mask + 1;
+   if (max_entries < attr->max_entries)
+   return ERR_PTR(-E2BIG);
+   }

array_size = sizeof(*array);
if (percpu)

Re: general protection fault in cgroup_fd_array_put_ptr

[Daniel Borkmann]

On 01/10/2018 01:58 PM, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on b4464bcab38d3f7fe995a7cb960eeac6889bec08
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

Currently looking into all of the reports. Looks they're all related to fd array
map. Will get back once I have some more data & managed to reproduce.

Thanks,
Daniel

Re: general protection fault in cgroup_fd_array_put_ptr

[Daniel Borkmann]

On 01/10/2018 01:58 PM, syzbot wrote:
> Hello,
> 
> syzkaller hit the following crash on b4464bcab38d3f7fe995a7cb960eeac6889bec08
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> C reproducer is attached
> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
> for information about syzkaller reproducers

Currently looking into all of the reports. Looks they're all related to fd array
map. Will get back once I have some more data & managed to reproduce.

Thanks,
Daniel

Re: [PATCH][bpf-next] bpf: fix spelling mistake: "obusing" -> "abusing"

[Daniel Borkmann]

On 01/10/2018 10:20 AM, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in error message text.
> 
> Signed-off-by: Colin Ian King 
> ---
>  kernel/bpf/verifier.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 97bbef3eecdf..e388f30c4168 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5336,7 +5336,7 @@ static int fixup_bpf_calls(struct bpf_verifier_env *env)
>*/
>   map_ptr = env->insn_aux_data[i + delta].map_ptr;
>   if (map_ptr == BPF_MAP_PTR_POISON) {
> - verbose(env, "tail_call obusing map_ptr\n");
> + verbose(env, "tail_call abusing map_ptr\n");
>   return -EINVAL;
>   }
>   if (!map_ptr->unpriv_array)
> 

This is not in bpf-next tree yet, but only in bpf tree. I will let this sit
for a bit in patchwork until bpf-next has all the stuff from bpf merged back,
and then apply it into bpf-next.

Thanks,
Daniel