CVE-2026-43126

What it actually does

This is a local use-after-free vulnerability in the Linux kernel ALSA OSS mixer compatibility layer. The vulnerable code can continue invoking mixer control operations while an ALSA sound card is being disconnected, leaving a race window where stale kernel objects may be accessed after they have been freed. A local authenticated user with access to OSS mixer device interfaces could potentially trigger the race and corrupt kernel memory, leading to kernel crash or local privilege escalation with kernel-level code execution. The CVSS vector indicates local access is required, attack complexity is low, privileges are required, no user interaction is needed, and successful exploitation can compromise confidentiality, integrity, and availability of the affected host.

Why it matters to the business

Successful exploitation could allow a local user, compromised service account, container escape path with device access, or malicious workload to gain elevated privileges on a Linux system or crash it. The most likely operational impact is host instability or denial of service, but the worst case is full host compromise because the flaw is in kernel code. EPSS is currently very low and there is no known KEV listing or public exploit maturity reported, so broad internet-scale exploitation is unlikely; however, systems that expose sound devices to untrusted users, desktops, VDI environments, shared Linux workstations, kiosks, multimedia servers, or workloads with access to ALSA/OSS mixer devices have higher practical risk.

How an attack unfolds

An attacker first needs local code execution or an account on an affected Linux system. They then interact with the ALSA OSS mixer interface, typically through legacy mixer device nodes such as OSS-compatible mixer devices, while causing or racing an audio card disconnect or teardown event. By repeatedly issuing mixer operations during the disconnect window, the attacker attempts to make the kernel call mixer control operations on an object that has already been freed. If the race only causes an invalid access, the system may log a kernel oops, panic, or KASAN use-after-free report. With a reliable exploit and appropriate kernel memory-shaping techniques, the attacker may be able to turn the use-after-free into arbitrary kernel memory read/write or code execution, resulting in local privilege escalation to root/kernel privileges. No active exploitation by named threat actors is currently indicated in the supplied data.

How to fix it

Upgrade the Linux kernel to a vendor release that includes the ALSA OSS mixer disconnect-check fix for CVE-2026-43126. Because no exact fixed versions were provided, use the relevant distribution security advisory or upstream stable kernel changelog to identify the corrected package for each supported OS release. Prioritize kernels used on multi-user systems, desktop fleets, VDI hosts, multimedia systems, and any server or container platform where untrusted users or workloads can access sound devices. If immediate patching is not possible, reduce exposure by disabling or restricting access to OSS mixer compatibility devices, removing unnecessary sound device passthrough from containers/VMs, unloading unused sound drivers where operationally safe, disabling legacy OSS mixer compatibility if not required, and enforcing least privilege on device nodes such as /dev/mixer and /dev/snd/* through udev rules, groups, and container runtime policy. Reboot into the patched kernel after installation; merely installing the package is not sufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm the running kernel, not just the installed package, has been updated to a vendor build containing the fix. On Linux systems, compare `uname -r` and package manager output against the distribution advisory for this issue. Verify that systems requiring mitigation have restricted access to OSS/ALSA mixer device nodes and that untrusted users or containers cannot access audio devices unless explicitly required. Check whether legacy OSS mixer support is enabled or loaded by reviewing kernel configuration and loaded modules, for example looking for ALSA OSS mixer compatibility support. Where feasible, perform a controlled regression test by exercising normal audio mixer functionality and hotplug/disconnect behavior after patching to ensure legitimate audio workflows still function and no kernel warnings are produced.

Typical attack path

1. Obtain local authenticated access to an affected Linux system.
2. Confirm the system exposes ALSA OSS mixer compatibility interfaces or relevant sound device nodes to the attacker.
3. Run code that repeatedly opens and performs OSS mixer ioctls or mixer operations.
4. Trigger or race an ALSA sound card disconnect, teardown, suspend/resume, hot-unplug, driver unload, or equivalent device removal path.
5. Win the race so a mixer operation executes after the associated ALSA card/control object has been freed.
6. Use the resulting kernel memory corruption to crash the host or attempt local privilege escalation.
7. If privilege escalation succeeds, establish elevated persistence or access sensitive host data.

How to detect it

Look for signs of prior kernel memory corruption or privilege escalation attempts rather than network indicators, because exploitation is local. Primary log sources include kernel ring buffer output, system journal, syslog/kern.log/messages, crash dumps, audit logs, endpoint detection telemetry, and container runtime logs if audio devices are passed into containers. Search for kernel oopses, panics, KASAN or slab use-after-free reports, general protection faults, NULL or invalid pointer dereferences, and stack traces involving ALSA OSS mixer code, mixer ioctl handling, sound-card disconnect, or snd_mixer_oss-related functions. Correlate any such events with local user sessions, recently executed binaries, unusual repeated access to mixer devices, hotplug/disconnect activity, module unload/reload activity, suspend/resume events, or containers started with access to /dev/snd or /dev/mixer. Also review audit records for unexpected opens or ioctls against OSS/ALSA mixer device nodes by non-audio applications, build directories, temporary executables, scripting runtimes, or processes owned by low-privilege users. There are no known public exploit-specific indicators in the supplied data, so detections should focus on behavioral evidence and kernel fault artifacts.

What your security team should do

• Inventory Linux systems with audio hardware, virtual audio devices, ALSA OSS mixer compatibility, or exposed /dev/mixer and /dev/snd device nodes.
• Prioritize patching multi-user Linux systems, desktops, VDI platforms, kiosks, developer workstations, and container/VM hosts that pass through sound devices to untrusted workloads.
• Upgrade affected kernels to vendor-fixed releases and reboot systems into the corrected kernel.
• Where patching is delayed, remove unnecessary audio device exposure and restrict mixer device access to trusted users only.
• Review container, sandbox, and virtualization configurations for unintended passthrough of /dev/snd, /dev/mixer, or broad device permissions such as privileged containers.
• Monitor kernel logs for use-after-free, KASAN, ALSA, snd_mixer_oss, oops, BUG, panic, or suspicious local privilege escalation activity.
• Treat unexplained kernel crashes involving ALSA mixer or sound-card disconnect paths as potential exploitation attempts until ruled out.
• Because EPSS is low, no KEV listing is present, and no public exploit maturity is reported, handle this through normal kernel vulnerability SLAs unless local multi-user or untrusted-device-access exposure increases risk.