Linux Kernel iommufd Race CVE-2024-26785 Patch for Local DoS

The Linux kernel received a targeted fix for a race-related protection fault in its IOMMU userspace subsystem — a patch tracked as CVE-2024-26785 that corrects a null-pointer / protection-fault condition reachable via the iommufd selftest ioctl paths and closes a locally exploitable denial‑of‑service vector.

Background / Overview​

The vulnerability lives inside the iommufd subsystem — the kernel’s userspace-facing API for managing I/O page tables and I/O address spaces (IOAS) from userspace. The bug was discovered by the Syzkaller fuzzing infrastructure and reported upstream after a KASAN / kernel oops trace exposed a general protection fault originating from the selftest code that exercises iommufd functionality.
At a high level the problem is a timing/race issue: a code path that reconfigures an access object was setting an internal pointer to NULL while another context could still be holding or trying to take a read lock on that pointer. The race can lead to the kernel dereferencing a NULL or otherwise invalid pointer inside the selftest ioctl handler, which produces a kernel oops and a loss of availability on the affected host.
Key, high‑level facts every administrator should know:

• The vulnerability is tracked as CVE‑2024‑26785 and is classified as a local, low‑complexity denial‑of‑service (DoS).
• The failure mode observed was a protection fault / KASAN null-pointer dereference which results in kernel crash behavior (panic / oops) and therefore an availability impact.
• The root cause is an improper locking / access sanity check during the iommufd access-change flow: an internal pointer (access->ioas) may be set to NULL while a concurrent reader still assumes it is valid.
• Upstream kernel maintainers committed a small, focused fix that performs the same sanity checks other iommufd access paths already use, preventing the race window.

This article distills the technical details, operational impact, detection clues, and practical mitigation and patching steps you can take today.

---

Why this matters: iommufd, IOVA and production risk​

What is iommufd and why administrators care​

iommufd provides a standardized userspace API to manage device DMA mappings (IOVAs) and userspace-managed I/O page tables. It is intended for advanced device and virtualization use cases (for example: VFIO and other subsystems migrating page-table control into userspace). Because iommufd touches DMA and kernel-to-userspace mappings, bugs in this area can cause severe failures (kernel oops, crashes, or memory corruption) if they occur in production exposure points.
Two operational facts reduce the immediate blast radius in most deployments:

• Much of the suspicious code that Syzkaller exercised is part of the iommufd selftest support. The selftest paths are gated by a kernel configuration option typically intended for kernel testing. In many distribution builds the test support is not enabled in production kernels.
• Exploitation is local: an attacker needs some level of access on the host to make the ioctl calls that trigger the condition (unlike remote network attacks).

However, those mitigations are not universal. Some organizations run test-ready kernels in cloud or CI fleets, or build kernels with debugging/test options enabled. Additionally, platform and distribution variants vary. For that reason this issue is treated by distributors and vendors as a security bug and patched in stable kernels and vendor packages.

The observable failure mode​

When the race triggers, the kernel log shows a protection fault / KASAN message and a stack trace pointing to the iommufd selftest call paths. The practical result is:

• Immediate kernel oops or panic on the affected host; services running on the node become unavailable until reboot.
• If the attacker can call the offending ioctl repeatedly, the node can be forced into repeated crashes (a sustained DoS).

Because the vulnerability is not an information leak or privilege escalation, its main consequence is availability disruption — but as is often true for kernel crashes, the operational fallout can be substantial.

---

Technical analysis: what went wrong, exactly​

The offending pattern​

The bug centers on the interaction between:

• the function that changes an access object's IOAS mapping (iommufd_access_change_ioas), and
• readers/workers that concurrently call access operations (e.g., iommufd_test_access_rw, iommufd_test_access_pin_pages, etc).

In the problematic sequence, iommufd_access_change_ioas performed an update that temporarily left the access object's ioas pointer NULL while it was performing internal reallocation or list operations. A concurrent path that expected the pointer to be valid would take a read lock (down_read) and then attempt to use that pointer. If the pointer was NULL when used, the kernel dereference produced a protection fault or KASAN-detected null-pointer deref.

The minimal fix​

The patch applied upstream is intentionally small and defensive: before using an access object's ioas pointer, the code verifies that it is non-NULL and behaves the same way established, previously fixed routines do (they perform a sanity check on access->ioas before grabbing locks or dereferencing it). Concretely, the change ensures the state transitions for the pointer are observable and safe to concurrent readers — eliminating the race window that allowed a NULL dereference.
This is a classic improper locking / use-after-state-change pattern: the solution is to either hold the protecting lock across the transition or make the transient state non-observable to concurrent readers. The kernel patch opts for the defensive sanity check used in peer functions so the behavior is predictable.

---

Scope: who is affected​

Determining impact in your environment requires two checks.

• Is your kernel build exposing iommufd?
• Many distribution kernels include the iommufd module or built-in support; the subsystem itself is relatively new and generally compiled in for modern kernels that support IOMMU userspace APIs.
• Is CONFIG_IOMMUFD_TEST enabled in your kernel?
• The specific crashing code exercised by Syzkaller lives in the iommufd selftest code path. The selftest support is controlled by the CONFIG_IOMMUFD_TEST kernel config option. That option is explicitly a test-only feature: kernel documentation and config helpers warn that it should not be enabled in production and that it depends on debug/fault-injection/test infrastructure.
• If your kernel is a standard, production distro build, the test support is often disabled. In that case, the common exploit path is not present and the risk is much lower.
• However, several distributions and vendor kernels have still packaged updated kernels to close the issue, because differences in build flags or backported patches can make the test paths available or because vendors prefer to treat any kernel selftest issues that can cause crashes as CVEs to be remediated.

Concrete vulnerable scenarios:

• Developer/test kernels, CI runners, or custom builds with debugging/test options enabled.
• Any kernel build where the iommufd module and selftest code are compiled and where unprivileged processes can reach the ioctl interface because of loose device/node permissions.
• Systems running older kernel trees that do not contain the upstream safety check.

---

Verified remediation and distribution response​

Upstream kernel maintainers accepted a small, focused change that performs the same access->ioas sanity checks used elsewhere. Distributors incorporated that change into stable kernels and issued advisories. Vendor responses included security errata and updated kernel packages; stable kernel releases and distribution kernel updates shipped patches that remove the race condition.
Administrators should rely on their distribution’s kernel security advisories for exact package names and fixed versions. In general:

• Update to the latest stable kernel provided by your Linux distribution that includes the iommufd patch.
• If you maintain your own kernel builds, pull the upstream stable commit that implements the fix and rebuild, or upgrade to a kernel release series where the fix is present.

If you cannot update immediately, consider the short-term mitigations below.

---

Detection and incident response: how to tell if you were hit​

Signs that the vulnerability was triggered on a system include:

• Kernel oops logs mentioning iommufd_test_syz_conv_iova, iommufd_test_access_rw or stack traces rooted in drivers/iommu/iommufd/selftest.c.
• KASAN reports or kernel warnings that reference a null-ptr-deref or a general protection fault around the iommufd paths.
• Repeated panics or oopses during attempts by local processes to issue ioctl calls against the iommufd device.

Practical steps for detection:

• Inspect dmesg and /var/log/kern.log for KASAN or oops lines that mention iommufd or iommufd_test*.
• Check kernel config for the running kernel: grep for CONFIG_IOMMUFD_TEST in /boot/config-$(uname -r) (or your distribution-equivalent). If it’s not set, the selftest paths are likely not present.
• Verify device presence and permissions: confirm whether /dev/iommu or the iommufd character device exists and who can access it. Loose permissions (e.g., world-writable or world-readable device nodes) increase risk if the selftest is present.

If you find evidence of exploitation (kernel oopses or crashes tied to these code paths), follow your standard incident response for host unavailability: isolate the node, preserve logs (dmesg, journalctl, kmsg), capture the kernel panic/oops trace, and plan for a kernel upgrade plus full rollback or forensic analysis as needed.

---

Practical mitigation and remediation steps​

If you manage Linux systems, follow this prioritized checklist.

• Patch and reboot (preferred, high confidence)
• Update to the latest vendor-provided kernel package that includes the iommufd fix.
• Reboot the host to activate the new kernel.
• Verify by checking kernel version and ensuring /boot/config indicates the patched build or that the vendor advisory is applied.
• If you cannot patch immediately, apply temporary mitigations
• Ensure the iommufd device nodes are not accessible to untrusted users. File-permission hardening can reduce risk:
• Change ownership to root:root and mode to 0600 or 0660 and confine access to a small, trusted group.
• Remove or blacklist the iommufd kernel module if it is modular and not required in your environment. (Be careful: removing modules that are in use can cause other failures.)
• Disable test features in custom kernel builds: rebuild without CONFIG_IOMMUFD_TEST if you control kernel compile options.
• For environments running test or debug kernels (CI runners, developer machines)
• Treat these hosts as high risk: update their kernels promptly and consider reconfiguring test runners so they do not run untrusted workloads under these configurations.
• Backport or cherry-pick
• If you maintain long‑lived kernel trees, identify the stable patch commit that implements the fix and backport it into your build branch. When performing a cherry-pick, ensure you resolve any dependency changes and run your regression/test suite.
• Monitor logs and alarms
• Add a log-check rule to detect KASAN/null-pointer deref traces referencing iommufd*test** and alert on any occurrences.

---

Recommended checks for administrators and developers​

• Check whether CONFIG_IOMMUFD_TEST is enabled in your kernels and, if enabled, determine whether exposing the test IOCTLs to unprivileged users is possible in your environment.
• Audit file permissions on iommufd device nodes and restrict access to administrators or dedicated device-management groups.
• If you use container or VM orchestration systems that allow nested access to host devices, confirm that no untrusted container or guest can access the iommufd device.
• For build teams: avoid shipping debug/test kernels into production fleets. Use separate images for CI and test workloads.

---

Risk assessment and operational impact​

CVE‑2024‑26785 is a targeted availability vulnerability: it does not appear to leak kernel memory or allow privilege escalation, but it does allow local actors to crash the host under certain kernel builds. For most production deployments using vendor-distributed kernels with test features disabled, the real-world risk is low. For CI systems, development workstations, or custom kernel builds that enable test hooks, the risk is meaningful and remediation should be prioritized.
Operational impact scenarios:

• Cloud or bare-metal hosts used for infrastructure services can suffer unplanned reboots and service outages if the crash is triggered.
• High-availability clusters reliant on kernel stability could experience failovers or cascading service degradation when nodes crash.
• Automated test farms with fuzzing or workload runners may be a vector for accidental triggering; a malicious actor with local access (for instance, via a compromised CI job) could intentionally force repeated crashes.

Administrators should therefore treat this as an availability‑risk patch: patching is low-effort relative to the impact of repeated host crashes.

---

Developer notes: backporting and code hygiene​

For kernel maintainers and engineers who need to backport the fix, the correction is narrowly scoped to ensure safety in concurrent access-change flows. When backporting:

• Identify the exact commit(s) from the stable kernel line that implement the sanity checks and apply them to the backport branch.
• Run the kernel test suite and any iommufd selftest harness (if used internally) to validate there are no regressions.
• Confirm that the backported code follows the same locking and reference-counting semantics as the target release branch to avoid introducing deadlocks or livelocks.

Two important code-quality lessons that this CVE highlights:

• Test infrastructures can reveal real concurrency bugs — but test-only code paths should be carefully segregated from production interfaces to reduce accidental exposure.
• Defensive sanity checks around pointer state transitions are cheap and effective: if a pointer can become NULL in a transition, verify it under the appropriate lock before use.

---

Quick “what to do now” checklist​

• Determine whether your systems have iommufd and whether CONFIG_IOMMUFD_TEST is enabled.
• Prioritize updating kernels on developer, CI, and any systems with test/debug configurations.
• For production systems, consult your vendor’s kernel security advisory and apply the recommended kernel package update.
• If immediate patching is impossible, restrict device-node access or unload the iommufd module where feasible.
• Add a log monitor to detect KASAN/oops traces referencing iommufd_test* and alert the security/ops team.

---

Conclusion​

CVE‑2024‑26785 is a concise reminder of how subtle race and state‑transition bugs in kernel subsystems can produce outsized availability problems. The vulnerability itself was fixed with a small, well-scoped defensive change upstream, and vendors have incorporated the fix into stable kernel packages. While most production distributions do not enable the iommufd test infrastructure by default — which reduces immediate exposure — organizations with custom kernels, developer fleets, or CI systems must act quickly to update or mitigate.
Treat this as an operational patch: confirm whether the test paths are present in your kernels, apply vendor updates or upstream fixes promptly, and restrict access to potentially dangerous device interfaces until your fleet is patched. Doing so removes an easy local avenue for an attacker (or a misbehaving local process) to take nodes offline and preserves platform availability.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center