CVE-2026-43480

What it actually does

This is a local availability vulnerability in the Linux kernel AMD ASoC audio machine driver for ACP3x systems using the RT5682 and MAX9836 audio components. The vulnerable initialization path calls clk_get() but fails to verify whether clock acquisition returned an error pointer. If clock acquisition fails, later code can dereference that error pointer in the RT5682 clock-enable path, causing a kernel oops or panic. The impact is denial of service only: there is no indicated confidentiality or integrity impact, and exploitation requires local access and a system where the affected driver is present and can be exercised.

Why it matters to the business

Affected Linux systems can be crashed by a local user or local workload under the right hardware and driver conditions, causing service interruption, endpoint downtime, loss of unsaved work, or operational disruption. The CVSS score is moderate and EPSS is very low, and the issue is not listed in CISA KEV or associated with ransomware, so urgency is highest for shared Linux workstations, kiosks, lab machines, multi-user systems, and fleets using AMD ACP3x audio hardware rather than for remotely exposed servers.

How an attack unfolds

An attacker first needs local access to an affected Linux system that loads the AMD ACP3x RT5682/MAX9836 ASoC machine driver. The attacker then attempts to trigger or re-trigger the vulnerable audio driver initialization path under conditions where the required clock lookup fails. Because the driver does not check the error return from clk_get(), the failed clock reference can be passed into the RT5682 clock-enable routine and dereferenced as if it were valid. That dereference can fault in kernel context, producing an oops or panic and making the system unstable or unavailable. There is no evidence from the provided data of public weaponization, remote exploitation, KEV listing, ransomware use, privilege escalation, code execution, or data theft.

How to fix it

Upgrade to a Linux kernel version or distribution kernel package that includes the fix for the AMD ASoC ACP3x RT5682/MAX9836 driver. The corrected implementation replaces unmanaged clk_get() usage with device-managed devm_clk_get() and adds IS_ERR() checks for both clock acquisition operations before the clocks are used. No exact fixed upstream or distribution package versions were provided, so use the relevant vendor advisory, distribution changelog, or stable kernel release notes to identify the first fixed build for each supported platform. If immediate patching is not possible and the affected audio hardware is not required, consider temporarily disabling or blacklisting the affected ASoC machine driver/module, disabling the relevant onboard audio device in firmware where feasible, or limiting local access to systems that load the driver. These mitigations may reduce audio functionality and should be tested before broad deployment.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the patch for the ACP3x RT5682/MAX9836 ASoC driver, not merely that an updated package is installed. Check the running kernel with uname -a and the package manager, then compare against the vendor-fixed kernel version or inspect the patched source/build metadata for devm_clk_get() and IS_ERR() checks in the acp3x_5682_init() clock acquisition logic. Validate exposure by checking whether the affected driver is present or loaded, whether the platform uses AMD ACP3x audio with RT5682/MAX9836 components, and whether kernel logs show prior oops or panic traces involving acp3x_5682_init or rt5682_clk_enable. After patching, reboot into the fixed kernel and confirm that driver initialization, audio use, suspend/resume, and module load/unload behavior do not produce kernel oops or panic messages.

Typical attack path

1. Gain local access to an affected Linux system, such as through an interactive account, local application execution, or another foothold.
2. Confirm the system uses the affected Linux kernel driver path for AMD ACP3x audio with RT5682/MAX9836 components.
3. Trigger loading, probing, suspend/resume, reinitialization, or another code path that invokes acp3x_5682_init().
4. Cause or wait for a clock acquisition failure during driver initialization.
5. The vulnerable code passes an unchecked error pointer into the RT5682 clock-enable path.
6. The kernel dereferences the invalid pointer, causing a kernel oops, panic, or system instability.
7. The system experiences denial of service until recovered or rebooted.

How to detect it

To determine whether this issue was already triggered, review kernel logs, persistent journal entries, crash dumps, and system availability telemetry for local kernel faults tied to the AMD ACP3x RT5682/MAX9836 audio driver. Useful sources include dmesg output, /var/log/kern.log, /var/log/messages, journalctl -k, systemd journal persistence, kdump/vmcore repositories, apport/ABRT crash records, and endpoint monitoring data showing unexpected reboots or kernel panics. Focus on stack traces containing acp3x_5682_init(), rt5682_clk_enable(), clk_get(), devm_clk_get(), snd-soc-acp3x-rt5682-max9836, or the source path for the ACP3x RT5682/MAX9836 machine driver. Because this is a denial-of-service condition rather than a post-compromise payload, detection is based on crash signatures and suspicious timing around local user activity, driver load/probe events, audio initialization, suspend/resume, or repeated reboots. There are no known attacker infrastructure indicators from the provided data.

• acp3x_5682_init
• rt5682_clk_enable
• acp3x-rt5682-max9836
• snd-soc-acp3x-rt5682-max9836
• sound/soc/amd/acp3x/acp3x-rt5682-max9836.c
• Unable to handle kernel paging request
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• RIP: rt5682_clk_enable
• Call Trace: acp3x_5682_init
• clk_get

What your security team should do

• Prioritize patching Linux endpoints and multi-user systems that use AMD ACP3x audio hardware and load the RT5682/MAX9836 ASoC driver.
• Confirm whether enterprise Linux distributions, appliance vendors, or endpoint images have backported the fix, since fixed versions may differ from upstream kernel versions.
• For systems that cannot be patched quickly, assess whether the affected audio driver can be disabled or blacklisted without business impact.
• Restrict local shell access and untrusted workload execution on affected systems until patched, because exploitation requires local access.
• Search kernel logs and crash repositories for oops or panic traces involving acp3x_5682_init, rt5682_clk_enable, or the acp3x-rt5682-max9836 driver.
• Ensure systems are rebooted into the fixed kernel after patch installation; installing a kernel update alone is insufficient.
• Track vendor advisories for exact fixed package versions and include this issue in routine Linux kernel patch compliance reporting.