linux-kernel - Re: 3.11.4: kernel BUG at fs/buffer.c:1268

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: <20131009172336.GH13318@ZenIV.linux.org.uk>
Date:	Wed, 9 Oct 2013 18:23:36 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Jan Kara <jack@...e.cz>
Cc:	George Spelvin <linux@...izon.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: 3.11.4: kernel BUG at fs/buffer.c:1268

On Wed, Oct 09, 2013 at 05:18:53PM +0200, Jan Kara wrote:

>   This is really weird. We are delivering a signal to a task. While task is

ITYM "a fatal signal"

> returning from kernel space we are running queued task works and one of

get_signal_to_deliver() notices that the signal has to be dealt with
via default reaction, which happens to be "die, you bastard".  So it
calls do_group_exit().  Which means that we'll never be returning to userland,
so the time to run pending __fput() is now.

> that works is dropping last file reference. Ext4 then does some data
> flushing and at that point we find out irqs are disabled. It isn't really
> clear to me where in that call chain got irqs disabled. I went through it
> and didn't find any such place... If this is reproducible, there would be
> ways to debug this (like irq tracing). Otherwise I'm not sure... I'm CCing
> Al since he was digging in this code recently. Maybe he will have some
> idea.

Note that do_group_exit() is preceded by
                spin_unlock_irq(&sighand->siglock);
so no matter what happened in callers, irq is enabled.  I'd suggest sticking
such BUG_ON() into __fput() and trying to reproduce that crap...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/