On Wed, Sep 27, 2017 at 3:26 PM, 'Eric Dumazet' via syzkaller
wrote:
> On Wed, Sep 27, 2017 at 5:58 AM, Alexander Potapenko
> wrote:
>> On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet wrote:
>>> On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
>>>
Or something cleaner to avoid copy/pas
On Wed, Sep 27, 2017 at 5:58 AM, Alexander Potapenko wrote:
> On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet wrote:
>> On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
>>
>>> Or something cleaner to avoid copy/paste and focus on proper
>>> skb->data[0] access and meaning.
> By the way I'm wo
On Wed, Sep 27, 2017 at 2:45 PM, Eric Dumazet wrote:
> On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
>
>> Or something cleaner to avoid copy/paste and focus on proper
>> skb->data[0] access and meaning.
By the way I'm wondering if this is the only place where skb->data is
being accessed.
On Wed, 2017-09-27 at 05:42 -0700, Eric Dumazet wrote:
> Or something cleaner to avoid copy/paste and focus on proper
> skb->data[0] access and meaning.
>
> Thanks.
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index
> 3c9985f299503ea65dad7eb3b47e2ab3bef87800..8ddb840687c1bdb24e41826
On Wed, 2017-09-27 at 14:16 +0200, Alexander Potapenko wrote:
> KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
> skb->data[0] in the case the skb is empty (i.e. skb->len is 0):
>
> Signed-off-by: Alexander Potapenko
> ---
> v2: free the skb
> ---
> drivers/net/tun.c |
KMSAN (https://github.com/google/kmsan) reported accessing uninitialized
skb->data[0] in the case the skb is empty (i.e. skb->len is 0):
BUG: KMSAN: use of uninitialized memory in tun_get_user+0x19ba/0x3770
CPU: 0 PID: 3051 Comm: probe Not tainted 4
