CVE-2026-64482

What it actually does

This is a Linux kernel denial-of-service flaw in the ALSA Gravis Ultrasound/GUS driver path. The vulnerable code calls snd_ctl_new1(), which can return NULL when a kernel memory allocation fails, and then dereferences the returned pointer without checking it. If the allocation failure is triggered at the right point, the kernel can hit a NULL pointer dereference, causing an oops and, depending on kernel panic settings and workload, a system crash or forced reboot. The issue is not currently associated with code execution, privilege escalation, or data disclosure.

Why it matters to the business

Successful exploitation can interrupt availability of Linux systems that load or use the affected ALSA GUS driver functionality. The likely impact is service disruption rather than compromise of sensitive data. Urgency is moderate to low based on the currently low EPSS score, lack of known exploitation, lack of CISA KEV listing, and no public exploit maturity reported, but kernel denial-of-service bugs should still be addressed through normal patch cycles, especially on systems where untrusted local users can interact with audio devices or load/use related sound modules.

How an attack unfolds

An attacker would generally need local access or another way to reach the affected ALSA GUS driver code path. They would cause the vulnerable control-creation routine to run while memory allocation fails, resulting in snd_ctl_new1() returning NULL. Because the driver dereferences the returned pointer without validating it, the kernel attempts to access memory through a NULL pointer. This causes a kernel oops and may crash or reboot the host if the kernel is configured to panic on oops, or if the fault destabilizes the affected subsystem. There is no current evidence from the provided intelligence that this flaw is being used by named threat actors, ransomware campaigns, or commodity exploit kits.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the ALSA GUS fix adding a NULL check after snd_ctl_new1() and returning -ENOMEM on allocation failure. Because no exact fixed versions were provided, use the relevant Linux distribution, appliance, cloud image, or kernel vendor advisory to identify the corrected package for each platform. If immediate patching is not possible, reduce exposure by unloading and blacklisting unused GUS-related ALSA modules, limiting local user access to audio devices, disabling unneeded sound support on servers, and ensuring kernel settings and service supervision minimize operational impact from kernel oops or panic events.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the ALSA GUS patch for the snd_ctl_new1() NULL-return check in snd_gf1_pcm_volume_control(). Validate both the installed package version and the actively booted kernel, because installing a kernel update without rebooting may leave the vulnerable kernel running. Check whether GUS/ALSA modules are present or loaded using standard module inventory tooling such as lsmod, modinfo, or distribution package metadata. Where source validation is possible, confirm that the patched code checks the result of snd_ctl_new1() before accessing kctl->id.index and returns -ENOMEM on failure. After patching, reboot into the corrected kernel and confirm no vulnerable kernel remains available as the default boot target.

Typical attack path

1. Obtain local execution or another path to interact with the affected ALSA sound driver functionality.
2. Ensure the affected GUS/ALSA driver code is loaded, reachable, or autoloadable.
3. Trigger the driver routine that creates the PCM volume control.
4. Induce or coincide with a memory-allocation failure so snd_ctl_new1() returns NULL.
5. Cause the vulnerable code to dereference the NULL control pointer.
6. Crash or destabilize the kernel, resulting in denial of service.

How to detect it

Review kernel, system, and crash logs for signs of a kernel NULL pointer dereference or oops in ALSA GUS driver functions. Useful sources include journald, syslog, kern.log, dmesg output, crash dump infrastructure such as kdump/vmcore, endpoint telemetry that records kernel panics, and availability monitoring that records unexpected reboots. Focus on events involving snd_gf1_pcm_volume_control(), snd_ctl_new1(), GUS, snd-gus, ALSA control creation, or NULL pointer dereferences shortly before a crash or reboot. Because this issue is a denial-of-service condition rather than a persistence or code-execution bug, there may be no durable file, process, network, or registry artifact after reboot beyond logs and crash dumps. Correlate suspected crashes with local login/session activity and access to audio device nodes such as /dev/snd/* to determine whether the event may have been intentionally triggered.

• BUG: kernel NULL pointer dereference
• Oops: 0000
• kernel NULL pointer dereference
• snd_gf1_pcm_volume_control
• snd_ctl_new1
• snd_gf1
• snd-gus
• ALSA: gus
• /dev/snd/
• Kernel panic - not syncing

What your security team should do

• Prioritize kernel updates for systems where untrusted local users, shared shell access, desktop sessions, containers with device access, or audio device access are present.
• Inventory Linux systems for loaded or available ALSA GUS-related modules and remove or blacklist them where they are not required.
• Verify that patched kernels are not only installed but actively running after reboot.
• Monitor kernel logs for NULL pointer dereferences, oops, panics, or crashes referencing ALSA, GUS, snd_gf1, snd_ctl_new1, or snd_gf1_pcm_volume_control.
• Keep this below remotely exploitable or known-exploited vulnerabilities in emergency prioritization, given low EPSS, no KEV status, no ransomware association, and no reported exploit maturity.
• For high-availability services, review reboot/failover behavior so a kernel crash does not cause prolonged outage.