[PATCH] Bluetooth: MGMT: validate LTK enc_size on load

[PATCH] Bluetooth: MGMT: validate LTK enc_size on load

[Keenan Dong]

Load Long Term Keys stores the user-provided enc_size and later uses
it to size fixed-size stack operations when replying to LE LTK
requests. An enc_size larger than the 16-byte key buffer can therefore
overflow the reply stack buffer.

Reject oversized enc_size values while validating the management LTK
record so invalid keys never reach the stored key state.

Fixes: 346af67b8d11 ("Bluetooth: Add MGMT handlers for dealing with SMP LTK's")
Reported-by: Keenan Dong <keenanat2000@gmail.com>
Signed-off-by: Keenan Dong <keenanat2000@gmail.com>
---
 net/bluetooth/mgmt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index e5f9287fb..adcd86c15 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -7248,6 +7248,9 @@ static bool ltk_is_valid(struct mgmt_ltk_info *key)
 	if (key->initiator != 0x00 && key->initiator != 0x01)
 		return false;
 
+	if (key->enc_size > sizeof(key->val))
+		return false;
+
 	switch (key->addr.type) {
 	case BDADDR_LE_PUBLIC:
 		return true;
-- 
2.43.0

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

[Keenan Dong]

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: Bluetooth: MGMT: require exact mesh send payload length

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 3181 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=1073915

---Test result---

Test Summary:
CheckPatch                    PENDING   0.41 seconds
GitLint                       PENDING   0.23 seconds
SubjectPrefix                 PASS      0.11 seconds
BuildKernel                   PASS      26.49 seconds
CheckAllWarning               PASS      28.96 seconds
CheckSparse                   PASS      27.52 seconds
BuildKernel32                 PASS      25.52 seconds
TestRunnerSetup               PASS      570.78 seconds
TestRunner_l2cap-tester       FAIL      28.01 seconds
TestRunner_iso-tester         PASS      36.01 seconds
TestRunner_bnep-tester        PASS      6.45 seconds
TestRunner_mgmt-tester        FAIL      113.74 seconds
TestRunner_rfcomm-tester      PASS      9.38 seconds
TestRunner_sco-tester         FAIL      14.21 seconds
TestRunner_ioctl-tester       PASS      10.18 seconds
TestRunner_mesh-tester        FAIL      11.47 seconds
TestRunner_smp-tester         PASS      8.59 seconds
TestRunner_userchan-tester    PASS      6.69 seconds
IncrementalBuild              PENDING   0.45 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_l2cap-tester - FAIL
Desc: Run l2cap-tester with test-runner
Output:
Total: 96, Passed: 95 (99.0%), Failed: 1, Not Run: 0

Failed Test Cases
L2CAP BR/EDR Server - Set PHY 3M                     Failed       0.117 seconds
##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 485 (98.2%), Failed: 5, Not Run: 4

Failed Test Cases
Adv. connectable & connected (central) - Success     Failed       2.130 seconds
Adv. non-connectable & connected (central) - Success Failed       0.123 seconds
Ext Adv. connectable & connected (central)           Failed       0.172 seconds
Ext Adv. non-connectable & connected (central)       Failed       0.171 seconds
Read Exp Feature - Success                           Failed       0.103 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
BUG: sleeping function called from invalid context at net/core/sock.c:3782
Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    1.816 seconds
Mesh - Send cancel - 2                               Timed out    1.993 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

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

[Luiz Augusto von Dentz]

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

[Keenan Dong]

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

[Keenan Dong]

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

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

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2593 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=1075891

---Test result---

Test Summary:
CheckPatch                    PENDING   0.49 seconds
GitLint                       PENDING   0.31 seconds
SubjectPrefix                 PASS      0.12 seconds
BuildKernel                   PASS      26.00 seconds
CheckAllWarning               PASS      28.47 seconds
CheckSparse                   PASS      27.98 seconds
BuildKernel32                 PASS      25.31 seconds
TestRunnerSetup               PASS      569.07 seconds
TestRunner_l2cap-tester       PASS      27.62 seconds
TestRunner_iso-tester         PASS      43.34 seconds
TestRunner_bnep-tester        PASS      6.31 seconds
TestRunner_mgmt-tester        FAIL      120.35 seconds
TestRunner_rfcomm-tester      PASS      9.42 seconds
TestRunner_sco-tester         FAIL      14.24 seconds
TestRunner_ioctl-tester       PASS      10.18 seconds
TestRunner_mesh-tester        FAIL      12.49 seconds
TestRunner_smp-tester         PASS      8.65 seconds
TestRunner_userchan-tester    PASS      6.75 seconds
IncrementalBuild              PENDING   1.07 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 489 (99.0%), Failed: 1, Not Run: 4

Failed Test Cases
Read Exp Feature - Success                           Failed       0.112 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
BUG: sleeping function called from invalid context at net/core/sock.c:3782
Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    2.736 seconds
Mesh - Send cancel - 2                               Timed out    1.992 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

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

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Wed,  1 Apr 2026 22:25:26 +0800 you wrote:
> 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.
> 
> [...]

Here is the summary with links:
  - [v2] Bluetooth: MGMT: validate mesh send advertising payload length
    https://git.kernel.org/bluetooth/bluetooth-next/c/2c12536623ca

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

RE: Bluetooth: MGMT: validate LTK enc_size on load

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 2913 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=1073914

---Test result---

Test Summary:
CheckPatch                    PENDING   0.34 seconds
GitLint                       PENDING   0.26 seconds
SubjectPrefix                 PASS      0.09 seconds
BuildKernel                   PASS      26.35 seconds
CheckAllWarning               PASS      28.36 seconds
CheckSparse                   PASS      27.72 seconds
BuildKernel32                 PASS      25.61 seconds
TestRunnerSetup               PASS      567.30 seconds
TestRunner_l2cap-tester       PASS      27.86 seconds
TestRunner_iso-tester         PASS      41.34 seconds
TestRunner_bnep-tester        PASS      6.26 seconds
TestRunner_mgmt-tester        FAIL      110.74 seconds
TestRunner_rfcomm-tester      PASS      9.32 seconds
TestRunner_sco-tester         FAIL      14.26 seconds
TestRunner_ioctl-tester       PASS      10.12 seconds
TestRunner_mesh-tester        FAIL      11.64 seconds
TestRunner_smp-tester         PASS      8.48 seconds
TestRunner_userchan-tester    PASS      6.70 seconds
IncrementalBuild              PENDING   0.46 seconds

Details
##############################
Test: CheckPatch - PENDING
Desc: Run checkpatch.pl script
Output:

##############################
Test: GitLint - PENDING
Desc: Run gitlint
Output:

##############################
Test: TestRunner_mgmt-tester - FAIL
Desc: Run mgmt-tester with test-runner
Output:
Total: 494, Passed: 485 (98.2%), Failed: 5, Not Run: 4

Failed Test Cases
Adv. connectable & connected (central) - Success     Failed       0.123 seconds
Adv. non-connectable & connected (central) - Success Failed       0.116 seconds
Ext Adv. connectable & connected (central)           Failed       0.172 seconds
Ext Adv. non-connectable & connected (central)       Failed       0.174 seconds
Read Exp Feature - Success                           Failed       0.106 seconds
##############################
Test: TestRunner_sco-tester - FAIL
Desc: Run sco-tester with test-runner
Output:
WARNING: possible circular locking dependency detected
BUG: sleeping function called from invalid context at net/core/sock.c:3782
Total: 30, Passed: 30 (100.0%), Failed: 0, Not Run: 0
##############################
Test: TestRunner_mesh-tester - FAIL
Desc: Run mesh-tester with test-runner
Output:
Total: 10, Passed: 8 (80.0%), Failed: 2, Not Run: 0

Failed Test Cases
Mesh - Send cancel - 1                               Timed out    2.136 seconds
Mesh - Send cancel - 2                               Timed out    1.996 seconds
##############################
Test: IncrementalBuild - PENDING
Desc: Incremental build with the patches in the series
Output:



---
Regards,
Linux Bluetooth

Re: [PATCH] Bluetooth: MGMT: validate LTK enc_size on load

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Sat, 28 Mar 2026 16:46:47 +0800 you wrote:
> Load Long Term Keys stores the user-provided enc_size and later uses
> it to size fixed-size stack operations when replying to LE LTK
> requests. An enc_size larger than the 16-byte key buffer can therefore
> overflow the reply stack buffer.
> 
> Reject oversized enc_size values while validating the management LTK
> record so invalid keys never reach the stored key state.
> 
> [...]

Here is the summary with links:
  - Bluetooth: MGMT: validate LTK enc_size on load
    https://git.kernel.org/bluetooth/bluetooth-next/c/2ba40afb67d1

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html