A race condition was discovered in the Linux kernel's fastrpc unmap routine. The buffer is removed from its tracking list only after the unmap operation on the DSP has completed. If multiple threads issue concurrent unmap requests, one may delete the buffer entry while another is still performing the unmap. This ordering flaw can cause inconsistent state, potential data corruption, or crashes in the kernel or associated user‑space components. The danger lies in the fact that the affected buffer structures are shared across threads and the timing of their removal is not protected by adequate synchronization.

The vulnerability affects all Linux kernel builds that include the fastrpc subsystem. No specific kernel versions are listed, which implies that any kernel containing the unpatched fastrpc code is potentially impacted. Users of standard Linux distributions that ship the upstream kernel should assess whether their kernel includes the fastrpc module and, if so, whether it incorporates the bug‑fix commit referenced in the advisory.

Because the flaw surfaces only under concurrent use of the unmap API, the attack surface is limited to scenarios where multiple threads or processes invoke fastrpc unmap simultaneously. The EPSS score is not available and the vulnerability is not listed in CISA KEV, indicating that no widespread exploitation has been documented. However, a local attacker with sufficient privileges to trigger concurrent unmap operations could potentially exploit the race to destabilize the kernel or corrupt shared memory, leading to privilege escalation or denial of service. The CVSS score is not provided, but the nature of the vulnerability suggests at least moderate severity. The primary vector is local, requiring internal access to the kernel or the ability to run privileged code that exercises the fastrpc interface.