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

Message-ID: <CAM_iQpWFGsXdC2qHfMLHy_0y3jEZxToxkSWYhj2_uQpTurPvdQ@mail.gmail.com>
Date:   Tue, 31 Oct 2017 20:19:51 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     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 Mon, Oct 30, 2017 at 7:08 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Mon, Oct 30, 2017 at 6:19 PM, Cong Wang <xiyou.wangcong@...il.com> wrote:
>>
>> 1. The faulty addresses are all near 0000000100000000, with one exception
>> of null (which is the most recent one)
>
> Well, they're at 8(%rax), except for that last case.
>
> And in every case (_including_ that last case), %rax has a very
> interesting pattern.. That's the (bad) buf->ops pointer that  was
> loaded from the somehow corrupted "buf".
>
> The values in all cases are
>
> 00000000fffffffa
> 00000000fffffffd
> 00000000fffffff1
> 00000000fffffff7
> 00000000fffffff4
> 00000000fffffffa
> 00000000fffffffd
> 00000000fffffffd
> 00000000fffffffa
> 00000000ffffffe8
> 00000000fffffff1
> 00000000fffffff7
>
> which kind of looks like a 32-bit error value. So we have (n, val, (errno)):
>
>       1 -24 (EMFILE)
>       2 -15 (ENOTBLK)
>       1 -12 (ENOMEM)
>       2 -9 (EBADF)
>       3 -6 (ENXIO)
>       3 -3 (ESRCH)
>
> none of which makes any sense to me, but it's an interesting pattern
> nonetheless.


Yeah, good find!


>
>> 2. R12 register, which should map to the local vairable 'i', is always 0x8
>> at the time of crash.
>
> So _if_ this is some kind of use-after-free thing, and the allocation
> got re-used for something else, that might just be related to whatever
> ends up being the offset that is filled in with the (int) error
> number.
>
> Except the offset is that %r12*0x28+0x10, so we're talking a byte
> offset of 330 bytes into the allocation, and apparently the eight
> previous (0-7) iterations were fine.
>
> Which is really odd.
>
> I'm not seeing anything that makes sense. I'll have to think about this.
>
> I'm assuming you don't have slub debugging enabled, and no way to
> enable it and try to catch this?

We enable it at compile-time but not at run-time:

CONFIG_SLUB_DEBUG=y
CONFIG_SLUB=y
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set

I can try to manually add slub_debug in boot parameters, but still
have no idea how and when can trigger this bug again.


Thanks!