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
| ||
|
Date: Tue, 8 Aug 2017 16:32:30 +0100 From: Mel Gorman <mgorman@...e.de> To: Mark Rutland <mark.rutland@....com> Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>, Davidlohr Bueso <dbueso@...e.de>, Thomas Gleixner <tglx@...utronix.de>, Chris Mason <clm@...com>, Darren Hart <dvhart@...ux.intel.com>, Hugh Dickins <hughd@...gle.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Peter Zijlstra <peterz@...radead.org>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, dave@...olabs.net Subject: Re: kernel BUG at kernel/futex.c:679 on v4.13-rc3-ish on arm64 On Tue, Aug 08, 2017 at 11:52:05AM +0100, Mark Rutland wrote: > Hi, > > As a heads-up, I hit the below splat when using Syzkaller to fuzz arm64 > VMAP_STACK patches [1] atop of v4.13-rc3. I haven't hit anything else > major, and so far I haven't had any luck reproducing this, so it may be > an existing issue that's difficult to hit. > > Note that while reported as a BUG(), it's actually the WARN_ON_ONCE() > introduced in commit: > > 65d8fc777f6dcfee ("futex: Remove requirement for lock_page() in get_futex_key()") > > ... misreported as I accidentally throw away the flags in __BUG_FLAGS(). > Other than that, I believe BUG() and friends are working correctly. > > The Syzkaller log is huge (1.0M), so rather than attaching it, I've > uploaded the log, report, and kernel config to: > > http://data.yaey.co.uk/bugs/20170808-futex-bug/ > > I'll continue trying to reproduce and minimize this. > > ------------[ cut here ]------------ > kernel BUG at kernel/futex.c:679! This corresponds to the warning /* * Take a reference unless it is about to be freed. Previously * this reference was taken by ihold under the page lock * pinning the inode in place so i_lock was unnecessary. The * only way for this check to fail is if the inode was * truncated in parallel so warn for now if this happens. * * We are not calling into get_futex_key_refs() in file-backed * cases, therefore a successful atomic_inc return below will * guarantee that get_futex_key() will still imply smp_mb(); (B). */ if (WARN_ON_ONCE(!atomic_inc_not_zero(&inode->i_count))) { rcu_read_unlock(); put_page(page); goto again; } The comment is pretty self-explanatory. The only situation I could think of where it could happen is if a futex existed on a shared mapping that was truncated during the operation. Why would an application truncate a mapping with a key on it? As weird as it is, the situation is recoverable which is what the code does but the warning was included in case I was not imaginative enough. Can you tell me if it's possible that syskaller when fuzz testing was creating a shared mapping, creating a futex backed by the mapping and truncating it? If so and that's what triggers the warning then I think it would be reasonable to remove the warning as the source of the confusion is userspace truncating a mapping with active keys on it. If you manage to create a test case, then it would be nice to test without that warning and see if it completes successfully or if there is other fallout. -- Mel Gorman SUSE Labs
Powered by blists - more mailing lists