Cloudanix VulnDB

CVE-2026-68346

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in Linux audio drivers can slowly use up memory or crash the system when handling certain hardware control information from the firmware.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Memory leak of ACPI _DSM result objects on every successful mute-state query plus potential invalid pointer dereference when a malformed firmware response returns a non-buffer object or empty buffer.

Why it matters to the business

Gradual kernel memory exhaustion or kernel crashes on affected Linux audio hardware can cause system instability, audio failures, and require reboots, increasing operational overhead for device fleets.

How an attack unfolds

An attacker supplies or modifies ACPI firmware tables so that the _DSM method returns an unexpected object type or empty buffer; the driver then dereferences an invalid pointer or leaks objects on every call, leading to denial of service.

How to fix it

Apply the upstream kernel patch that replaces the raw _DSM call with the typed helper, adds buffer-length validation, and frees the returned object after use.

How to confirm the fix worked

Confirm the patched driver source contains the typed _DSM helper, explicit buffer-size check, and acpi_free call; boot on hardware with the mute _DSM and verify no kmemleak reports or crashes on mute-state queries.

Typical attack path

  1. Obtain local or firmware-level access to supply crafted ACPI tables
  2. Trigger repeated calls to cs35l41_get_acpi_mute_state via audio mute operations
  3. Observe kernel memory consumption or trigger invalid memory access resulting in panic

How to detect it

Inspect kernel logs for ACPI or ALSA warnings around cs35l41, monitor kmemleak reports for unfreed ACPI objects, and look for repeated calls to _DSM methods in firmware traces.

What your security team should do

  • Prioritize kernel updates containing the ALSA cs35l41 fix for all Linux distributions
  • Monitor vendor advisories for backported patches in LTS kernels
  • Enable kmemleak or similar leak detectors in test environments to surface repeated leaks

The record

In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: cs35l41: validate and free ACPI mute object cs35l41_get_acpi_mute_state() evaluates a _DSM method to get the ACPI mute state and reads the first byte from the returned object. However, the returned ACPI object is owned by the caller and is never freed after use, so each successful query leaks the _DSM result object. The code also assumes that the returned object is a buffer with at least one byte. A malformed firmware response can return a different object type or an empty buffer, and the direct ret->buffer.pointer dereference can then access an invalid pointer. Use the typed _DSM helper, validate that the returned buffer contains at least one byte, and free the ACPI object after reading it.

Affected packages

Ecosystem Package Introduced Fixed