On 1/8/19 12:14 PM, Eric Dumazet wrote:
> On Tue, Jan 8, 2019 at 3:08 AM Piotr Sawicki
> wrote:
>
>> Yes I know. It looks like the Smack's security rule was changed during this
>> process.
>>
>> Firstly the packet was allowed to be received and it was put into the
>> backlog queue. Then, the
On Tue, Jan 8, 2019 at 3:08 AM Piotr Sawicki
wrote:
> Yes I know. It looks like the Smack's security rule was changed during this
> process.
>
> Firstly the packet was allowed to be received and it was put into the backlog
> queue. Then, the
>
> rule was changed, and during the release phase L
On 1/8/19 11:48 AM, Eric Dumazet wrote:
> On Tue, Jan 8, 2019 at 2:36 AM Piotr Sawicki
> wrote:
>>
>> On 1/8/19 11:06 AM, Eric Dumazet wrote:
>>> On Tue, Jan 8, 2019 at 1:47 AM Piotr Sawicki
>>> wrote:
On 1/8/19 10:21 AM, Eric Dumazet wrote:
> On Tue, Jan 8, 2019 at 12:57 AM Piotr Sawi
On Tue, Jan 8, 2019 at 2:36 AM Piotr Sawicki
wrote:
>
>
> On 1/8/19 11:06 AM, Eric Dumazet wrote:
> > On Tue, Jan 8, 2019 at 1:47 AM Piotr Sawicki
> > wrote:
> >>
> >> On 1/8/19 10:21 AM, Eric Dumazet wrote:
> >>> On Tue, Jan 8, 2019 at 12:57 AM Piotr Sawicki
> >>> wrote:
> dccp_v6_rcv() ca
On 1/8/19 11:06 AM, Eric Dumazet wrote:
> On Tue, Jan 8, 2019 at 1:47 AM Piotr Sawicki
> wrote:
>>
>> On 1/8/19 10:21 AM, Eric Dumazet wrote:
>>> On Tue, Jan 8, 2019 at 12:57 AM Piotr Sawicki
>>> wrote:
dccp_v6_rcv() calls __sk_receive_skb() which calls sk_filter_trim_cap().
sk_f
On Tue, Jan 8, 2019 at 1:47 AM Piotr Sawicki
wrote:
>
>
> On 1/8/19 10:21 AM, Eric Dumazet wrote:
> > On Tue, Jan 8, 2019 at 12:57 AM Piotr Sawicki
> > wrote:
> >> dccp_v6_rcv() calls __sk_receive_skb() which calls sk_filter_trim_cap().
> >>
> >> sk_filter_trim_cap() should return a value not equ
On 1/8/19 10:21 AM, Eric Dumazet wrote:
> On Tue, Jan 8, 2019 at 12:57 AM Piotr Sawicki
> wrote:
>> dccp_v6_rcv() calls __sk_receive_skb() which calls sk_filter_trim_cap().
>>
>> sk_filter_trim_cap() should return a value not equal to 0 and cause the skb
>> to be dropped, since icmpv6_send() is
On Tue, Jan 8, 2019 at 12:57 AM Piotr Sawicki
wrote:
>
> dccp_v6_rcv() calls __sk_receive_skb() which calls sk_filter_trim_cap().
>
> sk_filter_trim_cap() should return a value not equal to 0 and cause the skb
> to be dropped, since icmpv6_send() is called when smack_socket_sock_rcv_skb()
> retu
dccp_v6_rcv() calls __sk_receive_skb() which calls sk_filter_trim_cap().
sk_filter_trim_cap() should return a value not equal to 0 and cause the skb to
be dropped, since icmpv6_send() is called when smack_socket_sock_rcv_skb()
returns -EACCES.
So, the packet shouldn't be put into the backlog qu
From: Eric Dumazet
Date: Fri, 4 Jan 2019 11:00:00 -0800
> syzbot was able to crash one host with the following stack trace :
...
> This is because a RX packet found socket owned by user and
> was stored into socket backlog. Before leaving RCU protected section,
> skb->dev was cleared in __sk_re
On 1/4/2019 11:38 AM, Eric Dumazet wrote:
> On Fri, Jan 4, 2019 at 11:36 AM Casey Schaufler
> wrote:
>> On 1/4/2019 11:00 AM, Eric Dumazet wrote:
>>> syzbot was able to crash one host with the following stack trace :
>>>
>>> kasan: GPF could be caused by NULL-ptr deref or user memory access
>>> g
On Fri, Jan 4, 2019 at 11:36 AM Casey Schaufler wrote:
>
> On 1/4/2019 11:00 AM, Eric Dumazet wrote:
> > syzbot was able to crash one host with the following stack trace :
> >
> > kasan: GPF could be caused by NULL-ptr deref or user memory access
> > general protection fault: [#1] PREEMPT SMP
On 1/4/2019 11:00 AM, Eric Dumazet wrote:
> syzbot was able to crash one host with the following stack trace :
>
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 8625 Comm: syz-executor4 Not tainted 4.20.0+ #8
syzbot was able to crash one host with the following stack trace :
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 0 PID: 8625 Comm: syz-executor4 Not tainted 4.20.0+ #8
RIP: 0010:dev_net include/linux/netdevice.h:2169 [
14 matches
Mail list logo