CVE-2025-68345 Local DoS in Linux CS35L41 HDA Driver

A recently assigned CVE, CVE-2025-68345, identifies a NULL-pointer dereference in the ALSA HDA driver for the Cirrus Logic CS35L41 audio amplifier that can crash Linux systems when the driver reads ACPI properties without checking for a missing physical ACPI node — a low-complexity, local denial-of-service bug that has already been fixed upstream and is beginning to appear in vendor trackers and distribution advisories.

Background​

The Advanced Linux Sound Architecture (ALSA) contains a large collection of codec and controller drivers for laptop and desktop audio hardware. The CS35L41 is a Cirrus Logic digital amplifier commonly connected as a side codec to the Intel HDA (High Definition Audio) controller on modern laptops; manufacturers frequently expose device configuration — including device indices and firmware-control properties — via ACPI _DSD (Device Specific Data) or related ACPI objects. The kernel’s HDA side-codec glue reads ACPI to locate device indices and to honor OEM-provided controls like mute notifications. Driver code that traverses ACPI device relationships typically calls a small set of helper functions in the kernel ACPI API: for example, acpi_dev_get_first_match_dev to find a matching ACPI device by HID, acpi_get_first_physical_node to walk to the first physical ACPI node associated with that device, and get_device to obtain a struct device pointer for subsequent property queries. If one of these helper calls returns NULL and the driver code does not check for that, dereferencing the resulting pointer will trigger a kernel oops (NULL-pointer dereference), which destabilizes the kernel and leads to a denial-of-service condition. The bug flagged in CVE-2025-68345 is exactly this class of missing-check bug.

What the vulnerability is (technical overview)​

The vulnerable code path​

The vulnerable sequence, as implemented in the HDA side-codec integration for CS35L41, performs these conceptual steps:

• Locate an ACPI device for a given HID with acpi_dev_get_first_match_dev.
• Resolve the physical ACPI node for that device via acpi_get_first_physical_node.
• Convert that ACPI node into a struct device with get_device.
• Immediately use the returned struct device pointer to query device properties such as "cirrus,dev-index" with device_property_count_u32 and device_property_read_u32_array.

The problem arises if acpi_get_first_physical_node returns NULL: get_device(NULL) then returns NULL, and the code proceeds to call device_property_count_u32(NULL, ..., which dereferences the NULL and triggers a kernel crash. In short, a missing ACPI physical node was not treated as a valid error case, and the pointer dereference was not guarded.

Root cause and discovery​

The root cause is a missing NULL check on the result of get_device(acpi_get_first_physical_node(adev). The Linux Verification Center (linuxtesting.org) identified the issue using static-analysis tooling (SVACE), and the bug report and subsequent fixes were integrated into the upstream kernel tree. The defect is a classic robustness issue rather than a memory-corruption exploit that allows arbitrary code execution. That difference matters for risk assessment: this is a reliable crash vector (availability impact) rather than a vector for data theft or privilege escalation by the same mechanism.

Severity, scope, and impact​

• Attack vector: Local (an attacker or unprivileged user with the ability to trigger the driver code paths on a target system). Several distribution trackers and security teams describe the vector as local and the required privileges as low, meaning an unprivileged process that can interact with the audio device or trigger HDA probing could provoke the crash.
• Impact: Primarily availability — a NULL-pointer dereference in kernel space causes a kernel oops and system instability or panic on systems configured to panic on oops. There is no public evidence that this flaw can be escalated into confidentiality or integrity compromises (remote code execution) by the same code path.
• CVSS / distributor scoring: One vendor tracker (SUSE) has assigned the issue a CVSS v3.1 base score of 5.5 (vector: AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), reflecting a moderate severity with high availability impact but no confidentiality or integrity impact. Other canonical sources (NVD) have published the CVE record and description but have not yet supplied an NVD-assigned score as of the CVE’s publication. The EPSS (probability-of-exploitation) tercile is very low based on early automated analysis, which is consistent with it being a local crash (not remotely exploitable).

Who is affected​

Systems running a Linux kernel that contains the vulnerable CS35L41 HDA glue code and that actually load or probe the cs35l41 HDA driver are the primary population at risk. That set includes many modern laptops where CS35L41 is used as the amplifier/codec connected over HDA, particularly OEM platforms that rely on ACPI _DSD descriptors to describe device indices or controls. Distribution security trackers (for example Debian’s tracker) list multiple kernel versions that include the affected code; many vendor trees have already merged the upstream fix into their stable/kernel maintenance branches.

Patches, timeline, and vendor responses​

The upstream Linux kernel maintainers accepted a patch that adds a proper NULL check on the device pointer returned after resolving the physical ACPI node. The patch sequence was merged into the kernel stable trees and has been referenced by multiple downstream distribution trackers and CVE aggregators. The patch is small and focused: it checks the return value after get_device(acpi_get_first_physical_node(... and bails out cleanly (returning an ERR_PTR or similar error) instead of proceeding to call device_property_count_u32 on a NULL pointer. Distribution status varies:

• Debian’s security tracker lists affected kernel versions and shows fixed versions being rolled into stable/bookworm/others according to each release’s maintenance schedule. Administrators running Debian or Debian-derived distributions should consult their local package updates and the distribution’s kernel package changelog to confirm whether a fix has been applied to their kernel version stream.
• SUSE marks the issue as resolved and rates the vulnerability as moderate in its internal evaluation. SUSE’s advisory notes stress the availability impact and the local nature of the attack vector.
• Upstream kernel trees contain the commit(s) that correct the missing NULL checks; those commits are referenced by CVE databases and have been backported into stable branches by the kernel maintainers. Several mailing-list posts and stable-tree patch announcements document the precise fix and sign-offs by maintainers.

Practical detection and mitigation steps for administrators​

The following steps provide a prioritized checklist to detect exposure, mitigate risk immediately, and apply a definitive fix. Each step is practical for system administrators or power users managing affected Linux hosts.

1. Confirm whether the system uses the cs35l41 HDA driver​

• Check loaded modules and running kernel messages:
• lsmod | grep cs35l41
• dmesg | grep -i cs35l41
• Inspect whether the HDA side-codec file exists in your kernel tree:
• grep -R "cs35l41" /lib/modules/$(uname -r) -n
• List HDA codecs/devices reported by the kernel:
• cat /proc/asound/cards
• aplay -l
  If the cs35l41 module is not present and the machine has no HDA side-codec using CS35L41, the host is not directly vulnerable.

2. Immediate short-term mitigation (if patching cannot be done right away)​

• Unload or blacklist the module — this disables the driver and prevents the vulnerable path from being exercised. Note: this removes audio functionality for affected hardware.
• Temporarily unload: sudo modprobe -r cs35l41
• To prevent loading after reboot, create a blacklist file (e.g., /etc/modprobe.d/blacklist-cs35l41.conf) with the single line: blacklist cs35l41
• Restrict local access — ensure that unprivileged users cannot access device interfaces that may trigger HDA probing. That includes removing users from audio groups and restricting write access to /dev/snd devices where applicable.
• Disable auto-mounting or auto-probing utilities that may cause late probing of ACPI/ACPI-based audio devices in specialized environments (applies to some embedded or kiosk setups).
  These mitigations reduce availability risks but come at the cost of audio functionality. They are pragmatic when administrators cannot immediately install kernel updates.

3. Definitive fix — apply patched kernels or distribution security updates​

• Apply kernel security updates provided by your distribution as soon as they are available and verified for your platform.
• For custom kernels, pull the upstream stable commit(s) that implemented the null-check fix into your kernel tree and rebuild. The fix is small and suitable for backporting into maintenance trees.
• Reboot into the updated kernel after installation to ensure the patched driver is loaded and the vulnerable code path is no longer present.
  Distribution trackers show that fixes have been merged into various stable kernel branches; verify package changelogs or kernel version numbers to ensure your host is running a fixed release.

Why this class of bug keeps appearing (analysis)​

Audio and power-management drivers in the kernel frequently walk ACPI trees and cross-reference devices and firmware-provided descriptors. That code must reconcile platform-specific ACPI quirks with general kernel abstractions for device properties. Several factors make this an endemic class of defect:

• Complex ACPI semantics: ACPI tables and OEM _DSD blobs may be present, absent, or malformed depending on BIOS/UEFI versions and OEM integrations. Helper functions that resolve ACPI nodes can legitimately return NULL on systems with incomplete or intentionally atypical ACPI descriptions.
• Low visibility in functional testing: These corner cases often occur only on specific OEM platforms and are less likely to be covered by standard QA test matrices. The Linux Verification Center and static-analysis tools are increasingly helpful at discovering such checks that were simply missed by human reviewers.
• Tight timing of driver initialization: Device probing order and late binding of side-codecs can interact with power-management features and suspend/resume paths, exposing race and null-path errors only under particular conditions (for example, after certain firmware updates or on specific boot paths).
• Legacy interop code: Support for side-codecs and new amplifier families often reuses plumbing designed for older chips; small differences in expected ACPI topology can lead to missing checks being overlooked.

This specific CVE is a robust example of a non-exploitable kernel vulnerability that nonetheless matters because it causes real-world system instability on production hardware.

Risk assessment and realistic exploitation scenarios​

• Denial-of-service (DoS): This is the most realistic scenario. A local, unprivileged user or a local daemon that can trigger the audio driver’s ACPI probing path (for example by rescanning devices or by invoking device-property queries) can cause a kernel oops and potentially a panic. On desktop laptops, an application that attempts to enumerate or reconfigure audio devices could be sufficient to trigger the issue on vulnerable kernels.
• Remote exploitation: There is no public indication that the corrupt or missing ACPI node can be induced remotely in a way that would cascade into remote code execution. The bug is rooted in a local device topology inconsistency and is not a remotely reachable service interface. Attackers would need local code-execution or local code-execution-equivalent capabilities to exploit the issue.
• Persistent or cascading failure: Repeated kernel oopses could cause persistent device logs, NVRAM or firmware-related issues on some platforms if panic behavior and kernel dump handling are misconfigured, but these are secondary effects.

Broader implications for kernel maintainers and OEMs​

This CVE validates two complementary lessons:

• The value of automated static analysis and verification tooling. The vulnerability was discovered by the Linux Verification Center using SVACE; the tool found a missing NULL check that might have been missed by manual review. Continued investment in static-analysis and model-based verification should yield more preemptive fixes for similar classes of bugs.
• OEM-provided ACPI remains a brittle interface. When manufacturers rely on _DSD blobs and platform-specific ACPI wiring, portability and robustness issues often surface in the kernel driver layer. OEMs must be encouraged to test ACPI data across firmware revisions before shipping, and to coordinate with upstream kernel maintainers when ACPI changes are required. The kernel community’s model of rapid fixes and stable-branch backports remains key to limiting exposure windows for users.

Recommended policy for teams and vendors​

• Patch quickly, test conservatively. For vendors and enterprise teams, prioritize the kernel update if the vulnerable driver is present and in use, but validate the patch on representative hardware before mass deployment to avoid regressions on platform-specific ACPI semantics.
• Add targeted tests. For teams that manage fleets of Linux laptops, add a simple probe test to validate ACPI node resolution for key HDA devices during firmware update cycles. This detects regressions before they hit users.
• Use least-privilege on user-facing services. Reduce the number of local processes that require direct access to audio device interfaces; adopt access controls and containerization where appropriate.
• Monitor upstream stable branches for backports. Kernel stable branches often receive backports of these small fixes; maintainers and integrators should track these branches or vendor advisories to ensure fixes are applied to supported releases.

---

Conclusion​

CVE-2025-68345 is a concise, actionable example of the kind of robustness bug that still appears in hardware-support code: a missing NULL check in the CS35L41 HDA glue path that results in a local-denial-of-service due to a kernel NULL-pointer dereference while reading ACPI properties. The issue was discovered by automated analysis, fixed upstream with small, mechanical changes, and is being rolled into distribution kernel trees; vendor trackers characterize it as a moderate-severity availability issue that requires attention primarily on systems that actually load the cs35l41 HDA driver.
For system administrators and maintainers: verify whether your hosts use the CS35L41 HDA driver, prioritize the kernel updates supplied by your distribution, and apply short-term mitigations (module unload/blacklist and tightened local access controls) where immediate patching is impractical. The underlying lesson remains the same — driver-level checks against NULL returns from hardware topology helpers are small, inexpensive defenses that prevent disproportionate system-wide impact when platform ACPI data is absent or malformed.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center