CVE-2025-38307

What it actually does

Null pointer dereference in the Linux kernel ASoC Intel avs driver when parse_int_array() returns an array whose first element (length) is 0, allowing subsequent array accesses beyond index 0 to dereference a null pointer.

Why it matters to the business

Kernel crashes or denial of service on systems using affected Linux kernels, leading to unplanned reboots, loss of audio functionality, and potential disruption of workloads relying on stable kernel operation; high prevalence in Linux distributions increases exposure across servers and embedded devices.

How an attack unfolds

An attacker supplies crafted input to the avs driver that causes parse_int_array() to return a zero-length array; the driver then performs manipulations beyond index 0, triggering the null pointer dereference and potential privilege escalation or crash. Threat actors associated with Linux kernel privilege escalation campaigns could chain this with other kernel flaws for targeted attacks.

How to fix it

Upgrade linux-lts packages to fixed versions: 6.1.81-r0 for Alpaquita:23, 6.6.58-r0 or 6.12.41-r0 for Alpaquita:stream, or apply the upstream commit cc03c899e6d9812b25c3754c9a95c3830c4aec26 in custom kernel builds. Reboot after upgrade and verify the driver no longer processes zero-length arrays without checks.

How to confirm the fix worked

Confirm kernel version is at or above a listed fixed release; review source for the added length check after parse_int_array(); test with inputs that previously produced length-0 arrays and verify absence of null dereference oops in dmesg.

Typical attack path

1. Identify a target system running an affected kernel version with the avs driver enabled
2. Craft and deliver malicious audio configuration or firmware data that triggers parse_int_array() to return length 0
3. Trigger array manipulation code path beyond index 0 to cause null pointer dereference
4. Observe resulting kernel oops or panic; optionally chain with other memory corruption primitives for code execution

How to detect it

Search kernel logs (dmesg, syslog) for null pointer dereference oops messages referencing avs or parse_int_array functions; correlate with process activity involving audio subsystem or firmware loading around the time of any unexpected reboots.

What your security team should do

• Prioritize patching all affected linux-lts deployments within standard change windows given the memory corruption family and kernel context
• Monitor EPSS trend and kernel-specific threat actor activity for any increase in exploitation attempts
• Apply compensating controls such as restricting untrusted audio configuration sources until patches are deployed
• Include the fixed commit hash in automated kernel build and validation pipelines