All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Marcel Holtmann <marcel@holtmann.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	"Lee, Chun-Yi" <jlee@suse.com>, Arnd Bergmann <arnd@arndb.de>,
	Lee@kernel, Luiz Augusto von Dentz <luiz.von.dentz@intel.com>,
	stable@vger.kernel.org, Iulia Tanasescu <iulia.tanasescu@nxp.com>,
	Wenjia Zhang <wenjia@linux.ibm.com>,
	linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Bluetooth: mark bacmp() and bacpy() as __always_inline
Date: Mon, 9 Oct 2023 08:36:08 -0700	[thread overview]
Message-ID: <202310090835.4DEB79C5@keescook> (raw)
In-Reply-To: <20231009134826.1063869-1-arnd@kernel.org>

On Mon, Oct 09, 2023 at 03:48:19PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> These functions are simple wrappers around memcmp() and memcpy(), which
> contain compile-time checks for buffer overflow. Something in gcc-13 and
> likely other versions makes this trigger a warning when the functions
> are not inlined and the compiler misunderstands the buffer length:
> 
> In file included from net/bluetooth/hci_event.c:32:
> In function 'bacmp',
>     inlined from 'hci_conn_request_evt' at net/bluetooth/hci_event.c:3276:7:
> include/net/bluetooth/bluetooth.h:364:16: error: 'memcmp' specified bound 6 exceeds source size 0 [-Werror=stringop-overread]
>   364 |         return memcmp(ba1, ba2, sizeof(bdaddr_t));
>       |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Use the __always_inline annotation to ensure that the helpers are
> correctly checked. This has no effect on the actual correctness
> of the code, but avoids the warning. Since the patch that introduced
> the warning is marked for stable backports, this one should also
> go that way to avoid introducing build regressions.

Yes, good call.

> 
> Fixes: d70e44fef8621 ("Bluetooth: Reject connection with the device which has same BD_ADDR")
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Lee, Chun-Yi <jlee@suse.com>
> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Acked-by: Kees Cook <keescook@chromium.org>

-Kees

> ---
>  include/net/bluetooth/bluetooth.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
> index 7ffa8c192c3f2..27ee1bf51c235 100644
> --- a/include/net/bluetooth/bluetooth.h
> +++ b/include/net/bluetooth/bluetooth.h
> @@ -359,11 +359,11 @@ static inline bool bdaddr_type_is_le(u8 type)
>  #define BDADDR_NONE (&(bdaddr_t) {{0xff, 0xff, 0xff, 0xff, 0xff, 0xff}})
>  
>  /* Copy, swap, convert BD Address */
> -static inline int bacmp(const bdaddr_t *ba1, const bdaddr_t *ba2)
> +static __always_inline int bacmp(const bdaddr_t *ba1, const bdaddr_t *ba2)
>  {
>  	return memcmp(ba1, ba2, sizeof(bdaddr_t));
>  }
> -static inline void bacpy(bdaddr_t *dst, const bdaddr_t *src)
> +static __always_inline void bacpy(bdaddr_t *dst, const bdaddr_t *src)
>  {
>  	memcpy(dst, src, sizeof(bdaddr_t));
>  }
> -- 
> 2.39.2
> 

-- 
Kees Cook

  parent reply	other threads:[~2023-10-09 15:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-09 13:48 [PATCH] Bluetooth: mark bacmp() and bacpy() as __always_inline Arnd Bergmann
2023-10-09 13:48 ` Arnd Bergmann
2023-10-09 14:37 ` bluez.test.bot
2023-10-09 15:36 ` Kees Cook [this message]
2023-10-09 15:36 ` [PATCH] " Arnd Bergmann
2023-10-09 16:02   ` Kees Cook
2023-10-09 18:23     ` Arnd Bergmann
2023-10-09 19:48       ` Kees Cook
2023-10-09 20:08         ` Arnd Bergmann
2023-10-09 20:15           ` Kees Cook
2023-10-10  0:01             ` Luiz Augusto von Dentz

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=202310090835.4DEB79C5@keescook \
    --to=keescook@chromium.org \
    --cc=Lee@kernel \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=iulia.tanasescu@nxp.com \
    --cc=jlee@suse.com \
    --cc=johan.hedberg@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=luiz.von.dentz@intel.com \
    --cc=marcel@holtmann.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=wenjia@linux.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.