* [PATCH v2 2/2] Bluetooth: SMP: Use AES-CMAC library API
From: Eric Biggers @ 2026-04-21 23:09 UTC (permalink / raw)
To: linux-bluetooth, Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-crypto, linux-kernel, Eric Biggers, Ard Biesheuvel
In-Reply-To: <20260421230917.7057-1-ebiggers@kernel.org>
Now that AES-CMAC has a library API, convert net/bluetooth/smp.c to use
it instead of the "cmac(aes)" crypto_shash. Since the library API
doesn't require dynamic memory allocation, we no longer need to pass a
crypto_shash object down the call stack and can simply allocate the
aes_cmac_key on the stack in smp_aes_cmac() (renamed from aes_cmac()).
The result is simpler and faster code that no longer relies on the
error-prone loading of algorithms by name.
Note that the maximum stack usage actually decreases slightly, despite
the expanded AES key being moved to the stack. This is because the old
code called crypto_shash_tfm_digest(), which allocates 384 bytes on the
stack for a maximally-sized hash descriptor for any algorithm. The new
code instead declares a 288-byte aes_cmac_key, then calls aes_cmac()
which declares a 32-byte aes_cmac_ctx. Since 288 + 32 < 384, the
maximum stack usage decreases. I.e. the entire expanded AES key easily
fits in the space that the generic crypto API was wasting before.
I didn't add zeroization of the aes_cmac_key, since smp_aes_cmac()
already copies the raw key to the stack without zeroizing it.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
net/bluetooth/Kconfig | 3 +-
net/bluetooth/smp.c | 180 +++++++++++++++---------------------------
2 files changed, 65 insertions(+), 118 deletions(-)
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index 8bd0f2891161..884356938d74 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -8,12 +8,11 @@ menuconfig BT
depends on !S390
depends on RFKILL || !RFKILL
select CRC16
select CRYPTO
select CRYPTO_LIB_AES
- imply CRYPTO_AES
- select CRYPTO_CMAC
+ select CRYPTO_LIB_AES_CBC_MACS
select CRYPTO_ECDH
help
Bluetooth is low-cost, low-power, short-range wireless technology.
It was designed as a replacement for cables and other short-range
technologies like IrDA. Bluetooth operates in personal area range
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index 98f1da4f5f55..1739c1989dbd 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -20,12 +20,12 @@
SOFTWARE IS DISCLAIMED.
*/
#include <linux/debugfs.h>
#include <linux/scatterlist.h>
+#include <crypto/aes-cbc-macs.h>
#include <crypto/aes.h>
-#include <crypto/hash.h>
#include <crypto/kpp.h>
#include <crypto/utils.h>
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
@@ -61,11 +61,11 @@
#define AUTH_REQ_MASK(dev) (hci_dev_test_flag(dev, HCI_SC_ENABLED) ? \
0x3f : 0x07)
#define KEY_DIST_MASK 0x07
-/* Maximum message length that can be passed to aes_cmac */
+/* Maximum message length that can be passed to smp_aes_cmac */
#define CMAC_MSG_MAX 80
enum {
SMP_FLAG_TK_VALID,
SMP_FLAG_CFM_PENDING,
@@ -87,11 +87,10 @@ struct smp_dev {
bool local_oob;
u8 local_pk[64];
u8 local_rand[16];
bool debug_key;
- struct crypto_shash *tfm_cmac;
struct crypto_kpp *tfm_ecdh;
};
struct smp_chan {
struct l2cap_conn *conn;
@@ -125,11 +124,10 @@ struct smp_chan {
u8 local_pk[64];
u8 remote_pk[64];
u8 dhkey[32];
u8 mackey[16];
- struct crypto_shash *tfm_cmac;
struct crypto_kpp *tfm_ecdh;
};
/* These debug key values are defined in the SMP section of the core
* specification. debug_pk is the public debug key and debug_sk the
@@ -164,52 +162,40 @@ static inline void swap_buf(const u8 *src, u8 *dst, size_t len)
/* The following functions map to the LE SC SMP crypto functions
* AES-CMAC, f4, f5, f6, g2 and h6.
*/
-static int aes_cmac(struct crypto_shash *tfm, const u8 k[16], const u8 *m,
- size_t len, u8 mac[16])
+static int smp_aes_cmac(const u8 k[16], const u8 *m, size_t len, u8 mac[16])
{
uint8_t tmp[16], mac_msb[16], msg_msb[CMAC_MSG_MAX];
+ struct aes_cmac_key key;
int err;
if (len > CMAC_MSG_MAX)
return -EFBIG;
- if (!tfm) {
- BT_ERR("tfm %p", tfm);
- return -EINVAL;
- }
-
/* Swap key and message from LSB to MSB */
swap_buf(k, tmp, 16);
swap_buf(m, msg_msb, len);
SMP_DBG("msg (len %zu) %*phN", len, (int) len, m);
SMP_DBG("key %16phN", k);
- err = crypto_shash_setkey(tfm, tmp, 16);
- if (err) {
- BT_ERR("cipher setkey failed: %d", err);
+ err = aes_cmac_preparekey(&key, tmp, 16);
+ if (WARN_ON_ONCE(err)) /* Should never happen, as 16 is valid keylen */
return err;
- }
-
- err = crypto_shash_tfm_digest(tfm, msg_msb, len, mac_msb);
- if (err) {
- BT_ERR("Hash computation error %d", err);
- return err;
- }
+ aes_cmac(&key, msg_msb, len, mac_msb);
swap_buf(mac_msb, mac, 16);
SMP_DBG("mac %16phN", mac);
return 0;
}
-static int smp_f4(struct crypto_shash *tfm_cmac, const u8 u[32],
- const u8 v[32], const u8 x[16], u8 z, u8 res[16])
+static int smp_f4(const u8 u[32], const u8 v[32], const u8 x[16], u8 z,
+ u8 res[16])
{
u8 m[65];
int err;
SMP_DBG("u %32phN", u);
@@ -218,22 +204,21 @@ static int smp_f4(struct crypto_shash *tfm_cmac, const u8 u[32],
m[0] = z;
memcpy(m + 1, v, 32);
memcpy(m + 33, u, 32);
- err = aes_cmac(tfm_cmac, x, m, sizeof(m), res);
+ err = smp_aes_cmac(x, m, sizeof(m), res);
if (err)
return err;
SMP_DBG("res %16phN", res);
return err;
}
-static int smp_f5(struct crypto_shash *tfm_cmac, const u8 w[32],
- const u8 n1[16], const u8 n2[16], const u8 a1[7],
- const u8 a2[7], u8 mackey[16], u8 ltk[16])
+static int smp_f5(const u8 w[32], const u8 n1[16], const u8 n2[16],
+ const u8 a1[7], const u8 a2[7], u8 mackey[16], u8 ltk[16])
{
/* The btle, salt and length "magic" values are as defined in
* the SMP section of the Bluetooth core specification. In ASCII
* the btle value ends up being 'btle'. The salt is just a
* random number whereas length is the value 256 in little
@@ -248,11 +233,11 @@ static int smp_f5(struct crypto_shash *tfm_cmac, const u8 w[32],
SMP_DBG("w %32phN", w);
SMP_DBG("n1 %16phN n2 %16phN", n1, n2);
SMP_DBG("a1 %7phN a2 %7phN", a1, a2);
- err = aes_cmac(tfm_cmac, salt, w, 32, t);
+ err = smp_aes_cmac(salt, w, 32, t);
if (err)
return err;
SMP_DBG("t %16phN", t);
@@ -263,31 +248,30 @@ static int smp_f5(struct crypto_shash *tfm_cmac, const u8 w[32],
memcpy(m + 32, n1, 16);
memcpy(m + 48, btle, 4);
m[52] = 0; /* Counter */
- err = aes_cmac(tfm_cmac, t, m, sizeof(m), mackey);
+ err = smp_aes_cmac(t, m, sizeof(m), mackey);
if (err)
return err;
SMP_DBG("mackey %16phN", mackey);
m[52] = 1; /* Counter */
- err = aes_cmac(tfm_cmac, t, m, sizeof(m), ltk);
+ err = smp_aes_cmac(t, m, sizeof(m), ltk);
if (err)
return err;
SMP_DBG("ltk %16phN", ltk);
return 0;
}
-static int smp_f6(struct crypto_shash *tfm_cmac, const u8 w[16],
- const u8 n1[16], const u8 n2[16], const u8 r[16],
- const u8 io_cap[3], const u8 a1[7], const u8 a2[7],
- u8 res[16])
+static int smp_f6(const u8 w[16], const u8 n1[16], const u8 n2[16],
+ const u8 r[16], const u8 io_cap[3], const u8 a1[7],
+ const u8 a2[7], u8 res[16])
{
u8 m[65];
int err;
SMP_DBG("w %16phN", w);
@@ -299,21 +283,21 @@ static int smp_f6(struct crypto_shash *tfm_cmac, const u8 w[16],
memcpy(m + 14, io_cap, 3);
memcpy(m + 17, r, 16);
memcpy(m + 33, n2, 16);
memcpy(m + 49, n1, 16);
- err = aes_cmac(tfm_cmac, w, m, sizeof(m), res);
+ err = smp_aes_cmac(w, m, sizeof(m), res);
if (err)
return err;
SMP_DBG("res %16phN", res);
return err;
}
-static int smp_g2(struct crypto_shash *tfm_cmac, const u8 u[32], const u8 v[32],
- const u8 x[16], const u8 y[16], u32 *val)
+static int smp_g2(const u8 u[32], const u8 v[32], const u8 x[16],
+ const u8 y[16], u32 *val)
{
u8 m[80], tmp[16];
int err;
SMP_DBG("u %32phN", u);
@@ -322,11 +306,11 @@ static int smp_g2(struct crypto_shash *tfm_cmac, const u8 u[32], const u8 v[32],
memcpy(m, y, 16);
memcpy(m + 16, v, 32);
memcpy(m + 48, u, 32);
- err = aes_cmac(tfm_cmac, x, m, sizeof(m), tmp);
+ err = smp_aes_cmac(x, m, sizeof(m), tmp);
if (err)
return err;
*val = get_unaligned_le32(tmp);
*val %= 1000000;
@@ -334,34 +318,32 @@ static int smp_g2(struct crypto_shash *tfm_cmac, const u8 u[32], const u8 v[32],
SMP_DBG("val %06u", *val);
return 0;
}
-static int smp_h6(struct crypto_shash *tfm_cmac, const u8 w[16],
- const u8 key_id[4], u8 res[16])
+static int smp_h6(const u8 w[16], const u8 key_id[4], u8 res[16])
{
int err;
SMP_DBG("w %16phN key_id %4phN", w, key_id);
- err = aes_cmac(tfm_cmac, w, key_id, 4, res);
+ err = smp_aes_cmac(w, key_id, 4, res);
if (err)
return err;
SMP_DBG("res %16phN", res);
return err;
}
-static int smp_h7(struct crypto_shash *tfm_cmac, const u8 w[16],
- const u8 salt[16], u8 res[16])
+static int smp_h7(const u8 w[16], const u8 salt[16], u8 res[16])
{
int err;
SMP_DBG("w %16phN salt %16phN", w, salt);
- err = aes_cmac(tfm_cmac, salt, w, 16, res);
+ err = smp_aes_cmac(salt, w, 16, res);
if (err)
return err;
SMP_DBG("res %16phN", res);
@@ -572,12 +554,11 @@ int smp_generate_oob(struct hci_dev *hdev, u8 hash[16], u8 rand[16])
SMP_DBG("OOB Public Key X: %32phN", smp->local_pk);
SMP_DBG("OOB Public Key Y: %32phN", smp->local_pk + 32);
get_random_bytes(smp->local_rand, 16);
- err = smp_f4(smp->tfm_cmac, smp->local_pk, smp->local_pk,
- smp->local_rand, 0, hash);
+ err = smp_f4(smp->local_pk, smp->local_pk, smp->local_rand, 0, hash);
if (err < 0)
return err;
memcpy(rand, smp->local_rand, 16);
@@ -755,11 +736,10 @@ static void smp_chan_destroy(struct l2cap_conn *conn)
kfree_sensitive(smp->csrk);
kfree_sensitive(smp->responder_csrk);
kfree_sensitive(smp->link_key);
- crypto_free_shash(smp->tfm_cmac);
crypto_free_kpp(smp->tfm_ecdh);
/* Ensure that we don't leave any debug key around if debug key
* support hasn't been explicitly enabled.
*/
@@ -1158,27 +1138,27 @@ static void sc_generate_link_key(struct smp_chan *smp)
if (test_bit(SMP_FLAG_CT2, &smp->flags)) {
/* SALT = 0x000000000000000000000000746D7031 */
const u8 salt[16] = { 0x31, 0x70, 0x6d, 0x74 };
- if (smp_h7(smp->tfm_cmac, smp->tk, salt, smp->link_key)) {
+ if (smp_h7(smp->tk, salt, smp->link_key)) {
kfree_sensitive(smp->link_key);
smp->link_key = NULL;
return;
}
} else {
/* From core spec. Spells out in ASCII as 'tmp1'. */
const u8 tmp1[4] = { 0x31, 0x70, 0x6d, 0x74 };
- if (smp_h6(smp->tfm_cmac, smp->tk, tmp1, smp->link_key)) {
+ if (smp_h6(smp->tk, tmp1, smp->link_key)) {
kfree_sensitive(smp->link_key);
smp->link_key = NULL;
return;
}
}
- if (smp_h6(smp->tfm_cmac, smp->link_key, lebr, smp->link_key)) {
+ if (smp_h6(smp->link_key, lebr, smp->link_key)) {
kfree_sensitive(smp->link_key);
smp->link_key = NULL;
return;
}
}
@@ -1216,21 +1196,21 @@ static void sc_generate_ltk(struct smp_chan *smp)
if (test_bit(SMP_FLAG_CT2, &smp->flags)) {
/* SALT = 0x000000000000000000000000746D7032 */
const u8 salt[16] = { 0x32, 0x70, 0x6d, 0x74 };
- if (smp_h7(smp->tfm_cmac, key->val, salt, smp->tk))
+ if (smp_h7(key->val, salt, smp->tk))
return;
} else {
/* From core spec. Spells out in ASCII as 'tmp2'. */
const u8 tmp2[4] = { 0x32, 0x70, 0x6d, 0x74 };
- if (smp_h6(smp->tfm_cmac, key->val, tmp2, smp->tk))
+ if (smp_h6(key->val, tmp2, smp->tk))
return;
}
- if (smp_h6(smp->tfm_cmac, smp->tk, brle, smp->tk))
+ if (smp_h6(smp->tk, brle, smp->tk))
return;
sc_add_ltk(smp);
}
@@ -1387,20 +1367,14 @@ static struct smp_chan *smp_chan_create(struct l2cap_conn *conn)
smp = kzalloc_obj(*smp, GFP_ATOMIC);
if (!smp)
return NULL;
- smp->tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
- if (IS_ERR(smp->tfm_cmac)) {
- bt_dev_err(hcon->hdev, "Unable to create CMAC crypto context");
- goto zfree_smp;
- }
-
smp->tfm_ecdh = crypto_alloc_kpp("ecdh-nist-p256", 0, 0);
if (IS_ERR(smp->tfm_ecdh)) {
bt_dev_err(hcon->hdev, "Unable to create ECDH crypto context");
- goto free_shash;
+ goto zfree_smp;
}
smp->conn = conn;
chan->data = smp;
@@ -1410,12 +1384,10 @@ static struct smp_chan *smp_chan_create(struct l2cap_conn *conn)
hci_conn_hold(hcon);
return smp;
-free_shash:
- crypto_free_shash(smp->tfm_cmac);
zfree_smp:
kfree_sensitive(smp);
return NULL;
}
@@ -1435,11 +1407,11 @@ static int sc_mackey_and_ltk(struct smp_chan *smp, u8 mackey[16], u8 ltk[16])
memcpy(a, &hcon->init_addr, 6);
memcpy(b, &hcon->resp_addr, 6);
a[6] = hcon->init_addr_type;
b[6] = hcon->resp_addr_type;
- return smp_f5(smp->tfm_cmac, smp->dhkey, na, nb, a, b, mackey, ltk);
+ return smp_f5(smp->dhkey, na, nb, a, b, mackey, ltk);
}
static void sc_dhkey_check(struct smp_chan *smp)
{
struct hci_conn *hcon = smp->conn->hcon;
@@ -1468,12 +1440,12 @@ static void sc_dhkey_check(struct smp_chan *smp)
put_unaligned_le32(hcon->passkey_notify, r);
if (smp->method == REQ_OOB)
memcpy(r, smp->rr, 16);
- smp_f6(smp->tfm_cmac, smp->mackey, smp->prnd, smp->rrnd, r, io_cap,
- local_addr, remote_addr, check.e);
+ smp_f6(smp->mackey, smp->prnd, smp->rrnd, r, io_cap, local_addr,
+ remote_addr, check.e);
smp_send_cmd(smp->conn, SMP_CMD_DHKEY_CHECK, sizeof(check), &check);
}
static u8 sc_passkey_send_confirm(struct smp_chan *smp)
@@ -1486,11 +1458,11 @@ static u8 sc_passkey_send_confirm(struct smp_chan *smp)
r = ((hcon->passkey_notify >> smp->passkey_round) & 0x01);
r |= 0x80;
get_random_bytes(smp->prnd, sizeof(smp->prnd));
- if (smp_f4(smp->tfm_cmac, smp->local_pk, smp->remote_pk, smp->prnd, r,
+ if (smp_f4(smp->local_pk, smp->remote_pk, smp->prnd, r,
cfm.confirm_val))
return SMP_UNSPECIFIED;
smp_send_cmd(conn, SMP_CMD_PAIRING_CONFIRM, sizeof(cfm), &cfm);
@@ -1511,12 +1483,11 @@ static u8 sc_passkey_round(struct smp_chan *smp, u8 smp_op)
switch (smp_op) {
case SMP_CMD_PAIRING_RANDOM:
r = ((hcon->passkey_notify >> smp->passkey_round) & 0x01);
r |= 0x80;
- if (smp_f4(smp->tfm_cmac, smp->remote_pk, smp->local_pk,
- smp->rrnd, r, cfm))
+ if (smp_f4(smp->remote_pk, smp->local_pk, smp->rrnd, r, cfm))
return SMP_UNSPECIFIED;
if (crypto_memneq(smp->pcnf, cfm, 16))
return SMP_CONFIRM_FAILED;
@@ -2176,12 +2147,11 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
return sc_passkey_round(smp, SMP_CMD_PAIRING_RANDOM);
if (test_bit(SMP_FLAG_INITIATOR, &smp->flags)) {
u8 cfm[16];
- err = smp_f4(smp->tfm_cmac, smp->remote_pk, smp->local_pk,
- smp->rrnd, 0, cfm);
+ err = smp_f4(smp->remote_pk, smp->local_pk, smp->rrnd, 0, cfm);
if (err)
return SMP_UNSPECIFIED;
if (crypto_memneq(smp->pcnf, cfm, 16))
return SMP_CONFIRM_FAILED;
@@ -2203,11 +2173,11 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
SMP_ALLOW_CMD(smp, SMP_CMD_DHKEY_CHECK);
}
return 0;
}
- err = smp_g2(smp->tfm_cmac, pkax, pkbx, na, nb, &passkey);
+ err = smp_g2(pkax, pkbx, na, nb, &passkey);
if (err)
return SMP_UNSPECIFIED;
/* Always require user confirmation for Just-Works pairing to prevent
* impersonation attacks, or in case of a legitimate device that is
@@ -2748,12 +2718,12 @@ static int smp_cmd_public_key(struct l2cap_conn *conn, struct sk_buff *skb)
}
memcpy(smp->remote_pk, key, 64);
if (test_bit(SMP_FLAG_REMOTE_OOB, &smp->flags)) {
- err = smp_f4(smp->tfm_cmac, smp->remote_pk, smp->remote_pk,
- smp->rr, 0, cfm.confirm_val);
+ err = smp_f4(smp->remote_pk, smp->remote_pk, smp->rr, 0,
+ cfm.confirm_val);
if (err)
return SMP_UNSPECIFIED;
if (crypto_memneq(cfm.confirm_val, smp->pcnf, 16))
return SMP_CONFIRM_FAILED;
@@ -2849,12 +2819,12 @@ static int smp_cmd_public_key(struct l2cap_conn *conn, struct sk_buff *skb)
* send the confirm value.
*/
if (test_bit(SMP_FLAG_INITIATOR, &smp->flags))
return 0;
- err = smp_f4(smp->tfm_cmac, smp->local_pk, smp->remote_pk, smp->prnd,
- 0, cfm.confirm_val);
+ err = smp_f4(smp->local_pk, smp->remote_pk, smp->prnd, 0,
+ cfm.confirm_val);
if (err)
return SMP_UNSPECIFIED;
smp_send_cmd(conn, SMP_CMD_PAIRING_CONFIRM, sizeof(cfm), &cfm);
SMP_ALLOW_CMD(smp, SMP_CMD_PAIRING_RANDOM);
@@ -2897,12 +2867,12 @@ static int smp_cmd_dhkey_check(struct l2cap_conn *conn, struct sk_buff *skb)
if (smp->method == REQ_PASSKEY || smp->method == DSP_PASSKEY)
put_unaligned_le32(hcon->passkey_notify, r);
else if (smp->method == REQ_OOB)
memcpy(r, smp->lr, 16);
- err = smp_f6(smp->tfm_cmac, smp->mackey, smp->rrnd, smp->prnd, r,
- io_cap, remote_addr, local_addr, e);
+ err = smp_f6(smp->mackey, smp->rrnd, smp->prnd, r, io_cap, remote_addr,
+ local_addr, e);
if (err)
return SMP_UNSPECIFIED;
if (crypto_memneq(check->e, e, 16))
return SMP_DHKEY_CHECK_FAILED;
@@ -3284,11 +3254,10 @@ static const struct l2cap_ops smp_root_chan_ops = {
static struct l2cap_chan *smp_add_cid(struct hci_dev *hdev, u16 cid)
{
struct l2cap_chan *chan;
struct smp_dev *smp;
- struct crypto_shash *tfm_cmac;
struct crypto_kpp *tfm_ecdh;
if (cid == L2CAP_CID_SMP_BREDR) {
smp = NULL;
goto create_chan;
@@ -3296,34 +3265,24 @@ static struct l2cap_chan *smp_add_cid(struct hci_dev *hdev, u16 cid)
smp = kzalloc_obj(*smp);
if (!smp)
return ERR_PTR(-ENOMEM);
- tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
- if (IS_ERR(tfm_cmac)) {
- bt_dev_err(hdev, "Unable to create CMAC crypto context");
- kfree_sensitive(smp);
- return ERR_CAST(tfm_cmac);
- }
-
tfm_ecdh = crypto_alloc_kpp("ecdh-nist-p256", 0, 0);
if (IS_ERR(tfm_ecdh)) {
bt_dev_err(hdev, "Unable to create ECDH crypto context");
- crypto_free_shash(tfm_cmac);
kfree_sensitive(smp);
return ERR_CAST(tfm_ecdh);
}
smp->local_oob = false;
- smp->tfm_cmac = tfm_cmac;
smp->tfm_ecdh = tfm_ecdh;
create_chan:
chan = l2cap_chan_create();
if (!chan) {
if (smp) {
- crypto_free_shash(smp->tfm_cmac);
crypto_free_kpp(smp->tfm_ecdh);
kfree_sensitive(smp);
}
return ERR_PTR(-ENOMEM);
}
@@ -3366,11 +3325,10 @@ static void smp_del_chan(struct l2cap_chan *chan)
BT_DBG("chan %p", chan);
smp = chan->data;
if (smp) {
chan->data = NULL;
- crypto_free_shash(smp->tfm_cmac);
crypto_free_kpp(smp->tfm_ecdh);
kfree_sensitive(smp);
}
l2cap_chan_put(chan);
@@ -3563,11 +3521,11 @@ static int __init test_s1(void)
return -EINVAL;
return 0;
}
-static int __init test_f4(struct crypto_shash *tfm_cmac)
+static int __init test_f4(void)
{
const u8 u[32] = {
0xe6, 0x9d, 0x35, 0x0e, 0x48, 0x01, 0x03, 0xcc,
0xdb, 0xfd, 0xf4, 0xac, 0x11, 0x91, 0xf4, 0xef,
0xb9, 0xa5, 0xf9, 0xe9, 0xa7, 0x83, 0x2c, 0x5e,
@@ -3585,21 +3543,21 @@ static int __init test_f4(struct crypto_shash *tfm_cmac)
0x2d, 0x87, 0x74, 0xa9, 0xbe, 0xa1, 0xed, 0xf1,
0x1c, 0xbd, 0xa9, 0x07, 0xf1, 0x16, 0xc9, 0xf2 };
u8 res[16];
int err;
- err = smp_f4(tfm_cmac, u, v, x, z, res);
+ err = smp_f4(u, v, x, z, res);
if (err)
return err;
if (crypto_memneq(res, exp, 16))
return -EINVAL;
return 0;
}
-static int __init test_f5(struct crypto_shash *tfm_cmac)
+static int __init test_f5(void)
{
const u8 w[32] = {
0x98, 0xa6, 0xbf, 0x73, 0xf3, 0x34, 0x8d, 0x86,
0xf1, 0x66, 0xf8, 0xb4, 0x13, 0x6b, 0x79, 0x99,
0x9b, 0x7d, 0x39, 0x0a, 0xa6, 0x10, 0x10, 0x34,
@@ -3619,11 +3577,11 @@ static int __init test_f5(struct crypto_shash *tfm_cmac)
0x20, 0x6e, 0x63, 0xce, 0x20, 0x6a, 0x3f, 0xfd,
0x02, 0x4a, 0x08, 0xa1, 0x76, 0xf1, 0x65, 0x29 };
u8 mackey[16], ltk[16];
int err;
- err = smp_f5(tfm_cmac, w, n1, n2, a1, a2, mackey, ltk);
+ err = smp_f5(w, n1, n2, a1, a2, mackey, ltk);
if (err)
return err;
if (crypto_memneq(mackey, exp_mackey, 16))
return -EINVAL;
@@ -3632,11 +3590,11 @@ static int __init test_f5(struct crypto_shash *tfm_cmac)
return -EINVAL;
return 0;
}
-static int __init test_f6(struct crypto_shash *tfm_cmac)
+static int __init test_f6(void)
{
const u8 w[16] = {
0x20, 0x6e, 0x63, 0xce, 0x20, 0x6a, 0x3f, 0xfd,
0x02, 0x4a, 0x08, 0xa1, 0x76, 0xf1, 0x65, 0x29 };
const u8 n1[16] = {
@@ -3655,21 +3613,21 @@ static int __init test_f6(struct crypto_shash *tfm_cmac)
0x61, 0x8f, 0x95, 0xda, 0x09, 0x0b, 0x6c, 0xd2,
0xc5, 0xe8, 0xd0, 0x9c, 0x98, 0x73, 0xc4, 0xe3 };
u8 res[16];
int err;
- err = smp_f6(tfm_cmac, w, n1, n2, r, io_cap, a1, a2, res);
+ err = smp_f6(w, n1, n2, r, io_cap, a1, a2, res);
if (err)
return err;
if (crypto_memneq(res, exp, 16))
return -EINVAL;
return 0;
}
-static int __init test_g2(struct crypto_shash *tfm_cmac)
+static int __init test_g2(void)
{
const u8 u[32] = {
0xe6, 0x9d, 0x35, 0x0e, 0x48, 0x01, 0x03, 0xcc,
0xdb, 0xfd, 0xf4, 0xac, 0x11, 0x91, 0xf4, 0xef,
0xb9, 0xa5, 0xf9, 0xe9, 0xa7, 0x83, 0x2c, 0x5e,
@@ -3687,21 +3645,21 @@ static int __init test_g2(struct crypto_shash *tfm_cmac)
0x6e, 0x5f, 0xa7, 0x25, 0xcc, 0xe7, 0xe8, 0xa6 };
const u32 exp_val = 0x2f9ed5ba % 1000000;
u32 val;
int err;
- err = smp_g2(tfm_cmac, u, v, x, y, &val);
+ err = smp_g2(u, v, x, y, &val);
if (err)
return err;
if (val != exp_val)
return -EINVAL;
return 0;
}
-static int __init test_h6(struct crypto_shash *tfm_cmac)
+static int __init test_h6(void)
{
const u8 w[16] = {
0x9b, 0x7d, 0x39, 0x0a, 0xa6, 0x10, 0x10, 0x34,
0x05, 0xad, 0xc8, 0x57, 0xa3, 0x34, 0x02, 0xec };
const u8 key_id[4] = { 0x72, 0x62, 0x65, 0x6c };
@@ -3709,11 +3667,11 @@ static int __init test_h6(struct crypto_shash *tfm_cmac)
0x99, 0x63, 0xb1, 0x80, 0xe2, 0xa9, 0xd3, 0xe8,
0x1c, 0xc9, 0x6d, 0xe7, 0x02, 0xe1, 0x9a, 0x2d };
u8 res[16];
int err;
- err = smp_h6(tfm_cmac, w, key_id, res);
+ err = smp_h6(w, key_id, res);
if (err)
return err;
if (crypto_memneq(res, exp, 16))
return -EINVAL;
@@ -3734,12 +3692,11 @@ static const struct file_operations test_smp_fops = {
.open = simple_open,
.read = test_smp_read,
.llseek = default_llseek,
};
-static int __init run_selftests(struct crypto_shash *tfm_cmac,
- struct crypto_kpp *tfm_ecdh)
+static int __init run_selftests(struct crypto_kpp *tfm_ecdh)
{
ktime_t calltime, delta, rettime;
unsigned long long duration;
int err;
@@ -3767,35 +3724,35 @@ static int __init run_selftests(struct crypto_shash *tfm_cmac,
if (err) {
BT_ERR("smp_s1 test failed");
goto done;
}
- err = test_f4(tfm_cmac);
+ err = test_f4();
if (err) {
BT_ERR("smp_f4 test failed");
goto done;
}
- err = test_f5(tfm_cmac);
+ err = test_f5();
if (err) {
BT_ERR("smp_f5 test failed");
goto done;
}
- err = test_f6(tfm_cmac);
+ err = test_f6();
if (err) {
BT_ERR("smp_f6 test failed");
goto done;
}
- err = test_g2(tfm_cmac);
+ err = test_g2();
if (err) {
BT_ERR("smp_g2 test failed");
goto done;
}
- err = test_h6(tfm_cmac);
+ err = test_h6();
if (err) {
BT_ERR("smp_h6 test failed");
goto done;
}
@@ -3818,30 +3775,21 @@ static int __init run_selftests(struct crypto_shash *tfm_cmac,
return err;
}
int __init bt_selftest_smp(void)
{
- struct crypto_shash *tfm_cmac;
struct crypto_kpp *tfm_ecdh;
int err;
- tfm_cmac = crypto_alloc_shash("cmac(aes)", 0, 0);
- if (IS_ERR(tfm_cmac)) {
- BT_ERR("Unable to create CMAC crypto context");
- return PTR_ERR(tfm_cmac);
- }
-
tfm_ecdh = crypto_alloc_kpp("ecdh-nist-p256", 0, 0);
if (IS_ERR(tfm_ecdh)) {
BT_ERR("Unable to create ECDH crypto context");
- crypto_free_shash(tfm_cmac);
return PTR_ERR(tfm_ecdh);
}
- err = run_selftests(tfm_cmac, tfm_ecdh);
+ err = run_selftests(tfm_ecdh);
- crypto_free_shash(tfm_cmac);
crypto_free_kpp(tfm_ecdh);
return err;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] Bluetooth: Remove unneeded crypto kconfig selections
From: Eric Biggers @ 2026-04-21 23:09 UTC (permalink / raw)
To: linux-bluetooth, Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-crypto, linux-kernel, Eric Biggers
In-Reply-To: <20260421230917.7057-1-ebiggers@kernel.org>
Remove several kconfig selections that are no longer needed:
- CRYPTO_SKCIPHER and CRYPTO_ECB have been unneeded since
commit a4770e1117f1 ("Bluetooth: Switch SMP to
crypto_cipher_encrypt_one()") in 2016.
- CRYPTO_SHA256 has been unneeded since
commit e7b02296fb40 ("Bluetooth: Remove BT_HS") in 2024.
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
net/bluetooth/Kconfig | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index 6b2b65a66700..8bd0f2891161 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -7,16 +7,13 @@ menuconfig BT
tristate "Bluetooth subsystem support"
depends on !S390
depends on RFKILL || !RFKILL
select CRC16
select CRYPTO
- select CRYPTO_SKCIPHER
select CRYPTO_LIB_AES
imply CRYPTO_AES
select CRYPTO_CMAC
- select CRYPTO_ECB
- select CRYPTO_SHA256
select CRYPTO_ECDH
help
Bluetooth is low-cost, low-power, short-range wireless technology.
It was designed as a replacement for cables and other short-range
technologies like IrDA. Bluetooth operates in personal area range
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] Bluetooth: Use AES-CMAC library API
From: Eric Biggers @ 2026-04-21 23:09 UTC (permalink / raw)
To: linux-bluetooth, Marcel Holtmann, Luiz Augusto von Dentz
Cc: linux-crypto, linux-kernel, Eric Biggers
This series removes unnecessary kconfig selections from CONFIG_BT, then
converts net/bluetooth/smp.c to use the AES-CMAC library API (which was
introduced in 7.1) instead of the crypto_shash API. This makes the code
simpler and more efficient.
This series is intended to be taken through the bluetooth tree and can
be applied for either 7.1 or 7.2, depending on maintainer preference.
These patches were originally sent as
https://lore.kernel.org/r/20260404200645.28902-1-ebiggers@kernel.org and
https://lore.kernel.org/r/20260218213501.136844-14-ebiggers@kernel.org/
Eric Biggers (2):
Bluetooth: Remove unneeded crypto kconfig selections
Bluetooth: SMP: Use AES-CMAC library API
net/bluetooth/Kconfig | 6 +-
net/bluetooth/smp.c | 180 +++++++++++++++---------------------------
2 files changed, 65 insertions(+), 121 deletions(-)
base-commit: d46dd0d88341e45f8e0226fdef5462f5270898fc
--
2.53.0
^ permalink raw reply
* RE: [BlueZ,v1] input: Fix checking LE bonding on HIDP
From: bluez.test.bot @ 2026-04-21 21:26 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260421202253.1957689-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 988 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1084033
---Test result---
Test Summary:
CheckPatch PASS 0.48 seconds
GitLint PASS 0.35 seconds
BuildEll PASS 20.23 seconds
BluezMake PASS 591.70 seconds
MakeCheck PASS 1.01 seconds
MakeDistcheck PASS 235.32 seconds
CheckValgrind PASS 201.19 seconds
CheckSmatch PASS 321.82 seconds
bluezmakeextell PASS 165.86 seconds
IncrementalBuild PASS 590.54 seconds
ScanBuild PASS 913.84 seconds
https://github.com/bluez/bluez/pull/2061
---
Regards,
Linux Bluetooth
^ permalink raw reply
* [bluez/bluez]
From: BluezTestBot @ 2026-04-21 20:35 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1083932
Home: https://github.com/bluez/bluez
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] fc03db: input: Fix checking LE bonding on HIDP
From: Luiz Augusto von Dentz @ 2026-04-21 20:34 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1084033
Home: https://github.com/bluez/bluez
Commit: fc03db8ad548a5676fe5401ed94caa54ea860bb9
https://github.com/bluez/bluez/commit/fc03db8ad548a5676fe5401ed94caa54ea860bb9
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-04-21 (Tue, 21 Apr 2026)
Changed paths:
M profiles/input/device.c
Log Message:
-----------
input: Fix checking LE bonding on HIDP
HIDP is classic only, LE uses HOG, so there is no point in checking the
bonding with the address type which in case the device supports
dual-mode will map to LE random/public address.
Fixes: https://github.com/bluez/bluez/issues/2034
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [bluez/bluez] 9dffe6: doc: Add AI coding assistants guidelines
From: Luiz Augusto von Dentz @ 2026-04-21 20:34 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/master
Home: https://github.com/bluez/bluez
Commit: 9dffe61bd8b270681a1aa6d30f8819718c2d5a61
https://github.com/bluez/bluez/commit/9dffe61bd8b270681a1aa6d30f8819718c2d5a61
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-04-21 (Tue, 21 Apr 2026)
Changed paths:
M README
A doc/coding-assistants.rst
Log Message:
-----------
doc: Add AI coding assistants guidelines
Add doc/coding-assistants.rst with guidance for AI tools contributing to
BlueZ, covering licensing compatibility, human responsibility, and the
Assisted-by attribution format. Reference the new document from the README.
Based on similar documentation from the Linux kernel:
78d979db6cef ("docs: add AI Coding Assistants documentation")
Commit: 2c3961e3b0fab02afa3b8388e35f190c96f94fdb
https://github.com/bluez/bluez/commit/2c3961e3b0fab02afa3b8388e35f190c96f94fdb
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-04-21 (Tue, 21 Apr 2026)
Changed paths:
M .github/workflows/btsnoop-analyze.yml
Log Message:
-----------
Add permissions for btsnoop-analyzer workflow
Grant issues:write, contents:read, and models:read so the reusable
workflow can post comments and access the GitHub Models API.
Compare: https://github.com/bluez/bluez/compare/0fdf34b17d41...2c3961e3b0fa
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* [PATCH BlueZ v1] input: Fix checking LE bonding on HIDP
From: Luiz Augusto von Dentz @ 2026-04-21 20:22 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
HIDP is classic only, LE uses HOG, so there is no point in checking the
bonding with the address type which in case the device supports
dual-mode will map to LE random/public address.
Fixes: https://github.com/bluez/bluez/issues/2034
---
profiles/input/device.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/profiles/input/device.c b/profiles/input/device.c
index 6bdc5ee3aaf3..0ee6988c4e90 100644
--- a/profiles/input/device.c
+++ b/profiles/input/device.c
@@ -127,8 +127,7 @@ static int connection_disconnect(struct input_device *idev, uint32_t flags);
static bool input_device_bonded(struct input_device *idev)
{
- return device_is_bonded(idev->device,
- btd_device_get_bdaddr_type(idev->device));
+ return device_is_bonded(idev->device, BDADDR_BREDR);
}
static void input_device_free(struct input_device *idev)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH BlueZ v1] Add permissions for btsnoop-analyzer workflow
From: patchwork-bot+bluetooth @ 2026-04-21 20:10 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260421195544.1950548-1-luiz.dentz@gmail.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 21 Apr 2026 15:55:44 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> Grant issues:write, contents:read, and models:read so the reusable
> workflow can post comments and access the GitHub Models API.
> ---
> .github/workflows/btsnoop-analyze.yml | 5 +++++
> 1 file changed, 5 insertions(+)
Here is the summary with links:
- [BlueZ,v1] Add permissions for btsnoop-analyzer workflow
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=2c3961e3b0fa
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH BlueZ v1] doc: Add AI coding assistants guidelines
From: patchwork-bot+bluetooth @ 2026-04-21 20:10 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <20260421155141.1863559-1-luiz.dentz@gmail.com>
Hello:
This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 21 Apr 2026 11:51:41 -0400 you wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> Add doc/coding-assistants.rst with guidance for AI tools contributing to
> BlueZ, covering licensing compatibility, human responsibility, and the
> Assisted-by attribution format. Reference the new document from the README.
>
> Based on similar documentation from the Linux kernel:
> 78d979db6cef ("docs: add AI Coding Assistants documentation")
>
> [...]
Here is the summary with links:
- [BlueZ,v1] doc: Add AI coding assistants guidelines
https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=9dffe61bd8b2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH BlueZ v1] Add permissions for btsnoop-analyzer workflow
From: Luiz Augusto von Dentz @ 2026-04-21 19:55 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Grant issues:write, contents:read, and models:read so the reusable
workflow can post comments and access the GitHub Models API.
---
.github/workflows/btsnoop-analyze.yml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/.github/workflows/btsnoop-analyze.yml b/.github/workflows/btsnoop-analyze.yml
index 484288c0d9b6..b910f3c0cb66 100644
--- a/.github/workflows/btsnoop-analyze.yml
+++ b/.github/workflows/btsnoop-analyze.yml
@@ -4,6 +4,11 @@ on:
issue_comment:
types: [created]
+permissions:
+ issues: write
+ contents: read
+ models: read
+
jobs:
analyze:
if: >-
--
2.53.0
^ permalink raw reply related
* RE: Bluetooth: virtio_bt: harden rx against untrusted backend
From: bluez.test.bot @ 2026-04-21 18:26 UTC (permalink / raw)
To: linux-bluetooth, michael.bommarito
In-Reply-To: <20260421170845.3469513-2-michael.bommarito@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1083952
---Test result---
Test Summary:
CheckPatch FAIL 1.47 seconds
GitLint PASS 0.81 seconds
SubjectPrefix PASS 0.25 seconds
BuildKernel PASS 24.88 seconds
CheckAllWarning PASS 27.06 seconds
CheckSparse PASS 25.95 seconds
BuildKernel32 PASS 24.12 seconds
TestRunnerSetup PASS 520.13 seconds
IncrementalBuild PASS 24.74 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v3,1/2] Bluetooth: virtio_bt: clamp rx length before skb_put
WARNING: Non-standard signature: Assisted-by:
#141:
Assisted-by: Claude:claude-opus-4-7
ERROR: Unrecognized email address: 'Claude:claude-opus-4-7'
#141:
Assisted-by: Claude:claude-opus-4-7
total: 1 errors, 1 warnings, 37 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14532816.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
[v3,2/2] Bluetooth: virtio_bt: validate rx pkt_type header length
WARNING: Non-standard signature: Assisted-by:
#140:
Assisted-by: Claude:claude-opus-4-7
ERROR: Unrecognized email address: 'Claude:claude-opus-4-7'
#140:
Assisted-by: Claude:claude-opus-4-7
total: 1 errors, 1 warnings, 42 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14532817.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
https://github.com/bluez/bluetooth-next/pull/113
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH] Bluetooth: hci_uart: Fix NULL deref in recv callbacks when priv is uninitialized
From: patchwork-bot+bluetooth @ 2026-04-21 17:40 UTC (permalink / raw)
To: Aurelien DESBRIERES
Cc: linux-bluetooth, marcel, johan.hedberg, luiz.dentz, linux-kernel,
syzbot+ff30eeab8e07b37d524e
In-Reply-To: <20260421135331.15425-1-aurelien@hackers.camp>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 21 Apr 2026 15:53:31 +0200 you wrote:
> When a fault is injected during hci_uart line discipline setup, the
> proto open() callback may fail leaving hu->priv as NULL. A subsequent
> TIOCSTI ioctl can trigger the recv() callback before priv is
> initialized, causing a NULL pointer dereference.
>
> Fix all four affected HCI UART protocol drivers by adding a NULL check
> on hu->priv at the start of their recv() callbacks: h4, h5, ath and
> bcsp.
>
> [...]
Here is the summary with links:
- Bluetooth: hci_uart: Fix NULL deref in recv callbacks when priv is uninitialized
https://git.kernel.org/bluetooth/bluetooth-next/c/259c0a6e10fb
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4] Bluetooth: btmtk: validate WMT event SKB length before struct access
From: patchwork-bot+bluetooth @ 2026-04-21 17:40 UTC (permalink / raw)
To: Tristan Madani
Cc: luiz.dentz, marcel, sean.wang, mark-yw.chen, linux-mediatek,
stable, linux-bluetooth, tristan
In-Reply-To: <20260421111454.3403059-1-tristmd@gmail.com>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 21 Apr 2026 11:14:54 +0000 you wrote:
> From: Tristan Madani <tristan@talencesecurity.com>
>
> btmtk_usb_hci_wmt_sync() casts the WMT event response SKB data to
> struct btmtk_hci_wmt_evt (7 bytes) and struct btmtk_hci_wmt_evt_funcc
> (9 bytes) without first checking that the SKB contains enough data.
> A short firmware response causes out-of-bounds reads from SKB tailroom.
>
> [...]
Here is the summary with links:
- [v4] Bluetooth: btmtk: validate WMT event SKB length before struct access
https://git.kernel.org/bluetooth/bluetooth-next/c/006b9943b982
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 0/2] Bluetooth: ISO: Fix KCSAN data-races on iso_pi(sk)
From: patchwork-bot+bluetooth @ 2026-04-21 17:40 UTC (permalink / raw)
To: SeungJu Cheon
Cc: luiz.dentz, marcel, linux-bluetooth, netdev, linux-kernel, me,
skhan, linux-kernel-mentees
In-Reply-To: <20260421025122.55781-1-suunj1331@gmail.com>
Hello:
This series was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Tue, 21 Apr 2026 11:51:20 +0900 you wrote:
> Found while auditing iso_pi(sk) field accesses after a KCSAN report.
> Patch 1/2 is the reported race on iso_pi(sk)->dst in iso_sock_connect();
> patch 2/2 covers related races on other iso_pi(sk) fields accessed in
> iso_connect_{bis,cis}() and iso_connect_ind() that were found by
> inspection during the same audit.
>
> Changes in v2:
> - Patch 1/2: Use sa->iso_bdaddr directly instead of caching the
> bacmp() result in a local variable, as suggested by Luiz [1].
> This avoids reading from iso_pi(sk) entirely for the broadcast
> check.
>
> [...]
Here is the summary with links:
- [v2,1/2] Bluetooth: ISO: Fix data-race on dst in iso_sock_connect()
https://git.kernel.org/bluetooth/bluetooth-next/c/20ca2749b31a
- [v2,2/2] Bluetooth: ISO: Fix data-race on iso_pi(sk) in socket and HCI event paths
https://git.kernel.org/bluetooth/bluetooth-next/c/66d4d518020b
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [BlueZ,v1] doc: Add AI coding assistants guidelines
From: bluez.test.bot @ 2026-04-21 17:39 UTC (permalink / raw)
To: linux-bluetooth, luiz.dentz
In-Reply-To: <20260421155141.1863559-1-luiz.dentz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 990 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1083932
---Test result---
Test Summary:
CheckPatch PASS 0.28 seconds
GitLint PASS 0.21 seconds
BuildEll PASS 20.06 seconds
BluezMake PASS 638.04 seconds
MakeCheck PASS 18.28 seconds
MakeDistcheck PASS 243.02 seconds
CheckValgrind PASS 290.91 seconds
CheckSmatch PASS 346.63 seconds
bluezmakeextell PASS 181.86 seconds
IncrementalBuild PASS 644.64 seconds
ScanBuild PASS 1003.11 seconds
https://github.com/bluez/bluez/pull/2060
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove ISDN subsystem and Bluetooth CMTP
From: Randy Dunlap @ 2026-04-21 17:12 UTC (permalink / raw)
To: Luiz Augusto von Dentz, Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
skhan, marcel, mchehab+huawei, jani.nikula, gregkh, demarchi,
justonli, ivecera, jonathan.cameron, kees, marco.crivellari,
ferr.lambarginio, nihaal, mingo, tglx, linmq006, linux-doc,
linux-bluetooth
In-Reply-To: <CABBYNZ+yCH2hxbS32o6eDT7BDMLZd3YpjUZ=sfiw=z9XjMT6OQ@mail.gmail.com>
On 4/21/26 6:55 AM, Luiz Augusto von Dentz wrote:
> Hi Jakub,
>
> On Mon, Apr 20, 2026 at 10:21 PM Jakub Kicinski <kuba@kernel.org> wrote:
>>
>> Remove the ISDN (mISDN, CAPI) subsystem and Bluetooth CMTP protocol
>> from the kernel tree.
>>
>>
>
> Acked-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Please don't send 1.7 MB emails for an Ack.
See https://people.kernel.org/tglx/,
especially "Trim replies".
--
~Randy
^ permalink raw reply
* [PATCH v3 2/2] Bluetooth: virtio_bt: validate rx pkt_type header length
From: Michael Bommarito @ 2026-04-21 17:08 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth
Cc: linux-kernel, Soenke Huster, Michael S . Tsirkin, virtualization
In-Reply-To: <20260421170845.3469513-1-michael.bommarito@gmail.com>
virtbt_rx_handle() reads the leading pkt_type byte from the RX skb
and forwards the remainder to hci_recv_frame() for every
event/ACL/SCO/ISO type, without checking that the remaining payload
is at least the fixed HCI header for that type.
After the preceding patch bounds the backend-supplied used.len to
[1, VIRTBT_RX_BUF_SIZE], a one-byte completion still reaches
hci_recv_frame() with skb->len already pulled to 0. If the byte
happened to be HCI_ACLDATA_PKT, the ACL-vs-ISO classification
fast-path in hci_dev_classify_pkt_type() dereferences
hci_acl_hdr(skb)->handle whenever the HCI device has an active
CIS_LINK, BIS_LINK, or PA_LINK connection, reading two bytes of
uninitialized RX-buffer data. The same hazard exists for every
packet type the driver accepts because none of the switch cases in
virtbt_rx_handle() check skb->len against the per-type minimum HCI
header size before handing the frame to the core.
After stripping pkt_type, require skb->len to cover the fixed
header size for the selected type (event 2, ACL 4, SCO 3, ISO 4)
before calling hci_recv_frame(); drop ratelimited otherwise.
Unknown pkt_type values still take the original kfree_skb() default
path.
Use bt_dev_err_ratelimited() because both the length and pkt_type
values come from an untrusted backend that can otherwise flood the
kernel log.
Fixes: 160fbcf3bfb9 ("Bluetooth: virtio_bt: Use skb_put to set length")
Cc: stable@vger.kernel.org
Cc: Soenke Huster <soenke.huster@eknoes.de>
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Assisted-by: Claude:claude-opus-4-7
---
Changes in v3:
- new patch, split out of the v2 commit per Luiz's request on
the v2 thread so the per-pkt-type header-length check can be
reviewed on its own
Changes in v2:
- in virtbt_rx_handle(), require skb->len to cover the fixed HCI
header size for the selected pkt_type (event 2, ACL 4, SCO 3,
ISO 4) before calling hci_recv_frame(); this prevents a one-byte
HCI_ACLDATA_PKT completion from reaching
hci_dev_classify_pkt_type() and dereferencing hci_acl_hdr(skb)
over uninitialized RX buffer data when CIS/BIS/PA connections
are present
- switch the error log to bt_dev_err_ratelimited() because the
length and pkt_type values come from an untrusted backend that
can otherwise flood the kernel log
drivers/bluetooth/virtio_bt.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
index 2c5c39356a1c..140ab55c9fc5 100644
--- a/drivers/bluetooth/virtio_bt.c
+++ b/drivers/bluetooth/virtio_bt.c
@@ -198,6 +198,7 @@ static int virtbt_shutdown_generic(struct hci_dev *hdev)
static void virtbt_rx_handle(struct virtio_bluetooth *vbt, struct sk_buff *skb)
{
+ size_t min_hdr;
__u8 pkt_type;
pkt_type = *((__u8 *) skb->data);
@@ -205,16 +206,32 @@ static void virtbt_rx_handle(struct virtio_bluetooth *vbt, struct sk_buff *skb)
switch (pkt_type) {
case HCI_EVENT_PKT:
+ min_hdr = sizeof(struct hci_event_hdr);
+ break;
case HCI_ACLDATA_PKT:
+ min_hdr = sizeof(struct hci_acl_hdr);
+ break;
case HCI_SCODATA_PKT:
+ min_hdr = sizeof(struct hci_sco_hdr);
+ break;
case HCI_ISODATA_PKT:
- hci_skb_pkt_type(skb) = pkt_type;
- hci_recv_frame(vbt->hdev, skb);
+ min_hdr = sizeof(struct hci_iso_hdr);
break;
default:
kfree_skb(skb);
- break;
+ return;
}
+
+ if (skb->len < min_hdr) {
+ bt_dev_err_ratelimited(vbt->hdev,
+ "rx pkt_type 0x%02x payload %u < hdr %zu\n",
+ pkt_type, skb->len, min_hdr);
+ kfree_skb(skb);
+ return;
+ }
+
+ hci_skb_pkt_type(skb) = pkt_type;
+ hci_recv_frame(vbt->hdev, skb);
}
static void virtbt_rx_work(struct work_struct *work)
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/2] Bluetooth: virtio_bt: clamp rx length before skb_put
From: Michael Bommarito @ 2026-04-21 17:08 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth
Cc: linux-kernel, Soenke Huster, Michael S . Tsirkin, virtualization
In-Reply-To: <20260421170845.3469513-1-michael.bommarito@gmail.com>
virtbt_rx_work() calls skb_put(skb, len) where len comes directly
from virtqueue_get_buf() with no validation against the buffer we
posted to the device. The RX skb is allocated in virtbt_add_inbuf()
and exposed to virtio as exactly 1000 bytes via sg_init_one().
Checking len against skb_tailroom(skb) is not sufficient because
alloc_skb() can leave more tailroom than the 1000 bytes actually
handed to the device. A malicious or buggy backend can therefore
report used.len between 1001 and skb_tailroom(skb), causing skb_put()
to include uninitialized kernel heap bytes that were never written by
the device.
The same path also accepts len == 0, in which case skb_put(skb, 0)
leaves the skb empty but virtbt_rx_handle() still reads the pkt_type
byte from skb->data, consuming uninitialized memory.
Define VIRTBT_RX_BUF_SIZE once and reuse it in alloc_skb() and
sg_init_one(), and gate virtbt_rx_work() on that same constant so
the bound checked matches the buffer actually exposed to the device.
Reject used.len == 0 in the same gate so an empty completion can
no longer reach virtbt_rx_handle().
Use bt_dev_err_ratelimited() because the length value comes from an
untrusted backend that can otherwise flood the kernel log.
Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer
overflow in USB transport layer"), which hardened the USB 9p
transport against unchecked device-reported length.
Fixes: 160fbcf3bfb9 ("Bluetooth: virtio_bt: Use skb_put to set length")
Cc: stable@vger.kernel.org
Cc: Soenke Huster <soenke.huster@eknoes.de>
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Assisted-by: Claude:claude-opus-4-7
---
Changes in v3:
- split off the per-pkt-type header-length check into its own
patch (2/2) per Luiz's request; this patch now only covers the
used.len vs buffer-size hazard and the len == 0 path
Changes in v2:
- validate used.len against VIRTBT_RX_BUF_SIZE (the 1000 bytes
actually exposed to the device via sg_init_one()) rather than
skb_tailroom(), which can exceed 1000 due to slab padding
- reject used.len == 0 before virtbt_rx_handle() reads the
pkt_type byte, so zero-length completions can no longer pull an
empty skb into hci_recv_frame()
- switch the error log to bt_dev_err_ratelimited() because the
length value comes from an untrusted backend that can otherwise
flood the kernel log
drivers/bluetooth/virtio_bt.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c
index 76d61af8a275..2c5c39356a1c 100644
--- a/drivers/bluetooth/virtio_bt.c
+++ b/drivers/bluetooth/virtio_bt.c
@@ -12,6 +12,7 @@
#include <net/bluetooth/hci_core.h>
#define VERSION "0.1"
+#define VIRTBT_RX_BUF_SIZE 1000
enum {
VIRTBT_VQ_TX,
@@ -33,11 +34,11 @@ static int virtbt_add_inbuf(struct virtio_bluetooth *vbt)
struct sk_buff *skb;
int err;
- skb = alloc_skb(1000, GFP_KERNEL);
+ skb = alloc_skb(VIRTBT_RX_BUF_SIZE, GFP_KERNEL);
if (!skb)
return -ENOMEM;
- sg_init_one(sg, skb->data, 1000);
+ sg_init_one(sg, skb->data, VIRTBT_RX_BUF_SIZE);
err = virtqueue_add_inbuf(vq, sg, 1, skb, GFP_KERNEL);
if (err < 0) {
@@ -227,8 +228,15 @@ static void virtbt_rx_work(struct work_struct *work)
if (!skb)
return;
- skb_put(skb, len);
- virtbt_rx_handle(vbt, skb);
+ if (!len || len > VIRTBT_RX_BUF_SIZE) {
+ bt_dev_err_ratelimited(vbt->hdev,
+ "rx reply len %u outside [1, %u]\n",
+ len, VIRTBT_RX_BUF_SIZE);
+ kfree_skb(skb);
+ } else {
+ skb_put(skb, len);
+ virtbt_rx_handle(vbt, skb);
+ }
if (virtbt_add_inbuf(vbt) < 0)
return;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/2] Bluetooth: virtio_bt: harden rx against untrusted backend
From: Michael Bommarito @ 2026-04-21 17:08 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, linux-bluetooth
Cc: linux-kernel, Soenke Huster, Michael S . Tsirkin, virtualization
In-Reply-To: <CABBYNZKqx4ureNbRGEghGjGWcmMQSoiY4oUCECme_Vgn8RvYYw@mail.gmail.com>
Respin of the virtio_bt rx hardening patch, split per Luiz's
request on the v2 thread:
https://lore.kernel.org/linux-bluetooth/20260421151659.3326690-1-michael.bommarito@gmail.com/
v2 bundled two independent hazards in one commit and the commit
message got convoluted trying to explain them together. This v3
keeps each hazard in its own patch so the rationale for each is
self-contained.
Patch 1/2 keeps the original v1/v2 concern: virtbt_rx_work() calls
skb_put() with a used.len the device controls, with no validation
against the 1000-byte buffer we actually exposed to virtio via
sg_init_one(). Checking against skb_tailroom() is not enough
because alloc_skb() can leave more tailroom than 1000 bytes due to
slab padding. len == 0 is also accepted, which lets an empty skb
reach virtbt_rx_handle() where the pkt_type byte is then read from
uninitialized memory. 1/2 defines VIRTBT_RX_BUF_SIZE, reuses it in
alloc_skb() and sg_init_one(), and gates virtbt_rx_work() on
[1, VIRTBT_RX_BUF_SIZE] with bt_dev_err_ratelimited() on the drop
path.
Patch 2/2 closes a residual short-payload hazard found during v2
pre-send review. After 1/2 restricts used.len to [1, 1000], a
one-byte completion still reaches hci_recv_frame() with skb->len
pulled to 0. If that byte was HCI_ACLDATA_PKT, the ACL-vs-ISO
classification fast-path in hci_dev_classify_pkt_type()
dereferences hci_acl_hdr(skb)->handle whenever the HCI device has
an active CIS_LINK, BIS_LINK, or PA_LINK connection, reading two
bytes of uninitialized RX-buffer data. The same hazard shape
exists for every packet type because none of the switch cases in
virtbt_rx_handle() checked skb->len against the per-type minimum
HCI header. 2/2 requires skb->len to cover the fixed header size
for the selected type (event 2, ACL 4, SCO 3, ISO 4) before
calling hci_recv_frame(); drop ratelimited otherwise. Unknown
pkt_type values still take the original kfree_skb() default path.
Both patches carry the same Fixes: 160fbcf3bfb9 and Cc: stable@
as the v2 commit, because both hazards have existed since the
driver switched to skb_put() for used.len handling.
Fresh runtime repro of the original skb_over_panic on an unpatched
tree and a clean reject log with 1/2 applied are attached in the
evidence bundle referenced from the v2 thread; no runtime change
between v2 and v3 beyond the split (the final tree after 1/2+2/2
is byte-identical to the v2 commit).
Prior public versions of this patch on linux-bluetooth:
v1: <20260418000138.1848813-1-michael.bommarito@gmail.com>
v2: <20260421151659.3326690-1-michael.bommarito@gmail.com>
Michael Bommarito (2):
Bluetooth: virtio_bt: clamp rx length before skb_put
Bluetooth: virtio_bt: validate rx pkt_type header length
drivers/bluetooth/virtio_bt.c | 39 ++++++++++++++++++++++++++++-------
1 file changed, 32 insertions(+), 7 deletions(-)
--
2.53.0
^ permalink raw reply
* [bluez/bluez] 7439ad: doc: Add AI coding assistants guidelines
From: Luiz Augusto von Dentz @ 2026-04-21 16:42 UTC (permalink / raw)
To: linux-bluetooth
Branch: refs/heads/1083932
Home: https://github.com/bluez/bluez
Commit: 7439ad7aaf4fedb3971c525b270b335d81e0e002
https://github.com/bluez/bluez/commit/7439ad7aaf4fedb3971c525b270b335d81e0e002
Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Date: 2026-04-21 (Tue, 21 Apr 2026)
Changed paths:
M README
A doc/coding-assistants.rst
Log Message:
-----------
doc: Add AI coding assistants guidelines
Add doc/coding-assistants.rst with guidance for AI tools contributing to
BlueZ, covering licensing compatibility, human responsibility, and the
Assisted-by attribution format. Reference the new document from the README.
Based on similar documentation from the Linux kernel:
78d979db6cef ("docs: add AI Coding Assistants documentation")
To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
^ permalink raw reply
* RE: [v2] Bluetooth: virtio_bt: clamp rx length before skb_put
From: bluez.test.bot @ 2026-04-21 16:20 UTC (permalink / raw)
To: linux-bluetooth, michael.bommarito
In-Reply-To: <20260421151659.3326690-1-michael.bommarito@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=1083916
---Test result---
Test Summary:
CheckPatch FAIL 0.58 seconds
GitLint PASS 0.20 seconds
SubjectPrefix PASS 0.06 seconds
BuildKernel PASS 26.45 seconds
CheckAllWarning PASS 28.79 seconds
CheckSparse PASS 27.55 seconds
BuildKernel32 PASS 25.63 seconds
TestRunnerSetup PASS 570.69 seconds
IncrementalBuild PASS 25.48 seconds
Details
##############################
Test: CheckPatch - FAIL
Desc: Run checkpatch.pl script
Output:
[v2] Bluetooth: virtio_bt: clamp rx length before skb_put
WARNING: Non-standard signature: Assisted-by:
#156:
Assisted-by: Claude:claude-opus-4-7
ERROR: Unrecognized email address: 'Claude:claude-opus-4-7'
#156:
Assisted-by: Claude:claude-opus-4-7
total: 1 errors, 1 warnings, 79 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
/github/workspace/src/patch/14532726.patch has style problems, please review.
NOTE: Ignored message types: UNKNOWN_COMMIT_ID
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
https://github.com/bluez/bluetooth-next/pull/112
---
Regards,
Linux Bluetooth
^ permalink raw reply
* Re: [PATCH v1 1/6] sdio: Add syntactic sugar to store a pointer in sdio_driver_id
From: Johannes Berg @ 2026-04-21 15:54 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Ulf Hansson
Cc: Luiz Augusto von Dentz, Christian A. Ehrhardt, linux-mmc,
Greg Kroah-Hartman, Wolfram Sang, linux-kernel, Marcel Holtmann,
linux-bluetooth, Matthias Brugger, AngeloGioacchino Del Regno,
linux-mediatek, Ping-Ke Shih, linux-wireless, Felix Fietkau,
Lorenzo Bianconi, Ryder Lee, Shayne Chen, Sean Wang, Brian Norris,
Francesco Dolcini, Andy Shevchenko
In-Reply-To: <aeeFun4zdz360GCb@monoceros>
Hi Uwe,
> > It's probably better for everything all around, including the various
> > automations that test patch series, if you just flip a coin, send these
> > to either BT or WiFi, and then resend the others later :)
>
> The first patch of this series adapting sdio_device_id is technically
> mmc material.
Right.
> However to demonstrate the upside of this patch you also
> have to look at at least one of bluetooth and wifi. So even if I drop
> one of those there are still two subsystems involved.
Sure, that's fair.
> And then in my
> subjective view it doesn't matter much if I involve two or three
> subsystems. Regarding test automations I would assume that if the
> bluetooth bot sees patches #1-#4 of this series it can do something
> already (involving either testing the series only partially or finding
> all 6 patches on lore).
Yeah, that's a fair assumption, except at least for wifi, the
automations (like netdev, the nipa software) only ever runs on series
that it receives completely, since everyone gets CC'ed on random things
too much and having the full series is a proxy for "should be applied
here."
> Having said that, I'm happy if the first patch is merged and patches #2
> to #6 are discarded by the bluetooth and wifi people. I'll come back to
> them once the first patch is in a release.
>
> > All assuming we get an ACK from whoever is responsible for patch 1 to
> > merge it through some other tree :)
>
> To make this more explicit: That would be Ulf as MMC maintainer.
I'm also happy to merge the MMC (with Ulf's ACK) and WiFi parts, though
that's even scattered with my sub-maintainers, but that just needs some
coordination... I'd just like to then have a complete series on the list
so I don't have to all the (build) testing manually.
If either BT or WiFi merge the relevant patches then we can sync via
net-next pretty quickly and get all of it done soon, if the first patch
is via MMC then it'll probably take a whole other release cycle ...
johannes
^ permalink raw reply
* [PATCH BlueZ v1] doc: Add AI coding assistants guidelines
From: Luiz Augusto von Dentz @ 2026-04-21 15:51 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add doc/coding-assistants.rst with guidance for AI tools contributing to
BlueZ, covering licensing compatibility, human responsibility, and the
Assisted-by attribution format. Reference the new document from the README.
Based on similar documentation from the Linux kernel:
78d979db6cef ("docs: add AI Coding Assistants documentation")
---
README | 7 ++++++
doc/coding-assistants.rst | 47 +++++++++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+)
create mode 100644 doc/coding-assistants.rst
diff --git a/README b/README
index 74221a29ca91..1da987087355 100644
--- a/README
+++ b/README
@@ -284,6 +284,13 @@ For a working system, certain configuration options need to be enabled:
The plugin is built into bluetoothd therefore it does not need
to be package separately.
+AI Coding Assistants
+====================
+
+For guidance on using AI tools when contributing to BlueZ, see:
+ doc/coding-assistants.rst
+
+
Information
===========
diff --git a/doc/coding-assistants.rst b/doc/coding-assistants.rst
new file mode 100644
index 000000000000..3a643527fd65
--- /dev/null
+++ b/doc/coding-assistants.rst
@@ -0,0 +1,47 @@
+AI Coding Assistants
+++++++++++++++++++++
+
+This document provides guidance for AI tools and developers using AI
+assistance when contributing to BlueZ.
+
+AI tools helping with BlueZ development should follow the standard
+development process:
+
+* doc/coding-style.rst
+* doc/maintainer-guidelines.rst
+
+Licensing and Legal Requirements
+================================
+
+All contributed code must be compatible with the license of the
+respective file. The daemon is licensed under GPL-2.0, while other
+parts of the project may use different licenses such as LGPL.
+Use appropriate SPDX license identifiers.
+
+The human submitter is responsible for:
+
+* Reviewing all AI-generated code
+* Ensuring compliance with licensing requirements
+* Taking full responsibility for the contribution
+
+Attribution
+===========
+
+When AI tools contribute to development, proper attribution helps track
+the evolving role of AI in the development process. Contributions should
+include an Assisted-by tag in the following format::
+
+ Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
+
+Where:
+
+* ``AGENT_NAME`` is the name of the AI tool or framework
+* ``MODEL_VERSION`` is the specific model version used
+* ``[TOOL1] [TOOL2]`` are optional specialized analysis tools used
+ (e.g., coccinelle, sparse, smatch, clang-tidy)
+
+Basic development tools (git, gcc, make, editors) should not be listed.
+
+Example::
+
+ Assisted-by: Claude:claude-3-opus coccinelle sparse
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3] Bluetooth: hci_bcm4377: validate firmware event length in completion ring
From: kernel test robot @ 2026-04-21 15:50 UTC (permalink / raw)
To: Tristan Madani, linux-bluetooth
Cc: oe-kbuild-all, luiz.dentz, marcel, sven, marcan, asahi, stable
In-Reply-To: <20260417104639.2608008-1-tristmd@gmail.com>
Hi Tristan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on bluetooth/master]
[also build test WARNING on bluetooth-next/master linus/master v7.0 next-20260420]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Tristan-Madani/Bluetooth-hci_bcm4377-validate-firmware-event-length-in-completion-ring/20260420-161359
base: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git master
patch link: https://lore.kernel.org/r/20260417104639.2608008-1-tristmd%40gmail.com
patch subject: [PATCH v3] Bluetooth: hci_bcm4377: validate firmware event length in completion ring
config: um-allyesconfig (https://download.01.org/0day-ci/archive/20260422/202604220005.gyhLDa7b-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260422/202604220005.gyhLDa7b-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604220005.gyhLDa7b-lkp@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/linux/device.h:15,
from include/linux/async.h:14,
from drivers/bluetooth/hci_bcm4377.c:8:
drivers/bluetooth/hci_bcm4377.c: In function 'bcm4377_handle_completion':
>> drivers/bluetooth/hci_bcm4377.c:760:26: warning: format '%zu' expects argument of type 'size_t', but argument 4 has type 'int' [-Wformat=]
760 | "event data len %zu exceeds payload size %zu for ring %d\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
include/linux/dev_printk.h:156:61: note: in expansion of macro 'dev_fmt'
156 | dev_printk_index_wrap(_dev_warn, KERN_WARNING, dev, dev_fmt(fmt), ##__VA_ARGS__)
| ^~~~~~~
drivers/bluetooth/hci_bcm4377.c:759:17: note: in expansion of macro 'dev_warn'
759 | dev_warn(&bcm4377->pdev->dev,
| ^~~~~~~~
drivers/bluetooth/hci_bcm4377.c:760:69: note: format string is defined here
760 | "event data len %zu exceeds payload size %zu for ring %d\n",
| ~~^
| |
| long unsigned int
| %u
vim +760 drivers/bluetooth/hci_bcm4377.c
734
735 static void bcm4377_handle_completion(struct bcm4377_data *bcm4377,
736 struct bcm4377_completion_ring *ring,
737 u16 pos)
738 {
739 struct bcm4377_completion_ring_entry *entry;
740 u16 msg_id, transfer_ring;
741 size_t entry_size, data_len;
742 void *data;
743
744 if (pos >= ring->n_entries) {
745 dev_warn(&bcm4377->pdev->dev,
746 "invalid offset %d for completion ring %d\n", pos,
747 ring->ring_id);
748 return;
749 }
750
751 entry_size = sizeof(*entry) + ring->payload_size;
752 entry = ring->ring + pos * entry_size;
753 data = ring->ring + pos * entry_size + sizeof(*entry);
754 data_len = le32_to_cpu(entry->len);
755 msg_id = le16_to_cpu(entry->msg_id);
756 transfer_ring = le16_to_cpu(entry->ring_id);
757
758 if (data_len > ring->payload_size) {
759 dev_warn(&bcm4377->pdev->dev,
> 760 "event data len %zu exceeds payload size %zu for ring %d\n",
761 data_len, ring->payload_size, ring->ring_id);
762 return;
763 }
764
765 if ((ring->transfer_rings & BIT(transfer_ring)) == 0) {
766 dev_warn(
767 &bcm4377->pdev->dev,
768 "invalid entry at offset %d for transfer ring %d in completion ring %d\n",
769 pos, transfer_ring, ring->ring_id);
770 return;
771 }
772
773 dev_dbg(&bcm4377->pdev->dev,
774 "entry in completion ring %d for transfer ring %d with msg_id %d\n",
775 ring->ring_id, transfer_ring, msg_id);
776
777 switch (transfer_ring) {
778 case BCM4377_XFER_RING_CONTROL:
779 bcm4377_handle_ack(bcm4377, &bcm4377->control_h2d_ring, msg_id);
780 break;
781 case BCM4377_XFER_RING_HCI_H2D:
782 bcm4377_handle_ack(bcm4377, &bcm4377->hci_h2d_ring, msg_id);
783 break;
784 case BCM4377_XFER_RING_SCO_H2D:
785 bcm4377_handle_ack(bcm4377, &bcm4377->sco_h2d_ring, msg_id);
786 break;
787 case BCM4377_XFER_RING_ACL_H2D:
788 bcm4377_handle_ack(bcm4377, &bcm4377->acl_h2d_ring, msg_id);
789 break;
790
791 case BCM4377_XFER_RING_HCI_D2H:
792 bcm4377_handle_event(bcm4377, &bcm4377->hci_d2h_ring, msg_id,
793 entry->flags, HCI_EVENT_PKT, data,
794 data_len);
795 break;
796 case BCM4377_XFER_RING_SCO_D2H:
797 bcm4377_handle_event(bcm4377, &bcm4377->sco_d2h_ring, msg_id,
798 entry->flags, HCI_SCODATA_PKT, data,
799 data_len);
800 break;
801 case BCM4377_XFER_RING_ACL_D2H:
802 bcm4377_handle_event(bcm4377, &bcm4377->acl_d2h_ring, msg_id,
803 entry->flags, HCI_ACLDATA_PKT, data,
804 data_len);
805 break;
806
807 default:
808 dev_warn(
809 &bcm4377->pdev->dev,
810 "entry in completion ring %d for unknown transfer ring %d with msg_id %d\n",
811 ring->ring_id, transfer_ring, msg_id);
812 }
813 }
814
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox