linux-kernel - Futex and get_user_pages error conditions

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>] [day] [month] [year] [list]

Message-ID: <52E7A8B3.5060105@redhat.com>
Date:	Tue, 28 Jan 2014 13:55:15 +0100
From:	Florian Weimer <fweimer@...hat.com>
To:	linux-kernel@...r.kernel.org
Subject: Futex and get_user_pages error conditions

We currently do not deal with futex operation failures inside glibc, at 
least not for the glibc-internal locks.  (I noticed this while reading 
the code, my question is not prompted by real-world failures.)  In 
general, glibc will ensure that preconditions are met and handles some 
expected errors, or behavior is undefined user code doesn't ensure them, 
but there are some errors which are impossible to prevent by careful 
programming, such as memory allocation failures.

I looked at the kernel implementation, and noticed that in the guts of 
the get_user_pages implementation, it can return ENOMEM.  Does this 
actually affect futexes, especially the plain (non-PI, 
non-cross-process) variant?

Are there any other error conditions we should handle inside glibc?  We 
really need a fast, async-signal-safe locking primitive where locking 
and unlocking cannot fail (after suitable set-up).

-- 
Florian Weimer / Red Hat Product Security Team
--
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/