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: <CA+55aFzZKnEmqiYUjiNDvy470yau3XmitOnH5t0F5Upn9mrEAw@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ