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]

Message-ID: <87oa0fpsqs.fsf@xmission.com>
Date:   Wed, 14 Dec 2016 07:51:39 +1300
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Nikolay Borisov <n.borisov.lkml@...il.com>
Cc:     Jan Kara <jack@...e.cz>, containers@...ts.linux-foundation.org,
        LKML <linux-kernel@...r.kernel.org>,
        Serge Hallyn <serge@...lyn.com>
Subject: Re: [inotify] fee1df54b6: BUG_kmalloc-#(Not_tainted):Freepointer_corrupt

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.

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