linux-kernel - Re: bio linked list corruption.

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, 24 Oct 2016 18:02:35 -0400
From:   Chris Mason <clm@...com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...capital.net>
CC:     Dave Jones <davej@...emonkey.org.uk>,
        Andy Lutomirski <luto@...nel.org>, Jens Axboe <axboe@...com>,
        Al Viro <viro@...iv.linux.org.uk>, Josef Bacik <jbacik@...com>,
        David Sterba <dsterba@...e.com>,
        linux-btrfs <linux-btrfs@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: bio linked list corruption.

On 10/24/2016 05:50 PM, Linus Torvalds wrote:
> On Mon, Oct 24, 2016 at 2:17 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> The vmalloc/vfree code itself is a bit scary. In particular, we have a
>> rather insane model of TLB flushing. We leave the virtual area on a
>> lazy purge-list, and we delay flushing the TLB and actually freeing
>> the virtual memory for it so that we can batch things up.
>
> Never mind. If DaveJ is running with DEBUG_PAGEALLOC, then the code in
> vmap_debug_free_range() should have forced a synchronous TLB flush fro
> vmalloc ranges too, so that doesn't explain it either.
>

My big fear here is that we're just triggering an old stack corruption 
more reliably.  I wonder if we can make it happen much faster by 
restricting the stacks to a static list and cycling through them in lifo 
fashion?

-chris