linux-kernel - Re: Kernel panic - not syncing: Fatal exception in interrupt (file_free

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:   Thu, 28 Sep 2017 21:00:52 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kyle Sanderson <kyle.leet@...il.com>
Cc:     Linux-Kernal <linux-kernel@...r.kernel.org>,
        Paul McKenney <paulmck@...ux.vnet.ibm.com>
Subject: Re: Kernel panic - not syncing: Fatal exception in interrupt (file_free_rcu+0x14)

On Thu, Sep 28, 2017 at 8:32 PM, Kyle Sanderson <kyle.leet@...il.com> wrote:
> Not sure if the stack is crap or not, but this looks like an RCU crash?
>
> https://i.imgur.com/sBnNe1p.jpg

Hmm. Not the clearest picture, and the "Code:" line in particular is
missing the interesting part, but at a guess it's taking a fault in
put_cred(), which inlines to

        if (atomic_dec_and_test(&(cred)->usage))
                __put_cred(cred);

and I think it's that "cred" pointer that may be NULL, which makes
"&(cred)->usage" be a NULL pointer too, and you get a page fault when
it tries to decrement the usage count.

Now, it goes without saying that the cred pointer should never *be*
NULL on a filp that is on the RCU freeing list, because we always
initialize file->f_cred when we allocate a file to the current creds.

So there's something odd going on. Possibly entirely unrelated memory
corruption.

Nothing obvious stands out, I think we'd need to see more of a pattern
of the problem to see what is up.

                 Linus