netdev - Re: possible deadlock in ipv6_sock_mc

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 1 Mar 2021 16:04:13 +0100
From:   Matthieu Baerts <matthieu.baerts@...sares.net>
To:     Chuck Lever <chuck.lever@...cle.com>,
        syzbot <syzbot+e2fa57709a385e6db10f@...kaller.appspotmail.com>
Cc:     Bruce Fields <bfields@...ldses.org>,
        "David S. Miller" <davem@...emloft.net>,
        "dsahern@...nel.org" <dsahern@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        Linux-Net <netdev@...r.kernel.org>,
        "yoshfuji@...ux-ipv6.org" <yoshfuji@...ux-ipv6.org>,
        "syzkaller-bugs@...glegroups.com" <syzkaller-bugs@...glegroups.com>,
        MPTCP Upstream <mptcp@...ts.01.org>
Subject: Re: possible deadlock in ipv6_sock_mc_close

Hi Chuck,

(+ cc: MPTCP list)

On 01/03/2021 15:52, Chuck Lever wrote:
>> On Mar 1, 2021, at 8:49 AM, syzbot <syzbot+e2fa57709a385e6db10f@...kaller.appspotmail.com> wrote:

(...)

>> syzbot found the following issue on:

(...)

> Hi, thanks for the report.
> 
> Initial analysis:
> 
> c8e88e3aa738 ("NFSD: Replace READ* macros in nfsd4_decode_layoutget()"
> changes code several layers above the network layer. In addition,
> neither of the stack traces contain NFSD functions. And, repro.c does
> not appear to exercise any filesystem code.
> 
> Therefore the bisect result looks implausible to me. I don't see any
> obvious connection between the lockdep splat and c8e88e3aa738. (If
> someone else does, please let me know where to look).

 From what I can see from the bisect logs, it looks like this issue is 
difficult to reproduce. But it really looks like the issue is on MPTCP 
side and not directly related to your patch.

Thanks to the syzbot team for reporting this!

It doesn't look very simple to fix but we are tracking this on our side: 
https://github.com/multipath-tcp/mptcp_net-next/issues/170

Cheers,
Matt
-- 
Tessares | Belgium | Hybrid Access Solutions
www.tessares.net