linux-kernel - Re: [PATCH] Pass nr_wake2 to futex_wake

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

Message-Id: <20070717180628.ec649a78.akpm@linux-foundation.org>
Date:	Tue, 17 Jul 2007 18:06:28 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Andreas Schwab <schwab@...e.de>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Ulrich Drepper <drepper@...hat.com>, stable@...nel.org
Subject: Re: [PATCH] Pass nr_wake2 to futex_wake_op

On Tue, 17 Jul 2007 13:31:29 +0200
Andreas Schwab <schwab@...e.de> wrote:

> The fourth argument of sys_futex is ignored when op == FUTEX_WAKE_OP,
> but futex_wake_op expects it as its nr_wake2 parameter.
> 
> The only user of this operation in glibc is always passing 1, so this
> bug had no consequences so far.
> 
> Signed-off-by: Andreas Schwab <schwab@...e.de>
> 
> ---
>  kernel/futex.c |    4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> --- linux-2.6.22.orig/kernel/futex.c	2007-07-02 00:40:44.000000000 +0200
> +++ linux-2.6.22/kernel/futex.c	2007-07-07 15:56:42.000000000 +0200
> @@ -2061,8 +2061,10 @@ asmlinkage long sys_futex(u32 __user *ua
>  	}
>  	/*
>  	 * requeue parameter in 'utime' if cmd == FUTEX_REQUEUE.
> +	 * number of waiters to wake in 'utime' if cmd == FUTEX_WAKE_OP.
>  	 */
> -	if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE)
> +	if (cmd == FUTEX_REQUEUE || cmd == FUTEX_CMP_REQUEUE ||
> +	    cmd == FUTEX_WAKE_OP)
>  		val2 = (u32) (unsigned long) utime;
>  
>  	return do_futex(uaddr, op, val, tp, uaddr2, val2, val3);
> 

So if an application or glibc _does_ start passing in non-1 values, it
will malfunction on earlier kernels?

So that userspace code would need to have a test for the kernel version, I
assume?

All a bit of a hassle.  Still, I'd propose that this change (if the
thus-far-silent cc'ees agree with it?) go into 2.6.22.x at least.  If it
gets accepted into 2.6.22.x then applications (or glibc) will need to test
for kernels as far back as 2.6.22.  Really they would need to test for the
correct value of x in 2.6.22.x, but I don't know if glibc is set up for
that.

Thoughts?
-
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/