linux-kernel - Re: [inotify] fee1df54b6: BUG_kmalloc-#(Not_tainted):Freepointer

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:   Tue, 13 Dec 2016 21:34:35 +0200
From:   Nikolay Borisov <n.borisov.lkml@...il.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Jan Kara <jack@...e.cz>, containers@...ts.linux-foundation.org,
        LKML <linux-kernel@...r.kernel.org>,
        Serge Hallyn <serge@...lyn.com>, avagin@...nvz.org
Subject: Re: [inotify] fee1df54b6:
 BUG_kmalloc-#(Not_tainted):Freepointer_corrupt



On 13.12.2016 20:51, Eric W. Biederman wrote:
> Nikolay Borisov <n.borisov.lkml@...il.com> writes:
> 
>> So this thing resurfaced again and I took a hard look into the code but
>> couldn't find anything suspicious. So the allocating and freeing
>> contexts leads me to believe it's the 'tbl' pointer that is being
>> corrupted. The only thing which I do with it is to increase it by two.
>>
>> Perhaps some liveness issues.
> 
> To me it feels like a double free somewhere.  Like we call dec_ucount
> and thus put_ucount multiple times in a way that goes to 0.
> 
> Perhaps there is a peculiarity in the existing code which allows the
> count to go to zero which we don't notice because we don't free anything
> when the count goes to zero today.
> 
> Perhaps there is some subtle semantic mismatch between your conversion
> and the inotify code.
> 
> I don't know if you made a subtle misreading of the code, or if
> there is an existing bug that your changes took from harmless to
> problematic, but the evidence is overwhelming that something
> is going wrong and it is your patch that brings it out.
> 
> If it helps the openvz folks apparently reproduced this with the criu
> regression tests and the appropriate kernel debug options, and confirmed
> the failure was your patch.

Great but I think I missed this conversation, care to send relevant
threads? I'd like to get to the bottom of this and have it merged?

@openvz guys - if you care to shout with more details I'd love to work
on getting this fixed!

> 
> The current state of play is that I would love to merge this if we can
> track down this issue.  I dropped this from my tree before I sent my pull
> request to Linus so there is no emergency to get this fixed.
> 
> Eric
> 
>