[next] Bluetooth: hci_sync: Use cmd->num_cis instead of magic number

Commit Message

Gustavo A. R. Silva May 1, 2024, 5:50 p.m. UTC

At the moment of the check, `cmd->num_cis` holds the value of 0x1f,
which is the max number of elements in the `cmd->cis[]` array at
declaration, which is 0x1f.

So, avoid using 0x1f directly, and instead use `cmd->num_cis`. Similarly
to this other patch[1].

Link: https://lore.kernel.org/linux-hardening/ZivaHUQyDDK9fXEk@neat/ [1]
Signed-off-by: Gustavo A. R. Silva <[e-mail]>
---
 net/bluetooth/hci_sync.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

[e-mail] May 1, 2024, 6:35 p.m. UTC | #1

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=849713

---Test result---

Test Summary:
CheckPatch                    PASS      0.69 seconds
GitLint                       PASS      0.34 seconds
SubjectPrefix                 PASS      0.13 seconds
BuildKernel                   PASS      30.68 seconds
CheckAllWarning               PASS      33.46 seconds
CheckSparse                   PASS      38.84 seconds
CheckSmatch                   FAIL      34.88 seconds
BuildKernel32                 PASS      29.17 seconds
TestRunnerSetup               PASS      520.92 seconds
TestRunner_l2cap-tester       PASS      18.37 seconds
TestRunner_iso-tester         FAIL      31.48 seconds
TestRunner_bnep-tester        PASS      4.75 seconds
TestRunner_mgmt-tester        PASS      113.41 seconds
TestRunner_rfcomm-tester      PASS      7.35 seconds
TestRunner_sco-tester         PASS      15.06 seconds
TestRunner_ioctl-tester       PASS      7.95 seconds
TestRunner_mesh-tester        PASS      5.95 seconds
TestRunner_smp-tester         PASS      7.02 seconds
TestRunner_userchan-tester    PASS      5.08 seconds
IncrementalBuild              PASS      29.55 seconds

Details
##############################
Test: CheckSmatch - FAIL
Desc: Run smatch tool with source
Output:

Segmentation fault (core dumped)
make[4]: *** [scripts/Makefile.build:244: net/bluetooth/hci_core.o] Error 139
make[4]: *** Deleting file 'net/bluetooth/hci_core.o'
make[3]: *** [scripts/Makefile.build:485: net/bluetooth] Error 2
make[2]: *** [scripts/Makefile.build:485: net] Error 2
make[2]: *** Waiting for unfinished jobs....
Segmentation fault (core dumped)
make[4]: *** [scripts/Makefile.build:244: drivers/bluetooth/bcm203x.o] Error 139
make[4]: *** Deleting file 'drivers/bluetooth/bcm203x.o'
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:485: drivers/bluetooth] Error 2
make[2]: *** [scripts/Makefile.build:485: drivers] Error 2
make[1]: *** [/github/workspace/src/src/Makefile:1919: .] Error 2
make: *** [Makefile:240: __sub-make] Error 2
##############################
Test: TestRunner_iso-tester - FAIL
Desc: Run iso-tester with test-runner
Output:
Total: 122, Passed: 121 (99.2%), Failed: 1, Not Run: 0

Failed Test Cases
ISO Connect Suspend - Success                        Failed       4.184 seconds


---
Regards,
Linux Bluetooth

Kees Cook May 1, 2024, 7:15 p.m. UTC | #2

On Wed, May 01, 2024 at 11:50:02AM -0600, Gustavo A. R. Silva wrote:
> At the moment of the check, `cmd->num_cis` holds the value of 0x1f,
> which is the max number of elements in the `cmd->cis[]` array at
> declaration, which is 0x1f.
> 
> So, avoid using 0x1f directly, and instead use `cmd->num_cis`. Similarly
> to this other patch[1].
> 
> Link: https://lore.kernel.org/linux-hardening/ZivaHUQyDDK9fXEk@neat/ [1]
> Signed-off-by: Gustavo A. R. Silva <[e-mail]>
> ---
>  net/bluetooth/hci_sync.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
> index 6e15594d3565..af9513f3c451 100644
> --- a/net/bluetooth/hci_sync.c
> +++ b/net/bluetooth/hci_sync.c
> @@ -6559,7 +6559,7 @@ int hci_le_create_cis_sync(struct hci_dev *hdev)
>  		cis->cis_handle = cpu_to_le16(conn->handle);
>  		aux_num_cis++;
>  
> -		if (aux_num_cis >= 0x1f)
> +		if (aux_num_cis >= cmd->num_cis)
>  			break;
>  	}
>  	cmd->num_cis = aux_num_cis;

Yeah, good idea. No need to repeat a hard-coded value.

Reviewed-by: Kees Cook <[e-mail]>

[e-mail] May 1, 2024, 8 p.m. UTC | #3

Hello:

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

On Wed, 1 May 2024 11:50:02 -0600 you wrote:
> At the moment of the check, `cmd->num_cis` holds the value of 0x1f,
> which is the max number of elements in the `cmd->cis[]` array at
> declaration, which is 0x1f.
> 
> So, avoid using 0x1f directly, and instead use `cmd->num_cis`. Similarly
> to this other patch[1].
> 
> [...]

Here is the summary with links:
  - [next] Bluetooth: hci_sync: Use cmd->num_cis instead of magic number
    https://git.kernel.org/bluetooth/bluetooth-next/c/39e4d6fb881d

You are awesome, thank you!

Patch

diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 6e15594d3565..af9513f3c451 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -6559,7 +6559,7 @@  int hci_le_create_cis_sync(struct hci_dev *hdev)
 		cis->cis_handle = cpu_to_le16(conn->handle);
 		aux_num_cis++;
 
-		if (aux_num_cis >= 0x1f)
+		if (aux_num_cis >= cmd->num_cis)
 			break;
 	}
 	cmd->num_cis = aux_num_cis;