In the Linux kernel, the following vulnerability has been resolved:
clk: meson: align gxbb_32k_clk_sel number of parents with actual count
The following out-of-bounds read has been observed by Christian on a
GXBB WeTek Hub:
==================================================================
BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418
Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT
Hardware name: WeTek Hub (DT)
Call trace:
show_stack+0x14/0x20 (C)
dump_stack_lvl+0x74/0x94
print_report+0x164/0x4b0
kasan_report+0x98/0xd8
__asan_report_load8_noabort+0x1c/0x24
__clk_register+0x1b70/0x2418
devm_clk_hw_register+0x74/0x15c
meson_clkc_init+0xd4/0x20c
meson_clkc_syscon_probe+0x5c/0x94
platform_probe+0xbc/0x17c
really_probe+0x184/0x844
__driver_probe_device+0x154/0x35c
driver_probe_device+0x60/0x188
__driver_attach+0x168/0x4a0
bus_for_each_dev+0xec/0x180
driver_attach+0x38/0x58
bus_add_driver+0x238/0x4c0
driver_register+0x150/0x388
__platform_driver_register+0x54/0x7c
gxbb_clkc_driver_init+0x18/0x20
do_one_initcall+0xb8/0x340
kernel_init_freeable+0x49c/0x52c
kernel_init+0x24/0x148
ret_from_fork+0x10/0x20
The buggy address belongs to the variable:
gxbb_32k_clk_parents+0x60/0x400
The buggy address belongs to a vmalloc virtual mapping
The buggy address belongs to the physical page:
Memory state around the buggy address:
ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9
ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
^
ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9
ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9
==================================================================
Commit 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock
parent") dropped a non-existing clock parent from the gxbb_32k_clk_sel
mux but didn't adjust the hard-coded num_parents field. Fix the actual
number of parents of that mux by using ARRAY_SIZE instead (avoiding
similar problems in future).
CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H
CVSS Score: 8
AV:L - The over-read is reached only via meson_clkc_syscon_probe → meson_clkc_init → devm_clk_hw_register → __clk_register while binding amlogic,gxbb-clkc/gxl-clkc from the device tree on Amlogic S905/S905X boards; there is no network, adjacent-radio, or USB path into this clock controller.
AC:L - gxbb_32k_clk_sel hard-coded num_parents=4 against a 3-entry gxbb_32k_clk_parents array, so every probe deterministically reads parent_data[3] in clk_core_populate_parent_map(); no race, timing window, or attacker-uncontrollable layout is required.
PR:N - meson_clkc_syscon_probe runs from driver-core bind during kernel_init (swapper/0) with no capability, credential, or user-namespace check, so the defect fires automatically on affected GXBB/GXL hardware without any attacker privileges.
UI:N - Clock registration happens automatically at boot or deferred probe from the device tree; no victim action such as mounting a filesystem or opening a device is required.
S:U - The parent_data over-read, kstrdup of the dangling parent name, and any wild clk_hw dereference stay inside the host kernel clock framework; this is not a VM escape, IOMMU/DMA bypass, or sandbox breakout.
C:H - clk_core_populate_parent_map() copies an extra clk_parent_data and passes the out-of-bounds fw_name/name pointers to kstrdup_const(), which does an unbounded strlen/copy; those bytes are stored as a mux parent name and can be emitted by clk debugfs possible_parents (mode 0444).
I:L - The garbage parent is written into the in-bounds kmalloc'd parent map and can make the 2-bit 32k mux select bogus index 3 / program HHI_32K_CLK_CNTL from table[3], corrupting clock topology without an arbitrary kernel write or control-flow hijack.
A:H - KASAN reports a global-out-of-bounds read in __clk_register, and without KASAN kstrdup_const() or clk_core_fill_parent_index()'s entry->hw->core dereference of the stale pointer can oops or panic during boot probe.
| Attack Vector |
Local |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
None |
Integrity Impact |
Low |
| User Interaction |
None |
Availability Impact |
High |
AV:L - The over-read is reached only via meson_clkc_syscon_probe → meson_clkc_init → devm_clk_hw_register → __clk_register while binding amlogic,gxbb-clkc/gxl-clkc from the device tree on Amlogic S905/S905X boards; there is no network, adjacent-radio, or USB path into this clock controller.
AC:L - gxbb_32k_clk_sel hard-coded num_parents=4 against a 3-entry gxbb_32k_clk_parents array, so every probe deterministically reads parent_data[3] in clk_core_populate_parent_map(); no race, timing window, or attacker-uncontrollable layout is required.
PR:N - meson_clkc_syscon_probe runs from driver-core bind during kernel_init (swapper/0) with no capability, credential, or user-namespace check, so the defect fires automatically on affected GXBB/GXL hardware without any attacker privileges.
UI:N - Clock registration happens automatically at boot or deferred probe from the device tree; no victim action such as mounting a filesystem or opening a device is required.
S:U - The parent_data over-read, kstrdup of the dangling parent name, and any wild clk_hw dereference stay inside the host kernel clock framework; this is not a VM escape, IOMMU/DMA bypass, or sandbox breakout.
C:H - clk_core_populate_parent_map() copies an extra clk_parent_data and passes the out-of-bounds fw_name/name pointers to kstrdup_const(), which does an unbounded strlen/copy; those bytes are stored as a mux parent name and can be emitted by clk debugfs possible_parents (mode 0444).
I:L - The garbage parent is written into the in-bounds kmalloc'd parent map and can make the 2-bit 32k mux select bogus index 3 / program HHI_32K_CLK_CNTL from table[3], corrupting clock topology without an arbitrary kernel write or control-flow hijack.
A:H - KASAN reports a global-out-of-bounds read in __clk_register, and without KASAN kstrdup_const() or clk_core_fill_parent_index()'s entry->hw->core dereference of the stale pointer can oops or panic during boot probe.
CVSS 3.1