Look up another CVE · open CVE-2026-89947 in the interactive tracker
CVE-2026-89947
clk: meson: align gxbb_32k_clk_sel number of parents with actual count
Published 2026-09-16 (33 days ago) by the Linux kernel CNA. Subsystem drivers/clk. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89947 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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).
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/clk/meson/gxbb.c
- What this is
- ARM/Amlogic Meson SoC CLOCK FRAMEWORKMAINTAINERS section matched on drivers/clk/meson/ · linux-amlogic@lists.infradead.org · Maintained
Check it on the machine
grep -wE 'CONFIG_ARCH_MESON|CONFIG_COMMON_CLK_GXBB' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, i386/686, i386/686-pae, i386/rt/686-pae, ppc64el/powerpc64le
- trixieYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- forky, sidYnot built on amd64/amd64, amd64/cloud-amd64, amd64/rt-amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, loong64/loong64, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, riscv64/riscv64, s390x/s390x
- bookworm · linux-6.12Ynot built on amd64/amd64, amd64/cloud-amd64, amd64/rt/amd64, arm64/cloud-arm64, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k
- Y
- built in where it is built at all; some flavours do not build it
- Build switches
- CONFIG_ARCH_MESON, CONFIG_COMMON_CLK_GXBB
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-16 (33 days ago)source
- CVSS
- 8.0 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.18%, higher than 7.3% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/clk
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.10.236 | 5.10.270 | c86214e6178c |
| 5.15.180 | 5.15.221 | 8b2f7a411e7c |
| 6.1.134 | 6.1.188 | 1e509a6707d2 |
| 6.6.87 | 6.6.157 | 404079d124d7 |
| 6.12.23 | 6.12.110 | f6ff0e6995db |
| 6.15 | 6.18.51 | 4582949b7bad |
| 6.15 | 7.2.5 | bf85bd6e550c |
| 6.15 | 7.3 | 628b6fee9fca |
| 5.4.292 | 0 | 0 |
| 6.13.11 | 0 | 0 |
| 6.14.2 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- 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:LAttack complexity, low
- 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:NPrivileges required, none
- 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:NUser interaction, none
- 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:UScope, unchanged
- 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:HConfidentiality impact, high
- 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:LIntegrity impact, low
- 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:HAvailability impact, high
- 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.