On 12/03/2018 03:52 PM, David Miller wrote:
> From: Ido Schimmel
> Date: Fri, 30 Nov 2018 19:00:24 +0200
>
>> Yes, agree. Patch is good. I'll tag your v2.
>
> This means, I assume, that a new version of this fix is coming.
>
> Eric, is this correct?
>
This is absolutely correct David, I wi
From: Ido Schimmel
Date: Fri, 30 Nov 2018 19:00:24 +0200
> Yes, agree. Patch is good. I'll tag your v2.
This means, I assume, that a new version of this fix is coming.
Eric, is this correct?
On Fri, Nov 30, 2018 at 08:17:04AM -0800, Eric Dumazet wrote:
> On Fri, Nov 30, 2018 at 8:10 AM Dmitry Vyukov wrote:
> >
> > On Fri, Nov 30, 2018 at 4:02 PM, Ido Schimmel wrote:
> > > On Fri, Nov 30, 2018 at 08:59:09AM -0700, David Ahern wrote:
> > >> This does not repro for me:
> > >> # ./a.out
On Fri, Nov 30, 2018 at 8:10 AM Dmitry Vyukov wrote:
>
> On Fri, Nov 30, 2018 at 4:02 PM, Ido Schimmel wrote:
> > On Fri, Nov 30, 2018 at 08:59:09AM -0700, David Ahern wrote:
> >> This does not repro for me:
> >> # ./a.out
> >> Invalid address length 6 - must be 4 bytes
> >> RTNETLINK answers: No
On Fri, Nov 30, 2018 at 4:02 PM, Ido Schimmel wrote:
> On Fri, Nov 30, 2018 at 08:59:09AM -0700, David Ahern wrote:
>> This does not repro for me:
>> # ./a.out
>> Invalid address length 6 - must be 4 bytes
>> RTNETLINK answers: No buffer space available
>> RTNETLINK answers: Operation not supporte
On Fri, Nov 30, 2018 at 08:59:09AM -0700, David Ahern wrote:
> This does not repro for me:
> # ./a.out
> Invalid address length 6 - must be 4 bytes
> RTNETLINK answers: No buffer space available
> RTNETLINK answers: Operation not supported
> Invalid address length 6 - must be 4 bytes
> Invalid addr
On Fri, Nov 30, 2018 at 07:51:34AM -0800, Eric Dumazet wrote:
> On Fri, Nov 30, 2018 at 7:46 AM Eric Dumazet wrote:
> >
> > On Fri, Nov 30, 2018 at 7:40 AM Eric Dumazet wrote:
> > >
> > > On Fri, Nov 30, 2018 at 7:36 AM David Ahern wrote:
> > > >
> > > > On 11/30/18 7:58 AM, Ido Schimmel wrote:
On 11/30/18 8:14 AM, Eric Dumazet wrote:
>
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
>
> #define _GNU_SOURCE
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
On Fri, Nov 30, 2018 at 7:46 AM Eric Dumazet wrote:
>
> On Fri, Nov 30, 2018 at 7:40 AM Eric Dumazet wrote:
> >
> > On Fri, Nov 30, 2018 at 7:36 AM David Ahern wrote:
> > >
> > > On 11/30/18 7:58 AM, Ido Schimmel wrote:
> > > > Can you please share the reproducer (assuming it exists)? I don't re
On Fri, Nov 30, 2018 at 7:40 AM Eric Dumazet wrote:
>
> On Fri, Nov 30, 2018 at 7:36 AM David Ahern wrote:
> >
> > On 11/30/18 7:58 AM, Ido Schimmel wrote:
> > > Can you please share the reproducer (assuming it exists)? I don't really
> > > understand the fix. None of the functions you patched ar
On Fri, Nov 30, 2018 at 7:36 AM David Ahern wrote:
>
> On 11/30/18 7:58 AM, Ido Schimmel wrote:
> > Can you please share the reproducer (assuming it exists)? I don't really
> > understand the fix. None of the functions you patched are in the trace.
> > Also, looking at IPv4 GRE code, while GRE dev
On 11/30/18 7:58 AM, Ido Schimmel wrote:
> Can you please share the reproducer (assuming it exists)? I don't really
> understand the fix. None of the functions you patched are in the trace.
> Also, looking at IPv4 GRE code, while GRE device has dev->addr_len set
> to 4, dev->type is set to ARPHRD_I
On Fri, Nov 30, 2018 at 6:58 AM Ido Schimmel wrote:
>
> On Fri, Nov 30, 2018 at 05:35:01AM -0800, 'Eric Dumazet' via syzkaller wrote:
> > Commit da71577545a5 ("rtnetlink: Disallow FDB configuration
> > for non-Ethernet device") added a test against dev->type.
> >
> > kmsan was still able to trigge
On Fri, Nov 30, 2018 at 05:35:01AM -0800, 'Eric Dumazet' via syzkaller wrote:
> Commit da71577545a5 ("rtnetlink: Disallow FDB configuration
> for non-Ethernet device") added a test against dev->type.
>
> kmsan was still able to trigger a kernel-infoleak using a gre device,
> with a correct device
Commit da71577545a5 ("rtnetlink: Disallow FDB configuration
for non-Ethernet device") added a test against dev->type.
kmsan was still able to trigger a kernel-infoleak using a gre device,
with a correct device type (ARPHRD_ETHER), but with a not
correct dev->addr_len (4 bytes instead of the expect
15 matches
Mail list logo