CVE-2026-64133

What it actually does

This is a local Linux kernel vulnerability in the ALSA asihpi driver. A caller that can reach the affected control-cache lookup path may provide or influence an invalid control index, causing find_control() to access an array outside its valid bounds. Depending on kernel build, memory layout, and runtime conditions, an out-of-bounds access in kernel space can result in information disclosure, kernel memory corruption, system crash, or potentially local privilege escalation. The CVSS vector indicates local access with low attack complexity and low privileges, no user interaction, and high confidentiality, integrity, and availability impact.

Why it matters to the business

Systems running affected Linux kernels with the ALSA asihpi driver available may be exposed to local privilege escalation or denial-of-service risk. The practical business impact is highest on shared Linux servers, workstations, build systems, audio-processing hosts, and multi-user environments where untrusted or semi-trusted local users, containers, or workloads may interact with sound devices. This issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has low EPSS, and has no known public exploit maturity in the provided data, so it should be prioritized as a normal kernel security update unless the driver is exposed on high-risk multi-user systems.

How an attack unfolds

An attacker first needs local access to a system running an affected Linux kernel where the asihpi ALSA driver is present and reachable. The attacker then interacts with ALSA control interfaces in a way that causes the driver to look up cached control information using an invalid or out-of-range index. Because the vulnerable code did not sufficiently validate the index before accessing the cache array, the kernel may read or reference memory outside the intended array bounds. A basic exploit may cause a kernel warning, oops, or panic, producing denial of service. A more advanced exploit would attempt to shape kernel memory and repeatedly trigger the flawed path to disclose kernel memory or corrupt execution state, potentially escalating from a low-privileged local account to kernel-level privileges. No active exploitation, ransomware use, or named threat actor activity is indicated in the provided data.

How to fix it

Upgrade to a Linux kernel version or vendor kernel package that includes the ALSA asihpi bounds-checking fix for find_control(). Because no exact fixed versions were provided, use the security advisory from the relevant distribution or kernel vendor to identify the corrected package. Where immediate patching is not possible, reduce exposure by unloading or blacklisting the snd_asihpi/asihpi driver if the AudioScience HPI hardware and ALSA asihpi functionality are not required, restricting local shell access to trusted users, limiting container/device access to sound devices, and ensuring untrusted workloads cannot access ALSA control devices such as /dev/snd/controlC*. Mitigations should be treated as temporary; the durable fix is to deploy a corrected kernel.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package is at or above the vendor-fixed version and that the installed kernel changelog includes the ALSA asihpi out-of-bounds access fix. Reboot into the patched kernel after installation; merely installing a kernel package is not sufficient if the system continues running the vulnerable kernel. Check whether the asihpi module is loaded using kernel module inventory commands and confirm it is either patched or not present/loaded where not needed. For mitigation validation, verify that the driver is blacklisted and absent from lsmod output, and that ALSA sound control device permissions do not grant access to untrusted users or containers. Security teams may also run authenticated vulnerability scans or kernel package compliance checks against distribution advisories once vendor-fixed package identifiers are available.

Typical attack path

1. Obtain local low-privileged access to a Linux system running an affected kernel.
2. Confirm that the ALSA asihpi driver or related sound hardware/control interface is present and accessible.
3. Open or interact with ALSA control device interfaces exposed by the system.
4. Supply or trigger an invalid control index that reaches the vulnerable find_control() cache lookup path.
5. Cause an out-of-bounds kernel array access, resulting in a crash, memory disclosure, memory corruption, or potential privilege escalation.
6. If pursuing privilege escalation, iterate the trigger while manipulating local memory layout to obtain kernel-level code execution or credentials.

How to detect it

Because this is a local kernel driver vulnerability, exploitation is unlikely to leave network indicators. Review host-based telemetry and kernel logs for evidence of abnormal ALSA/asihpi activity followed by kernel warnings, oopses, panics, KASAN/UBSAN reports, general protection faults, or unexpected reboots. Useful log sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, auditd records for access to /dev/snd/controlC* devices, endpoint detection telemetry for local proof-of-concept execution, kernel crash dumps, and console logs. Investigate events where low-privileged users or containers accessed ALSA control devices shortly before kernel instability. Also review module load history for snd_asihpi/asihpi and correlate with crashes or privilege changes. There are no provided public exploit artifacts or threat actor indicators, so detection should focus on behavioral evidence of local driver probing and kernel fault artifacts rather than fixed hashes or external IP addresses.

• asihpi
• snd_asihpi
• /dev/snd/controlC
• ALSA: asihpi
• find_control
• kernel BUG
• BUG: kernel
• Oops:
• general protection fault
• KASAN:
• UBSAN:
• kernel panic
• snd_asihpi.ko
• asihpi.ko

What your security team should do

• Inventory Linux systems for affected kernel versions and for presence of the ALSA asihpi/snd_asihpi driver.
• Prioritize patching multi-user Linux systems, developer workstations, shared compute hosts, container hosts with device passthrough, and audio-processing systems where local users or workloads are less trusted.
• Apply the vendor-provided kernel update containing the ALSA asihpi bounds-check fix and reboot into the updated kernel.
• If patching is delayed and the driver is not required, unload and blacklist the asihpi/snd_asihpi module.
• Restrict access to /dev/snd/* devices from untrusted users, containers, and sandboxed workloads until patched.
• Monitor kernel logs for oops, BUG, general protection fault, KASAN, UBSAN, or panic events mentioning asihpi, snd_asihpi, ALSA, or sound control operations.
• Do not treat this as an internet-exposed remote code execution issue; current urgency is driven by local access risk, shared-system exposure, and kernel privilege impact rather than known exploitation.