Bluetooth: MGMT: validate LTK enc_size on load

PATCH Applied Keenan Dong 4 participants 10 messages Mar 28 – Apr 1

Subsystems (2)

Bluetooth drivers Bluetooth

lore

Share & tools

lore

Keenan Dong

author

2026-03-28 08:47 UTC #0 lore raw

PATCH 1/1 Bluetooth: MGMT: validate LTK enc_size on load

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 <[email protected]>

Signed-off-by Keenan Dong <[email protected]>

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

net/bluetooth/mgmt.c +3 -0

index e5f9287fb..adcd86c15 100644
@@ -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;

Signature · 1 line

2.43.0

Keenan Dong

author

2026-03-28 08:47 UTC #1 lore raw

PATCH 1/1 Bluetooth: MGMT: require exact mesh send payload length

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 <[email protected]>

Signed-off-by Keenan Dong <[email protected]>

---
 net/bluetooth/mgmt.c | 6 ++++++
 1 file changed, 6 insertions(+)

net/bluetooth/mgmt.c +6 -0

index e5f9287fb..aad0da033 100644
@@ -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));

Signature · 1 line

2.43.0

[email protected]

2026-03-28 09:53 UTC #2 lore raw

RE: Bluetooth: MGMT: require exact mesh send payload length

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

Luiz Augusto von Dentz

maintainer

2026-03-30 20:07 UTC #3 lore raw

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

In reply to Keenan Dong

Hi Keenan,

Quoted 29 lines · 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 <[email protected]>
Signed-off-by Keenan Dong <[email protected]>
---
 net/bluetooth/mgmt.c | 6 ++++++
 1 file changed, 6 insertions(+)
net/bluetooth/mgmt.c +1 -0
index e5f9287fb..aad0da033 100644
@@ -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;
 

net/bluetooth/mgmt.c static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len) · line 2498

Quoted 7 lines

net/bluetooth/mgmt.c +4 -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

Quoted 6 lines

net/bluetooth/mgmt.c +0 -1

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

2.43.0

Signature · 1 line

Luiz Augusto von Dentz

Keenan Dong

author

2026-04-01 14:52 UTC #4 lore raw

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

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

Quoted 63 lines · Luiz Augusto von Dentz

Hi Keenan,
Quoted 29 lines · 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 <[email protected]>
Signed-off-by Keenan Dong <[email protected]>
---
 net/bluetooth/mgmt.c | 6 ++++++
 1 file changed, 6 insertions(+)
net/bluetooth/mgmt.c +1 -0
index e5f9287fb..aad0da033 100644
@@ -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;
 
net/bluetooth/mgmt.c static int mesh_send(struct sock *sk, struct hci_dev *hdev, void *data, u16 len) · line 2498
Quoted 7 lines
net/bluetooth/mgmt.c +4 -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
Quoted 6 lines
net/bluetooth/mgmt.c +0 -1
        hci_dev_lock(hdev);
 
        memset(&rp, 0, sizeof(rp));
--
2.43.0
--
Luiz Augusto von Dentz

Keenan Dong

author

2026-04-01 14:26 UTC #5 lore raw

PATCH v2 1/1 Bluetooth: MGMT: validate mesh send advertising payload length

In reply to 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 <[email protected]>

Signed-off-by Keenan Dong <[email protected]>

---
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(-)

net/bluetooth/mgmt.c +11 -3

index e5f9287fb..18cee19aa 100644
@@ -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));

Signature · 1 line

2.43.0

[email protected]

2026-04-01 15:10 UTC #6 lore raw

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

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

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

[email protected]

CI Applied

2026-04-01 18:30 UTC #7 lore raw

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

In reply to Keenan Dong

This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <[email protected]>:

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <[email protected]>:

Quoted 9 lines · 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!

Signature · 2 lines

Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

[email protected]

2026-03-28 09:52 UTC #8 lore raw

In reply to Keenan Dong

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

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

[email protected]

CI Applied

2026-03-30 20:20 UTC #9 lore raw

In reply to Keenan Dong

This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <[email protected]>:

Hello:

This patch was applied to bluetooth/bluetooth-next.git (master) by Luiz Augusto von Dentz <[email protected]>:

Quoted 9 lines · 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!

Signature · 2 lines

Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html