Linux Kernel up to 6.1.21/6.2.8 Bluetooth hci_sync.c hci_init_stage_sync out-of-bounds

Summaryinfo

A vulnerability identified as problematic has been detected in Linux Kernel up to 6.1.21/6.2.8. Affected by this issue is the function hci_init_stage_sync of the file /v6.2-bzimage/net/bluetooth/hci_sync.c of the component Bluetooth. The manipulation leads to out-of-bounds. This vulnerability is listed as CVE-2023-53057. There is no available exploit. You should upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as problematic, has been found in Linux Kernel up to 6.1.21/6.2.8. This issue affects the function hci_init_stage_sync of the file /v6.2-bzimage/net/bluetooth/hci_sync.c of the component Bluetooth. The manipulation with an unknown input leads to a out-of-bounds vulnerability. Using CWE to declare the problem leads to CWE-125. The product reads data past the end, or before the beginning, of the intended buffer. Impacted is confidentiality. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: HCI: Fix global-out-of-bounds To loop a variable-length array, hci_init_stage_sync(stage) considers that stage[i] is valid as long as stage[i-1].func is valid. Thus, the last element of stage[].func should be intentionally invalid as hci_init0[], le_init2[], and others did. However, amp_init1[] and amp_init2[] have no invalid element, letting hci_init_stage_sync() keep accessing amp_init1[] over its valid range. This patch fixes this by adding {} in the last of amp_init1[] and amp_init2[]. ================================================================== BUG: KASAN: global-out-of-bounds in hci_dev_open_sync ( /v6.2-bzimage/net/bluetooth/hci_sync.c:3154 /v6.2-bzimage/net/bluetooth/hci_sync.c:3343 /v6.2-bzimage/net/bluetooth/hci_sync.c:4418 /v6.2-bzimage/net/bluetooth/hci_sync.c:4609 /v6.2-bzimage/net/bluetooth/hci_sync.c:4689) Read of size 8 at addr ffffffffaed1ab70 by task kworker/u5:0/1032 CPU: 0 PID: 1032 Comm: kworker/u5:0 Not tainted 6.2.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04 Workqueue: hci1 hci_power_on Call Trace: <TASK> dump_stack_lvl (/v6.2-bzimage/lib/dump_stack.c:107 (discriminator 1)) print_report (/v6.2-bzimage/mm/kasan/report.c:307 /v6.2-bzimage/mm/kasan/report.c:417) ? hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154 /v6.2-bzimage/net/bluetooth/hci_sync.c:3343 /v6.2-bzimage/net/bluetooth/hci_sync.c:4418 /v6.2-bzimage/net/bluetooth/hci_sync.c:4609 /v6.2-bzimage/net/bluetooth/hci_sync.c:4689) kasan_report (/v6.2-bzimage/mm/kasan/report.c:184 /v6.2-bzimage/mm/kasan/report.c:519) ? hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154 /v6.2-bzimage/net/bluetooth/hci_sync.c:3343 /v6.2-bzimage/net/bluetooth/hci_sync.c:4418 /v6.2-bzimage/net/bluetooth/hci_sync.c:4609 /v6.2-bzimage/net/bluetooth/hci_sync.c:4689) hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154 /v6.2-bzimage/net/bluetooth/hci_sync.c:3343 /v6.2-bzimage/net/bluetooth/hci_sync.c:4418 /v6.2-bzimage/net/bluetooth/hci_sync.c:4609 /v6.2-bzimage/net/bluetooth/hci_sync.c:4689) ? __pfx_hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:4635) ? mutex_lock (/v6.2-bzimage/./arch/x86/include/asm/atomic64_64.h:190 /v6.2-bzimage/./include/linux/atomic/atomic-long.h:443 /v6.2-bzimage/./include/linux/atomic/atomic-instrumented.h:1781 /v6.2-bzimage/kernel/locking/mutex.c:171 /v6.2-bzimage/kernel/locking/mutex.c:285) ? __pfx_mutex_lock (/v6.2-bzimage/kernel/locking/mutex.c:282) hci_power_on (/v6.2-bzimage/net/bluetooth/hci_core.c:485 /v6.2-bzimage/net/bluetooth/hci_core.c:984) ? __pfx_hci_power_on (/v6.2-bzimage/net/bluetooth/hci_core.c:969) ? read_word_at_a_time (/v6.2-bzimage/./include/asm-generic/rwonce.h:85) ? strscpy (/v6.2-bzimage/./arch/x86/include/asm/word-at-a-time.h:62 /v6.2-bzimage/lib/string.c:161) process_one_work (/v6.2-bzimage/kernel/workqueue.c:2294) worker_thread (/v6.2-bzimage/./include/linux/list.h:292 /v6.2-bzimage/kernel/workqueue.c:2437) ? __pfx_worker_thread (/v6.2-bzimage/kernel/workqueue.c:2379) kthread (/v6.2-bzimage/kernel/kthread.c:376) ? __pfx_kthread (/v6.2-bzimage/kernel/kthread.c:331) ret_from_fork (/v6.2-bzimage/arch/x86/entry/entry_64.S:314) </TASK> The buggy address belongs to the variable: amp_init1+0x30/0x60 The buggy address belongs to the physical page: page:000000003a157ec6 refcount:1 mapcount:0 mapping:0000000000000000 ia flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea0005054688 ffffea0005054688 000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffffaed1aa00: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00 ffffffffaed1aa80: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00 >ffffffffaed1ab00: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 ---truncated---

The advisory is shared at git.kernel.org. The identification of this vulnerability is CVE-2023-53057 since 05/02/2025. The exploitation is known to be difficult. Technical details are known, but no exploit is available.

Upgrading to version 6.1.22 or 6.2.9 eliminates this vulnerability. Applying the patch b3168abd24245aa0775c5a387dcf94d36ca7e738/8497222b22b591c6b2d106e0e3c1672ffe4e10e0/bce56405201111807cc8e4f47c6de3e10b17c1ac is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.1.18
• 6.1.19
• 6.1.20
• 6.1.21
• 6.2.0
• 6.2.1
• 6.2.2
• 6.2.3
• 6.2.4
• 6.2.5
• 6.2.6
• 6.2.7
• 6.2.8

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion