linux-kernel - Re: Kernel crash in free_pipe

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:   Fri, 10 Nov 2017 11:47:43 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Simon Brewer <sbrunau@...il.com>
Cc:     Cong Wang <xiyou.wangcong@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Kernel crash in free_pipe_info()

On Thu, Nov 9, 2017 at 10:07 PM, Simon Brewer <sbrunau@...il.com> wrote:
>
> This looks familiar...
>
> https://github.com/moby/moby/issues/34472
>
> From the bug report:
> "In particular, it looks like either docker-containerd or
> docker-containerd-shim (the log is cut off) has a pipe open that is
> causing a kernel BUG when attempting to kill the process. Fun times."

Interestingly, some of the "reproducers" show a totally different problem, with

  kernel BUG at /build/linux-5EyXrQ/linux-4.4.0/mm/slub.c:1495!

which is this BUG():

  1493          if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
  1494                  pr_emerg("gfp: %u\n", flags & GFP_SLAB_BUG_MASK);
  1495                  BUG();
  1496          }

which implies a completely invalid gfp mask.

The stack trace shows it's unix_stream_sendmsg -> sock_alloc_send_pskb
allocation, which uses "sk->sk_allocation".

Odd. af_unix just does

        sk->sk_allocation       = GFP_KERNEL_ACCOUNT;

That is new since v4.4, though - but before that it should have been
set by sock_init_data to just GFP_KERNEL.

So there it looks like a socket is entirely corrupted.

So that other backtrace looks entirely bogus too. More "that looks
like corrupted kernel data structures".

Enabling SLUB debugging would be really good here too.

But that is still quite an old kernel. I wish somebody could reproduce
this with something newer.

I added those wishes to the github thing.

             Linus