From: tglx@linutronix.de (Thomas Gleixner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1] futex: remove duplicated code and fix UB
Date: Fri, 23 Jun 2017 09:51:23 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1706230017520.2221@nanos> (raw)
In-Reply-To: <20170621115318.2781-1-jslaby@suse.cz>
On Wed, 21 Jun 2017, Jiri Slaby wrote:
> diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
> index f32b42e8725d..5bb2fd4674e7 100644
> --- a/arch/arm64/include/asm/futex.h
> +++ b/arch/arm64/include/asm/futex.h
> @@ -48,20 +48,10 @@ do { \
> } while (0)
>
> static inline int
> -futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
That unsigned int seems to be a change from the arm64 tree in next. It's
not upstream and it'll cause a (easy to resolve) conflict.
> +static int futex_atomic_op_inuser(unsigned int encoded_op, u32 __user *uaddr)
> +{
> + int op = (encoded_op >> 28) & 7;
> + int cmp = (encoded_op >> 24) & 15;
> + int oparg = (int)(encoded_op << 8) >> 20;
> + int cmparg = (int)(encoded_op << 20) >> 20;
So this is really bad. We have implicit and explicit type casting to
int. And while we are at it can we please stop proliferating the existing
mess.
'op' and 'cmp' definitly can be unsigned int. There is no reason to cast
them to int.
oparg, cmparg and oldval are more interesting.
The logic here is "documented" in uapi/linux/futex.h
/* FUTEX_WAKE_OP will perform atomically
int oldval = *(int *)UADDR2;
*(int *)UADDR2 = oldval OP OPARG;
if (oldval CMP CMPARG)
wake UADDR2; */
Now the FUTEX_OP macro which is supposed to compose the encoded_up does:
#define FUTEX_OP(op, oparg, cmp, cmparg) \
(((op & 0xf) << 28) | ((cmp & 0xf) << 24) \
| ((oparg & 0xfff) << 12) | (cmparg & 0xfff))
Of course this all is not typed, undocumented and completely ill
defined.
> + int oparg = (int)(encoded_op << 8) >> 20;
> + int cmparg = (int)(encoded_op << 20) >> 20;
So in fact we sign expand the 12 bits of oparg and cmparg. Really
intuitive.
Yes, we probably can't change that anymore, but at least we should make it
very explicit and add a comment to that effect.
Thanks,
tglx
next prev parent reply other threads:[~2017-06-23 7:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-21 11:53 [PATCH 1/1] futex: remove duplicated code and fix UB Jiri Slaby
2017-06-22 3:53 ` Darren Hart
2017-06-23 7:51 ` Thomas Gleixner [this message]
2017-06-26 12:02 ` Jiri Slaby
2017-06-26 12:08 ` Will Deacon
2017-07-03 10:18 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1706230017520.2221@nanos \
--to=tglx@linutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox