linux-kernel - Re: possible deadlock in skb_queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 4 Apr 2018 21:00:16 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Kirill Tkhai <ktkhai@...tuozzo.com>,
        Ingo Molnar <mingo@...nel.org>,
        syzbot <syzbot+6b495100f17ca8554ab9@...kaller.appspotmail.com>,
        David Miller <davem@...emloft.net>,
        David Herrmann <dh.herrmann@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        David Windsor <dwindsor@...il.com>,
        "Reshetova, Elena" <elena.reshetova@...el.com>,
        Hans Liljestrand <ishkamiel@...il.com>,
        Kees Cook <keescook@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Matthew Dawson <matthew@...systems.ca>,
        Mateusz Jurczyk <mjurczyk@...gle.com>,
        netdev <netdev@...r.kernel.org>, syzkaller-bugs@...glegroups.com,
        Al Viro <viro@...iv.linux.org.uk>, xemul@...tuozzo.com
Subject: Re: possible deadlock in skb_queue_tail

On Wed, Apr 4, 2018 at 7:08 AM, Cong Wang <xiyou.wangcong@...il.com> wrote:
> On Tue, Apr 3, 2018 at 4:42 AM, Kirill Tkhai <ktkhai@...tuozzo.com> wrote:
>> On 03.04.2018 14:25, Dmitry Vyukov wrote:
>>> On Tue, Apr 3, 2018 at 11:50 AM, Kirill Tkhai <ktkhai@...tuozzo.com> wrote:
>>>> sk_diag_dump_icons() dumps only sockets in TCP_LISTEN state.
>>>> TCP_LISTEN state may be assigned in only place in net/unix/af_unix.c:
>>>> it's unix_listen(). The function is applied to stream and seqpacket
>>>> socket types.
>>>>
>>>> It can't be stream because of the second stack, and seqpacket also can't,
>>>> as I don't think it's possible for gcc to inline unix_seqpacket_sendmsg()
>>>> in the way, we don't see it in the stack.
>>>>
>>>> So, this is looks like false positive result for me.
>>>>
>>>> Kirill
>>>
>>> Do you mean that these &(&u->lock)->rlock/1 referenced in 2 stacks are
>>> always different?
>>
>> In these 2 particular stacks they have to be different.
>
> So actually my patch could fix this false positive? I thought it couldn't.
> https://patchwork.ozlabs.org/patch/894342/

You know better!
If you suspect it can fix this report, and nobody has better
proposals, then we can just mark this as being fixed with your commit
and then see if it triggers again with your commit or not.