Linux Kernel forbid uaddr == uaddr2 in futex_wait_requeue_pi() null dereference

2014.05.15
Credit: Darren
Risk: Medium
Local: Yes
Remote: No
CWE: CWE-20


CVSS Base Score: 4.9/10
Impact Subscore: 6.9/10
Exploitability Subscore: 3.9/10
Exploit range: Local
Attack complexity: Low
Authentication: No required
Confidentiality impact: None
Integrity impact: None
Availability impact: Complete

Hello, Linux kernel built with the fast userspace mutexes(CONFIG_FUTEX) support is vulnerable to a NULL pointer dereference flaw. It could occur when a waiting task requests wait to be re-queued from non-PI futex to a PI-aware futex via FUTEX_WAIT_REQUEUE_PI operation. An unprivileged user/program could use this flaw to crash the system kernel resulting in DoS. Upstream fix: ------------- -> https://git.kernel.org/linus/6f7b0a2a5c0fb03be7c25bd1745baa50582348ef If uaddr == uaddr2, then we have broken the rule of only requeueing from a non-pi futex to a pi futex with this call. If we attempt this, as the trinity test suite manages to do, we miss early wakeups as q.key is equal to key2 (because they are the same uaddr). We will then attempt to dereference the pi_mutex (which would exist had the futex_q been properly requeued to a pi futex) and trigger a NULL pointer dereference. diff --git a/kernel/futex.c b/kernel/futex.c index 5551ada..3717e7b 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -2231,11 +2231,11 @@ int handle_early_requeue_pi_wakeup(struct futex_hash_bucket *hb, * @uaddr2: the pi futex we will take prior to returning to user-space * * The caller will wait on uaddr and will be requeued by futex_requeue() to - * uaddr2 which must be PI aware. Normal wakeup will wake on uaddr2 and - * complete the acquisition of the rt_mutex prior to returning to userspace. - * This ensures the rt_mutex maintains an owner when it has waiters; without - * one, the pi logic wouldn't know which task to boost/deboost, if there was a - * need to. + * uaddr2 which must be PI aware and unique from uaddr. Normal wakeup will wake + * on uaddr2 and complete the acquisition of the rt_mutex prior to returning to + * userspace. This ensures the rt_mutex maintains an owner when it has waiters; + * without one, the pi logic would not know which task to boost/deboost, if + * there was a need to. * * We call schedule in futex_wait_queue_me() when we enqueue and return there * via the following: @@ -2272,6 +2272,9 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, unsigned int flags, struct futex_q q = futex_q_init; int res, ret; + if (uaddr == uaddr2) + return -EINVAL; + if (!bitset) return -EINVAL; Introduced in: -------------- -> https://git.kernel.org/linus/52400ba946759af28442dee6265c5c0180ac7122 Thank you. -- Prasad J Pandit / Red Hat Security Response Team

References:

https://git.kernel.org/linus/6f7b0a2a5c0fb03be7c25bd1745baa50582348ef


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top