Bluetooth: MGMT: require exact mesh send payload length

[PATCH] Bluetooth: MGMT: require exact mesh send payload length

Posted by Keenan Dong 5 days, 3 hours ago

mesh_send() only checks that the total command length falls within a
broad range. A malformed MGMT_OP_MESH_SEND request can therefore claim
a larger adv_data_len than the bytes actually present, and the async
mesh send path later copies past the end of the stored command buffer.

Require the command length to exactly match the variable advertising
payload size before queueing the request.

Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh")
Reported-by: Keenan Dong <keenanat2000@gmail.com>
Signed-off-by: Keenan Dong <keenanat2000@gmail.com>
---
 net/bluetooth/mgmt.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index e5f9287fb..aad0da033 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2478,6 +2478,7 @@ static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
 	struct mgmt_mesh_tx *mesh_tx;
 	struct mgmt_cp_mesh_send *send = data;
 	struct mgmt_rp_mesh_read_features rp;
+	u16 expected_len;
 	bool sending;
 	int err = 0;
 
@@ -2491,6 +2492,11 @@ static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
 		return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
 				       MGMT_STATUS_REJECTED);
 
+	expected_len = struct_size(send, adv_data, send->adv_data_len);
+	if (expected_len != len)
+		return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
+				       MGMT_STATUS_INVALID_PARAMS);
+
 	hci_dev_lock(hdev);
 
 	memset(&rp, 0, sizeof(rp));
-- 
2.43.0

Re: [PATCH] Bluetooth: MGMT: require exact mesh send payload length

Posted by Luiz Augusto von Dentz 2 days, 16 hours ago

Hi Keenan,

On Sat, Mar 28, 2026 at 4:47 AM Keenan Dong <keenanat2000@gmail.com> wrote:
>
> mesh_send() only checks that the total command length falls within a
> broad range. A malformed MGMT_OP_MESH_SEND request can therefore claim
> a larger adv_data_len than the bytes actually present, and the async
> mesh send path later copies past the end of the stored command buffer.
>
> Require the command length to exactly match the variable advertising
> payload size before queueing the request.
>
> Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh")
> Reported-by: Keenan Dong <keenanat2000@gmail.com>
> Signed-off-by: Keenan Dong <keenanat2000@gmail.com>
> ---
>  net/bluetooth/mgmt.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index e5f9287fb..aad0da033 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -2478,6 +2478,7 @@ static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
>         struct mgmt_mesh_tx *mesh_tx;
>         struct mgmt_cp_mesh_send *send = data;
>         struct mgmt_rp_mesh_read_features rp;
> +       u16 expected_len;
>         bool sending;
>         int err = 0;
>
> @@ -2491,6 +2492,11 @@ static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
>                 return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
>                                        MGMT_STATUS_REJECTED);
>
> +       expected_len = struct_size(send, adv_data, send->adv_data_len);
> +       if (expected_len != len)
> +               return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
> +                                      MGMT_STATUS_INVALID_PARAMS);

Ok, I guess you are saying the following is not actually correct:

    if (!hci_dev_test_flag(hdev, HCI_LE_ENABLED) ||
        len <= MGMT_MESH_SEND_SIZE ||
        len > (MGMT_MESH_SEND_SIZE + 31))

So is MGMT_MESH_SEND_SIZE is not the size of mgmt_cp_mesh_send? Anyway
your check can probably replace these checks above, it would be great
to have these conditions covered by the likes of mesh-tester:

https://github.com/bluez/bluez/blob/master/tools/mesh-tester.c

>         hci_dev_lock(hdev);
>
>         memset(&rp, 0, sizeof(rp));
> --
> 2.43.0
>


-- 
Luiz Augusto von Dentz

Re: [PATCH] Bluetooth: MGMT: require exact mesh send payload length

Posted by Keenan Dong 21 hours ago

Hi,

I've submitted a revised version of the patch.

Regarding your comment about mesh-tester, I'm not entirely sure about
the expectation — would you like me to also add test coverage for
these conditions in tools/mesh-tester.c?

If so, should I include that as part of a new patch revision, or
handle it separately (e.g. as a PR to the BlueZ repository)?

Best regards,
Xianrui Dong






On Tue, Mar 31, 2026 at 4:07 AM Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
>
> Hi Keenan,
>
> On Sat, Mar 28, 2026 at 4:47 AM Keenan Dong <keenanat2000@gmail.com> wrote:
> >
> > mesh_send() only checks that the total command length falls within a
> > broad range. A malformed MGMT_OP_MESH_SEND request can therefore claim
> > a larger adv_data_len than the bytes actually present, and the async
> > mesh send path later copies past the end of the stored command buffer.
> >
> > Require the command length to exactly match the variable advertising
> > payload size before queueing the request.
> >
> > Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh")
> > Reported-by: Keenan Dong <keenanat2000@gmail.com>
> > Signed-off-by: Keenan Dong <keenanat2000@gmail.com>
> > ---
> >  net/bluetooth/mgmt.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> > index e5f9287fb..aad0da033 100644
> > --- a/net/bluetooth/mgmt.c
> > +++ b/net/bluetooth/mgmt.c
> > @@ -2478,6 +2478,7 @@ static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
> >         struct mgmt_mesh_tx *mesh_tx;
> >         struct mgmt_cp_mesh_send *send = data;
> >         struct mgmt_rp_mesh_read_features rp;
> > +       u16 expected_len;
> >         bool sending;
> >         int err = 0;
> >
> > @@ -2491,6 +2492,11 @@ static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
> >                 return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
> >                                        MGMT_STATUS_REJECTED);
> >
> > +       expected_len = struct_size(send, adv_data, send->adv_data_len);
> > +       if (expected_len != len)
> > +               return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
> > +                                      MGMT_STATUS_INVALID_PARAMS);
>
> Ok, I guess you are saying the following is not actually correct:
>
>     if (!hci_dev_test_flag(hdev, HCI_LE_ENABLED) ||
>         len <= MGMT_MESH_SEND_SIZE ||
>         len > (MGMT_MESH_SEND_SIZE + 31))
>
> So is MGMT_MESH_SEND_SIZE is not the size of mgmt_cp_mesh_send? Anyway
> your check can probably replace these checks above, it would be great
> to have these conditions covered by the likes of mesh-tester:
>
> https://github.com/bluez/bluez/blob/master/tools/mesh-tester.c
>
> >         hci_dev_lock(hdev);
> >
> >         memset(&rp, 0, sizeof(rp));
> > --
> > 2.43.0
> >
>
>
> --
> Luiz Augusto von Dentz

[PATCH v2] Bluetooth: MGMT: validate mesh send advertising payload length

Posted by Keenan Dong 22 hours ago

mesh_send() currently bounds MGMT_OP_MESH_SEND by total command
length, but it never verifies that the bytes supplied for the
flexible adv_data[] array actually match the embedded adv_data_len
field. MGMT_MESH_SEND_SIZE only covers the fixed header, so a
truncated command can still pass the existing 20..50 byte range
check and later drive the async mesh send path past the end of the
queued command buffer.

Keep rejecting zero-length and oversized advertising payloads, but
validate adv_data_len explicitly and require the command length to
exactly match the flexible array size before queueing the request.

Fixes: b338d91703fa ("Bluetooth: Implement support for Mesh")
Reported-by: Keenan Dong <keenanat2000@gmail.com>
Signed-off-by: Keenan Dong <keenanat2000@gmail.com>
---
v2:
- replace the raw total-length range check in mesh_send()
- keep REJECTED for zero-length and oversized advertising payloads
- reject len/adv_data_len desynchronization with INVALID_PARAMS

Validation:
- vuln kernel reproduced the field-spanning write in
  hci_set_adv_instance_data() with a minimal direct-QEMU initramfs
  repro
- fixed kernel rejected malformed MGMT_OP_MESH_SEND requests at
  ingress in the same direct-QEMU setup

 net/bluetooth/mgmt.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index e5f9287fb..18cee19aa 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2478,6 +2478,7 @@ static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
 	struct mgmt_mesh_tx *mesh_tx;
 	struct mgmt_cp_mesh_send *send = data;
 	struct mgmt_rp_mesh_read_features rp;
+	u16 expected_len;
 	bool sending;
 	int err = 0;
 
@@ -2485,12 +2486,19 @@ static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len)
 	    !hci_dev_test_flag(hdev, HCI_MESH_EXPERIMENTAL))
 		return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
 				       MGMT_STATUS_NOT_SUPPORTED);
-	if (!hci_dev_test_flag(hdev, HCI_LE_ENABLED) ||
-	    len <= MGMT_MESH_SEND_SIZE ||
-	    len > (MGMT_MESH_SEND_SIZE + 31))
+	if (!hci_dev_test_flag(hdev, HCI_LE_ENABLED))
+		return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
+				       MGMT_STATUS_REJECTED);
+
+	if (!send->adv_data_len || send->adv_data_len > 31)
 		return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
 				       MGMT_STATUS_REJECTED);
 
+	expected_len = struct_size(send, adv_data, send->adv_data_len);
+	if (expected_len != len)
+		return mgmt_cmd_status(sk, hdev->id, MGMT_OP_MESH_SEND,
+				       MGMT_STATUS_INVALID_PARAMS);
+
 	hci_dev_lock(hdev);
 
 	memset(&rp, 0, sizeof(rp));
-- 
2.43.0