CVE-2026-64402

What it actually does

This is a local Linux kernel memory-corruption flaw in the CoreSight UltraSoC System Memory Buffer driver when the SMB sink is used as a perf AUX sink. The vulnerable code calculates an AUX ring-buffer page index from the perf buffer head before normalizing that head value to the AUX buffer size, allowing an out-of-bounds write past the destination page array when the head value exceeds the buffer bounds. Successful exploitation can corrupt kernel memory and may lead to local privilege escalation, kernel crash, or arbitrary kernel-code execution depending on memory layout and exploit reliability.

Why it matters to the business

Systems running affected Linux kernels with the CoreSight UltraSoC SMB driver available may be exposed to a local attack that can turn an existing low-privileged foothold into full system compromise or cause system outages. The risk is highest on platforms where CoreSight tracing hardware is present and untrusted users can access perf tracing or related debug interfaces. Although this issue is not listed in CISA KEV, has low EPSS, and has no known mature public exploit, kernel memory-corruption flaws should still be prioritized on shared systems, developer workstations, embedded platforms, and production systems where local users, containers, or compromised services could reach perf or tracing interfaces.

How an attack unfolds

An attacker first obtains local code execution as a non-root or otherwise limited user on a Linux system where the vulnerable CoreSight UltraSoC SMB sink is present and reachable through perf/CoreSight tracing interfaces. The attacker configures or triggers perf AUX tracing so the SMB sink copies hardware trace data into perf AUX ring-buffer pages. By manipulating trace activity and buffer state so the perf handle head exceeds the AUX buffer size, the vulnerable path in smb_update_buffer() calls smb_sync_perf_buffer() with an unnormalized head-derived page index. The first copy operation can then write beyond the dst_pages[] array, corrupting adjacent kernel memory. From there, the outcome may be a kernel panic, denial of service, or carefully shaped kernel memory corruption that changes credentials, control data, or function pointers to gain elevated privileges. No public exploit maturity is indicated, so exploitation is expected to require platform-specific knowledge of the kernel build, hardware availability, and memory layout.

How to fix it

Apply the Linux kernel update that contains the fix for the CoreSight UltraSoC SMB smb_sync_perf_buffer() bounds normalization issue. If a distribution kernel is used, upgrade to the vendor-provided fixed kernel package rather than attempting a source-level patch. If immediate patching is not possible, reduce exposure by disabling or removing the CoreSight UltraSoC SMB driver where it is not required, blacklisting the related module if built as a module, disabling unnecessary CoreSight tracing/debug interfaces, restricting access to perf events, and limiting local shell or container access on affected systems. Consider setting kernel.perf_event_paranoid to a restrictive value, disabling unprivileged BPF if applicable, and ensuring debugfs/sysfs tracing controls are not writable by untrusted users. Reboot into the fixed kernel after installation; merely installing the package is not sufficient if the running kernel remains vulnerable.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, includes the upstream or vendor fix that normalizes the perf AUX head before deriving the page index in smb_sync_perf_buffer(). Validate with `uname -a`, distribution package metadata, vendor advisories, or kernel source/build provenance. Check whether CoreSight UltraSoC SMB support is present through loaded modules, kernel configuration, and sysfs/debugfs CoreSight device entries. Confirm mitigations by verifying untrusted users cannot access perf/CoreSight tracing paths, `kernel.perf_event_paranoid` is set restrictively, and relevant modules or devices are unavailable where not needed. After remediation, run functional checks for legitimate tracing workflows on systems that depend on CoreSight to ensure observability or hardware-debug use cases were not unintentionally broken.

Typical attack path

1. Gain local execution on a Linux host as a low-privileged user, compromised service account, or code running in a container with sufficient access to perf/tracing interfaces.
2. Confirm that CoreSight UltraSoC SMB support and relevant tracing devices are available on the system.
3. Use perf_event_open, perf tooling, or CoreSight sysfs/debugfs interfaces to configure an SMB sink as a perf AUX sink.
4. Generate trace activity and manipulate AUX buffer state so the perf head value exceeds the AUX buffer size.
5. Trigger smb_update_buffer() and smb_sync_perf_buffer() so the initial page index is calculated out of bounds.
6. Use the resulting kernel memory corruption to crash the host or attempt privilege escalation to root/kernel execution.

How to detect it

Detection should focus on signs of local abuse of perf/CoreSight tracing and on kernel memory-corruption symptoms, because successful kernel exploitation may leave few durable artifacts. Collect and review kernel logs from journald, syslog, dmesg, crash dumps, auditd, and EDR telemetry. Look for kernel oops, BUG, panic, slab corruption, general protection faults, or page faults with stack traces referencing `smb_sync_perf_buffer`, `smb_update_buffer`, `coresight`, `ultrasoc`, `perf_aux`, or perf ring-buffer handling. Review audit logs for unusual use of `perf`, direct `perf_event_open` activity where captured, access to CoreSight sysfs/debugfs paths, and writes enabling CoreSight sinks by users or services that do not normally perform hardware tracing. On systems with crash dumping enabled, preserve vmcore data and inspect whether the faulting stack traverses the UltraSoC SMB driver or perf AUX buffer copy path. Also investigate suspicious privilege changes shortly after perf/CoreSight activity, such as unexpected root shells, new setuid binaries, unauthorized service changes, or unusual kernel module loads. Threat intelligence currently does not identify named threat actors or ransomware campaigns exploiting this issue, so absence of known campaign IOCs should not be treated as proof of safety.

• smb_sync_perf_buffer
• smb_update_buffer
• coresight: ultrasoc-smb
• ultrasoc-smb
• coresight_ultrasoc_smb
• perf AUX
• perf_event_open
• /sys/bus/coresight/devices/
• /sys/kernel/debug/coresight/
• kernel.perf_event_paranoid
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• kernel panic
• slab corruption

What your security team should do

• Inventory Linux systems for kernels with CoreSight UltraSoC SMB support, prioritizing ARM/embedded/development platforms and systems exposing perf or hardware tracing to non-root users.
• Patch affected systems to a fixed vendor kernel and reboot into the updated kernel.
• If patching is delayed, disable or restrict CoreSight SMB tracing and perf AUX access for untrusted users.
• Set restrictive perf controls, such as a high `kernel.perf_event_paranoid` value, where operationally feasible.
• Review local user, container, and service-account access on systems with tracing hardware because exploitation requires local access but can potentially yield full host compromise.
• Monitor kernel logs for crashes, warnings, or stack traces involving `smb_sync_perf_buffer`, `smb_update_buffer`, CoreSight, perf AUX, or UltraSoC SMB.
• Because there is no known mature exploit and the CVE is not KEV-listed, prioritize remediation based on exposure to local users and availability of CoreSight SMB hardware rather than broad internet-facing urgency.