linux-kernel - Re: GPF in net sybsystem

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]

Message-ID: <CAM_iQpUSek_wYBCbnuDRF8AB5vTVPppsLaeYa9jt2dqidYSWhg@mail.gmail.com>
Date:   Thu, 6 May 2021 17:40:30 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Pavel Skripkin <paskripkin@...il.com>
Cc:     Ralf Baechle <ralf@...ux-mips.org>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: GPF in net sybsystem

On Wed, May 5, 2021 at 10:36 AM Pavel Skripkin <paskripkin@...il.com> wrote:
>
> Hi, netdev developers!
>
> I've spent some time debugging this bug
> https://syzkaller.appspot.com/bug?id=c670fb9da2ce08f7b5101baa9426083b39ee9f90
> and, I believe, I found the root case:
>
> static int nr_accept(struct socket *sock, struct socket *newsock, int flags,
>                      bool kern)
> {
> ....
>         for (;;) {
>                 prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
>                 ...
>                 if (!signal_pending(current)) {
>                         release_sock(sk);
>                         schedule();
>                         lock_sock(sk);
>                         continue;
>                 }
>                 ...
>         }
> ...
> }
>
> When calling process will be scheduled, another proccess can release
> this socket and set sk->sk_wq to NULL. (In this case nr_release()
> will call sock_orphan(sk)). In this case GPF will happen in
> prepare_to_wait().

Are you sure?

How could another process release this socket when its fd is still
refcnt'ed? That is, accept() still does not return yet at the point of
schedule().

Also, the above pattern is pretty common in networking subsystem,
see sk_wait_event(), so how come it is only problematic for netrom?

Thanks.