Look up another CVE · open CVE-2026-72016 in the interactive tracker
CVE-2026-72016
cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
Published 2026-08-15 (2 months ago) by the Linux kernel CNA. Subsystem Documentation/arch. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-72016 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 | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.1.5-1 | Update the kernel and reboot. Fixed in 7.1.5-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
On arm64, when booting with `maxcpus` greater than the number of present CPUs (e.g., QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present' but have not yet been registered via register_cpu(). Consequently, the per-cpu device objects for these CPUs are not yet initialized. In cpuhp_smt_enable(), the code iterates over all present CPUs. Calling _cpu_up() for these unregistered CPUs eventually leads to sysfs_create_group() being called with a NULL kobject (or a kobject without a directory), triggering the following warning in fs/sysfs/group.c: WARNING: fs/sysfs/group.c:137 at internal_create_group+0x41c/0x4bc, CPU#2: sh/181 [...] Call trace: internal_create_group+0x41c/0x4bc (P) sysfs_create_group+0x18/0x24 topology_add_dev+0x1c/0x28 cpuhp_invoke_callback+0x104/0x20c __cpuhp_invoke_callback_range+0x94/0x11c _cpu_up+0x200/0x37c When booting with ACPI, arm64 smp_prepare_cpus() currently sets all enumerated CPUs as "present" regardless of their status in the MADT. This causes issues with SMT hotplug control. For instance, with QEMU's "-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as follows: 1. The first four CPUs: `Enabled` set but `Online Capable` not set. 2. The remaining four CPUs: `Online Capable` set but `Enabled` not set to support potential hot-plugging. Fix this by: 1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC entry before calling set_cpu_present() during SMP initialization. 2. Properly managing the present mask in acpi_map_cpu() and acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with other architectures like x86 and LoongArch. 3. Update the arm64 CPU hotplug documentation to no longer state that all online-capable vCPUs are marked as present by the kernel at boot time. This ensures that only physically available or explicitly enabled CPUs are in the present mask, keeping the SMT control logic consistent with the actual hardware state.
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.
Documentation/arch/arm64/cpu-hotplug.rst
arch/arm64/kernel/acpi.c
arch/arm64/kernel/smp.c
- What this is
- ARM64 PORT (AARCH64 ARCHITECTURE)MAINTAINERS section matched on Documentation/arch/arm64/ · linux-arm-kernel@lists.infradead.org · Maintained
Check it on the machine
grep -w CONFIG_ACPI /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 armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le
- trixieYnot built on armel/rpi, armhf/armmp, armhf/armmp-lpae, armhf/rt/armmp, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
- forky, sidYnot built on armhf/armmp, armhf/armmp-lpae, ppc64el/powerpc64le, ppc64el/powerpc64le-64k, s390x/s390x
- Y
- built in where it is built at all; some flavours do not build it
- Build switch
- CONFIG_ACPI
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-08-15 (2 months ago)source
- CVSS
- no vector published, unrated
- Attack vector
- not published
- EPSS
- 0.21%, higher than 10.0% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- Documentation/arch
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.15 | 6.18.40 | ccdf1770a4ba |
| 6.15 | 7.1.5 | 901a489d89ee |
| 6.15 | 7.2 | f9a82544c717 |
Why the CNA scored it this way
The kernel CNA published no CVSS vector and no reasoning for CVE-2026-72016, which is why it is shown as unrated rather than given an invented score. 6,405 of the 20,413 CVEs here carry reasoning; this is not one of them.