Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andrej Shadura' <andrew.shadura@collabora.co.uk>,
	"linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Justin Stitt <justinstitt@google.com>,
	Aleksei Vetrov <vvvvvv@google.com>,
	"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
	"kernel@collabora.com" <kernel@collabora.com>,
	George Burgess <gbiv@chromium.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: RE: [PATCH v2] Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()
Date: Wed, 9 Oct 2024 16:37:32 +0000	[thread overview]
Message-ID: <49c81d21778b4ef5a7ab458b359a9993@AcuMS.aculab.com> (raw)
In-Reply-To: <20241009121424.1472485-1-andrew.shadura@collabora.co.uk>

From: Andrej Shadura
> Sent: 09 October 2024 13:14
> 
> Commit 9bf4e919ccad worked around an issue introduced after an innocuous
> optimisation change in LLVM main:
> 
> > len is defined as an 'int' because it is assigned from
> > '__user int *optlen'. However, it is clamped against the result of
> > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit
> > platforms). This is done with min_t() because min() requires compatible
> > types, which results in both len and the result of sizeof() being casted
> > to 'unsigned int', meaning len changes signs and the result of sizeof()
> > is truncated. From there, len is passed to copy_to_user(), which has a
> > third parameter type of 'unsigned long', so it is widened and changes
> > signs again.

That can't matter because the value is a small positive integer.

> This excessive casting in combination with the KCSAN
> > instrumentation causes LLVM to fail to eliminate the __bad_copy_from()
> > call, failing the build.
> 
> The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and
> rfcomm_sock_getsockopt_old.
> 
> Change the type of len to size_t in both rfcomm_sock_getsockopt and
> rfcomm_sock_getsockopt_old and replace min_t() with min().

Isn't there still a problem if the application passed a negative length.
You are converting it to a very large unsigned value and then reducing
it to the structure size.
Since the structure size will be less than 2GB it makes no difference
whether the '__user int optlen' is ever converted to 64bits.
I think you are just hiding a bug in a different way.

Note that pretty much all the checks for 'optlen' have treated
negative values as 4 since well before the min() and min_t()
#defines were added.
Look at the tcp code!

I bet that globally fixing the test will cause some important
application that is passing 'on stack garbage' to fail.

	David

> 
> Cc: stable@vger.kernel.org
> Co-authored-by: Aleksei Vetrov <vvvvvv@google.com>
> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()")
> Link: https://github.com/ClangBuiltLinux/linux/issues/2007
> Link: https://github.com/llvm/llvm-project/issues/85647
> Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>
> Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
>  net/bluetooth/rfcomm/sock.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
> index 37d63d768afb..5f9d370e09b1 100644
> --- a/net/bluetooth/rfcomm/sock.c
> +++ b/net/bluetooth/rfcomm/sock.c
> @@ -729,7 +729,8 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
>  	struct sock *l2cap_sk;
>  	struct l2cap_conn *conn;
>  	struct rfcomm_conninfo cinfo;
> -	int len, err = 0;
> +	int err = 0;
> +	size_t len;
>  	u32 opt;
> 
>  	BT_DBG("sk %p", sk);
> @@ -783,7 +784,7 @@ static int rfcomm_sock_getsockopt_old(struct socket *sock, int optname, char __u
>  		cinfo.hci_handle = conn->hcon->handle;
>  		memcpy(cinfo.dev_class, conn->hcon->dev_class, 3);
> 
> -		len = min_t(unsigned int, len, sizeof(cinfo));
> +		len = min(len, sizeof(cinfo));
>  		if (copy_to_user(optval, (char *) &cinfo, len))
>  			err = -EFAULT;
> 
> @@ -802,7 +803,8 @@ static int rfcomm_sock_getsockopt(struct socket *sock, int level, int optname, c
>  {
>  	struct sock *sk = sock->sk;
>  	struct bt_security sec;
> -	int len, err = 0;
> +	int err = 0;
> +	size_t len;
> 
>  	BT_DBG("sk %p", sk);
> 
> @@ -827,7 +829,7 @@ static int rfcomm_sock_getsockopt(struct socket *sock, int level, int optname, c
>  		sec.level = rfcomm_pi(sk)->sec_level;
>  		sec.key_size = 0;
> 
> -		len = min_t(unsigned int, len, sizeof(sec));
> +		len = min(len, sizeof(sec));
>  		if (copy_to_user(optval, (char *) &sec, len))
>  			err = -EFAULT;
> 
> --
> 2.43.0
> 

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)


  reply	other threads:[~2024-10-09 16:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-09 12:14 [PATCH v2] Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}() Andrej Shadura
2024-10-09 16:37 ` David Laight [this message]
2024-10-10  6:51   ` Andrej Shadura
2024-10-17 13:46 ` Andrej Shadura
2024-10-17 14:39   ` Luiz Augusto von Dentz
2024-10-21 17:10 ` patchwork-bot+bluetooth

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=49c81d21778b4ef5a7ab458b359a9993@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=andrew.shadura@collabora.co.uk \
    --cc=gbiv@chromium.org \
    --cc=justinstitt@google.com \
    --cc=kernel@collabora.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=vvvvvv@google.com \
    /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