A small, targeted kernel fix patched a creeping memory leak inside the CoreSight ACPI parsing path — a defect that doesn’t expose secrets but can steadily erode system availability by leaking ACPI buffer memory allocated through acpi_buffer->pointer until a service or host runs out of memory.
Background
The Linux kernel includes a set of drivers and helpers known as
CoreSight, used primarily for CPU tracing and hardware debug on ARM platforms. CoreSight interacts with firmware-provided topology expressed in ACPI _DSD properties; the kernel queries those properties via the ACPI helpers and marshals the results into internal structures used by CoreSight during device initialization. In one of those code paths, the ACPI buffer allocated by the generic ACPI helper was not freed in all return paths, producing a detectable memory leak reported by kmemleak and recorded as CVE‑2023‑53261. This bug is a
resource-management defect rather than a memory-corruption or remote-exploit primitive. The vulnerability report and upstream patch both indicate the issue manifests as unreferenced ACPI buffer memory (the buf.pointer field) that should have been freed before exiting the parsing routine. Public trackers and distro advisories treat the impact as availability-focused: a sustained leak that, if repeatedly triggered, can cause services or a host to become unavailable.
Technical overview
What the kernel was doing
When the CoreSight platform driver queries firmware descriptors, it relies on the ACPI evaluator API to fetch _DSD (Device Specific Data) properties. The canonical pattern used by drivers is to call acpi_evaluate_object_typed with a struct acpi_buffer initialized to ACPI_ALLOCATE_BUFFER. The ACPI subsystem then fills buf.pointer with allocated memory containing parsed ACPI object data. The caller is responsible for using the pointer and freeing the buffer when it’s no longer needed. The vulnerable CoreSight path returned pointers derived from the ACPI buffer to higher-level routines without ensuring the original ACPI-allocated buffer had been released in all code paths, which left an allocation orphaned. The kernel source shows acpi_get_dsd_graph calling acpi_evaluate_object_typed and returning a pointer into buf.pointer, while the buffer itself stayed allocated.
Why that pattern leaks memory
The memory returned in buf.pointer is separately allocated by the ACPICA layer. If a function returns or continues to use a pointer into that buffer after the original acpi_buffer variable goes out of scope — but the code never invokes the corresponding free (acpi_os_free or equivalent) — the allocation remains referenced nowhere by the allocator’s tracking, and kmemleak reports it as an unreferenced object. Repeated runs of the code path (device probe, udev operations, test harnesses or repeated hotplug cycles) can accumulate such leaks until the system reaches memory pressure or critical subsystems fail. The NVD entry reproduces a kmemleak backtrace that highlights __kmalloc → acpi_os_allocate → acpi_ut_initialize_buffer → acpi_evaluate_object → coresight_get_platform_data stack frames, pointing squarely at the ACPI buffer allocation path as the leak source.
The upstream fix
Upstream maintainers addressed the problem by changing where the temporary acpi_buffer variable lived and by ensuring the allocated buffer is explicitly freed before any early returns. Concretely, the temporary variables were moved into the parsing function (acpi_coresight_parse_graph so callers are given stable pointers or copies while the original buffer is released prior to returning from the parsing function. That restructuring prevents the allocation from persisting after the function returns and eliminates the orphaned buf.pointer. The patch is small and surgical by design: the fix reorders and scopes variables and adds the missing free. Multiple vendors and tracking databases imported that upstream patch into their advisories.
Why this matters operationally
Availability impact (the practical risk)
This is not a secret-exfiltration or RCE (remote code execution) vulnerability; it’s an
availability and
resource exhaustion vulnerability. The attack model is local or service-local: software components that trigger the ACPI read path (for example, a udev probe or some provisioning service) can repeatedly cause allocations that are never freed. Over time those uncollected allocations increase memory usage, leading to:
- Repeated service restarts due to OOM (out‑of‑memory) kills.
- Degraded system responsiveness and elevated swap pressure.
- Potential kernel memory exhaustion (if allocations are in kernel-managed pools), leading to crashes or panics depending on system configuration.
Public advisories classify the severity accordingly:
Medium severity with a CVSS vector emphasizing Local attack vector, Low complexity, and High availability impact. That numeric classification is consistent across multiple trackers and distribution advisories.
Exploitability and prerequisites
Exploitation requires the attacker to be able to trigger the vulnerable path repeatedly. This means:
- Local user or process privilege sufficient to cause CoreSight to parse ACPI _DSD entries, or
- A service running on the host (for example, a device manager or udev rule) that performs the ACPI query during device events and can be induced to do so by an attacker-controlled action.
There is no public evidence (at disclosure) of remote exploitation or weaponization into a wider campaign. Absent additional chaining or higher-privilege mechanisms, this bug is not a direct remote compromise vector. Still, in multi‑tenant or hosted environments, local primitives that hurt availability are high‑value to attackers seeking to disrupt services. Advisories emphasize that the defect is operationally significant in cloud and embedded contexts where device probing is common and kernel backport cycles may lag.
Affected systems and scope
- Kernels that include the CoreSight platform codepath which parses ACPI _DSD Graph properties are the primary population at risk. This generally includes ARM/ARM64 builds for SoCs that expose CoreSight hardware and where the driver is enabled in the kernel configuration.
- Distribution kernels that shipped before the stable-tree patch and have not backported the commit remain vulnerable; distro security trackers list package ranges and status for affected branches. Administrators should consult their vendor advisories for the exact kernel package names and fixed versions.
- Embedded devices, vendor-supplied images and OEM kernels: these are the highest-risk population because vendors often maintain custom kernel trees and may not backport upstream fixes promptly. The long-tail of unpatched embedded devices makes this a real operational headache.
Detection and hunting
Because the bug is a leak rather than an immediate crash, detection is behavioral and forensic:
- Look for kmemleak reports in kernel logs. The published leak trace includes __kmalloc → acpi_os_allocate → acpi_ut_initialize_buffer → acpi_evaluate_object → coresight_get_platform_data frames. Those frames are a useful signature.
- Search kernel ring logs (dmesg, /var/log/kern.log, journalctl -k) for repeated ACPI evaluation entries, or for unexplained increases in kernel memory usage coincident with device probes.
- Monitor system memory trends and OOM events on machines that use CoreSight or perform heavy ACPI parsing (for example, repeated device attaches/detaches in automated testbeds).
- On platforms where the CoreSight driver is built as a module, check lsmod and /sys/bus/coresight for device presence. Validate whether the driver is enabled in your kernel config: grep CONFIG_CORESIGHT* /boot/config-$(uname -r) or inspect lsmod | grep coresight_trbe (or related module names) where applicable. Community hunting advice mirrors these steps.
Note: Because the bug originally showed up under kmemleak, running the kmemleak facility in a test environment is a direct way to validate whether a kernel image exhibits the leak. Where kernel builds omit kmemleak, reproduction and memory profiling become more manual and require careful instrumentation.
Remediation and mitigation
Immediate remediation
- Apply vendor/distribution kernel updates that include the upstream stable-tree commit fixing the ACPI buffer free. This is the definitive remedy — the patch reworks variable scope and inserts the missing free call so the allocation is released in all exit paths.
- Reboot into the updated kernel. Kernel-level fixes require a reboot to take effect; plan rollouts and staged reboots for production fleets.
Workarounds and compensating controls while patching
- Restrict local access: limit which local users or processes can trigger device probing (control udev rules and device node permissions), especially on multi‑tenant hosts.
- Disable or blacklist the CoreSight driver modules where the hardware is not in use and where disabling is acceptable. Use modprobe.blacklist or rebuild kernels without the driver if appropriate.
- For embedded appliances where vendor updates are not forthcoming, consider network isolation and strict process sandboxing to reduce the chance an untrusted workload can repeatedly exercise the ACPI parse path. Community advisories stress embedded vendors as the largest residual risk.
Testing and validation
After applying a kernel update:
- Reproduce a representative device probe sequence and verify kmemleak reports no lingering unreferenced ACPI buffers.
- Validate long-run memory trends on test hosts (soak tests) while exercising the CoreSight attach/detach flows to ensure the leak is gone.
- Inspect kernel changelogs to ensure the package actually includes the upstream commit ID or explicit CVE mention before declaring remediation complete; vendors sometimes backport fixes in different ways.
Timeline and cross-references
Public vulnerability databases and distribution trackers published the CVE and mapped it to upstream kernel commits in September 2025. The National Vulnerability Database (NVD) documents the leak and reproduces the kmemleak backtrace that pinpoints acpi_evaluate_object and coresight_get_platform_data as the stack frames of concern. Kernel source trees and mirrored repositories show the specific functions involved and the upstream code diffs that fixed the buffering/scoping bug. Distributors (Ubuntu, SUSE, Debian imports) and cloud vendor advisories mirrored the NVD findings and listed their package status. Cross‑verification across these independent sources confirms the same root cause and the same fix approach: ensure the ACPI buffer is freed before function exit and avoid returning pointers to memory without maintaining the allocation’s lifecycle. This consensus reduces ambiguity about what changed in the kernel and how distributions are expected to remediate.
Critical analysis: strengths and risks
Strengths
- Surgical upstream fix: The patch is minimal and constrained to variable scoping and an added free operation. Small, focused fixes are easy to review, test and backport to stable trees, which accelerates vendor absorption into distribution kernels.
- Clear observability: The leak was identified via kmemleak, a deterministic instrumentation facility, and produced a reproducible stack trace. That determinism simplifies validation and detection in test environments.
- Low regression risk: Because the fix does not change functional behavior in successful ACPI parse paths — it only alters scoping and frees the buffer — the risk of introducing a functional regression is small when compared to broad redesigns.
Residual risks and caveats
- Long tail in embedded/OEM kernels: Vendors that maintain custom kernels are often slow to backport upstream fixes. Devices in the field (SoC platforms, appliances) may remain exposed for long periods, and operational mitigations may be the only realistic near-term control for those fleets.
- Detection in production: Because the vulnerability leaks memory slowly, it might remain invisible until the leak accumulates sufficiently to affect availability. Systems with ample memory or with frequent reboots may not show symptoms quickly, delaying detection.
- Assumptions about PoC and exploitation: There is no authoritative evidence of exploitation in the wild for this CVE; that absence should be explicitly flagged as unverifiable rather than proof of safety. Attackers sometimes chain resource-management bugs with other primitives to escalate or cause systemic outages; defenders should not treat this as impossible.
Practical checklist for administrators
- Inventory:
- Determine whether your kernels include CoreSight code paths (grep for CONFIG_CORESIGHT and inspect /sys/bus/coresight).
- Map running kernel packages to vendor advisories and distro security tracker entries to confirm whether your package includes the upstream fix.
- Patch:
- Pull the vendor-supplied kernel update that lists CVE‑2023‑53261 or includes the relevant upstream commit.
- Stage updates and reboot hosts according to standard change-management.
- Validate:
- Run representative device attach/detach sequences in test rings.
- Re-run kmemleak on a test host if possible and confirm the absence of unreferenced ACPI buffer allocations.
- Compensate:
- If a patch is not immediately available, restrict device probing, harden permissions, and isolate vulnerable hosts from multi-tenant workloads.
- Document:
- Record which kernels were updated, the observed pre/post memory profiles, and any vendor communication for compliance and audit trails.
Final assessment
CVE‑2023‑53261 is a classic example of a low‑complexity, availability‑focused kernel defect: trivial to describe, trivial to fix at the code level, but operationally meaningful because kernel-level resource leaks can accumulate into serious service outages. The fix upstream is small, low-risk and already incorporated into stable trees; the real operational challenge is ensuring that distribution kernels, vendor images and embedded devices receive the backport and that teams validate the remediation in their environments.
Administrators should prioritize remediation in multi‑tenant hosts and embedded fleets, verify vendor backports where applicable, and treat the lack of public exploitation evidence as provisional. The safest course for any environment where CoreSight is used or where device probing is routine is to apply the vendor kernel update and run validation tests to ensure the leak has been eliminated.
In short: the vulnerability is fixable, the fix is well-scoped, and the operational job is straightforward — inventory, patch, reboot, and validate — but do not underestimate the long-tail exposure on embedded and vendor-supplied kernels where remediation often lags.
Source: MSRC
Security Update Guide - Microsoft Security Response Center