CVE-2025-40293: Linux kernel iommufd dirty tracking divide-by-zero fix

A recently assigned CVE identifier, CVE-2025-40293, closes a subtle arithmetic bug in the Linux kernel’s iommufd dirty-tracking code that could produce a divide-by-zero kernel fault when unusual page-size shift values are used; upstream maintainers reorganized the arithmetic to avoid overflow and ensure the dirty-bit index calculation yields zero for the extreme case where pgshift == 63.

Background / Overview​

IOMMUFD (iommufd) is the kernel subsystem and user API that lets userspace manage I/O address spaces and hardware page tables for I/O memory management, including dirty tracking support that can query which IOVAs (I/O virtual addresses) have been written. Dirty tracking is exposed through ioctls such as IOMMU_HWPT_GET_DIRTY_BITMAP and IOMMU_HWPT_SET_DIRTY_TRACKING and is intended for use by virtualisation and device-migration stacks. The kernel documentation defines the bitmap interfaces and the semantics of checking "dirty" IOVA ranges. The CVE description summarizes a corner-case arithmetic failure: if an unusually large page-shift — specifically pgshift == 63 — is present, the expression BITS_PER_TYPE(bitmap->bitmap) pgsize can overflow to zero. That wrapped zero value later participates in a division, triggering a divide-by-zero condition. The kernel fix rearranges the math so the division is done by a shift (which avoids the overflow path) and explicitly ensures the index is zero in the degenerate case rather than allowing an arithmetic wrap to create an invalid divisor.

---

What went wrong: a closer technical look​

At the heart of the bug is a classic mixed-width/multiplication overflow followed by a division that can become divide-by-zero when intermediate multiplication wraps. The simplified pattern is:

• Compute a per-word bit-count times page-size: BITS_PER_TYPE(bitmap->bitmap) pgsize.
• Use the product as a divisor or in an index calculation.
• If the product overflows to zero (possible if pgshift is extreme), the later division attempts to divide by zero, causing a kernel exception.

With pgshift == 63 the multiplication (on typical kernel integer types) can overflow and wrap to zero; the correct logical result for the index in that configuration should be 0, but the arithmetic ordering in the vulnerable code allowed the overflow path to produce a zero divisor and a subsequent crash. Upstream maintainers therefore reorganized the arithmetic to divide by the shift amount first (or use shifts in a wider type), guaranteeing the index calculation cannot encounter a zero divisor. This preserves intended semantics while removing the overflow/divide-by-zero path. This class of bug—mixed-width arithmetic and wrapping during shifts or multiplications—appears frequently in low-level kernel code that manipulates bitmaps, page sizes, and hardware page-table metadata. Kernel reviewers often prefer surgical arithmetic reorganizations or explicit type promotions (casts to a wider integer type) to remove the corner-case overflow while preserving original semantics for normal inputs.

---

Why this matters: impact, attack surface, and realistic threat model​

• Primary impact: Availability (Denial-of-Service). An attempted divide-by-zero in the kernel context typically triggers a kernel warning, oops, or panic — i.e., host instability or a crash. The practical outcome is a local DoS rather than a straightforward remote code execution or confidentiality breach.
• Attack vector: Local / host-adjacent. Exploiting this condition requires the ability to interact with iommufd functionality — that typically means a local process or privileged userspace code that can create or manipulate IOMMUFD HW pagetables, set dirty tracking, or call the relevant ioctls. In virtualized or multi-tenant environments, untrusted guest or container components that have access to the relevant device interfaces raise the practical risk.
• Exploitability: Low to moderate in the general population. The degenerate pgshift==63 case is unusual in practice; typical platforms use conventional page-size shifts. That said, malformed or crafted userspace inputs and particular hardware or driver configurations could surface the condition. Public vulnerability aggregators and upstream trackers list the CVE as a correctness/overflow fix rather than an active exploitation vector; as of the CVE write-up there was no public proof-of‑concept or active in‑the‑wild exploit tied to this specific CVE.
• Long-tail risk: Vendor kernels and embedded devices. As with many kernel fixes, the greatest operational exposure often lives in vendor forks, OEM Android kernels, and embedded images that are slow to receive upstream backports. Those long-tail kernels can remain vulnerable even after mainstream distributions have applied the fix upstream.

---

Verification and cross-checks​

To validate the published description and the remediation approach, the CVE was cross-checked against authoritative aggregator entries and the kernel project’s published records:

• The National Vulnerability Database (NVD) lists CVE‑2025‑40293 with the same summary describing overflow of BITS_PER_TYPE(bitmap->bitmap) pgsize and the divide-by-zero trigger; the NVD record is the canonical CVE aggregation entry.
• The OSV (Open Source Vulnerabilities) entry mirrors the same text, timestamps the publication around 8 December 2025, and references kernel stable commits that implement the fix. OSV’s record includes the mapping to the upstream git commits.
• Independent trackers such as OpenCVE and distro advisories (for instance SUSE’s CVE page) reproduced the CVE summary and noted that maintainer fixes reorganize the arithmetic to avoid overflow. These corroborations provide independent confirmation of the bug description and remediation path.

When possible, technical claims were cross-referenced with the kernel’s API documentation on iommufd to ensure the contextual description of dirty tracking and its API semantics matches the vulnerable code’s intended behavior. That documentation explains how the kernel walks IOMMU pagetables to return dirty bitmaps and clarifies the page_size/page-granularity semantics relevant to the bug. Caveat: direct viewing of the kernel commit diffs on git.kernel.org can sometimes be blocked by hosting front-ends or rate restrictions for automated fetches. Where that occurred, the OSV and NVD entries reference the commit identifiers and the public kernel tree; independent vulnerability trackers reproduce the same references, which gives reasonable assurance that the upstream fixes are the intended remediation.

---

What the patch does (developer view)​

Upstream maintainers made a small, targeted change: reorganize the index/division arithmetic so that any division is done by a safe value (for example by performing shifts before multiplying or by promoting operands to a sufficiently wide integer) and explicitly treat the extreme pgshift==63 case as an index of zero. This removes the path where the multiplication can overflow to zero and later be used as a divisor.
This kind of micro-fix is intentional and typical for kernel correctness patches: it avoids heavy refactoring of the bitmap routines while removing the exploitable corner case. Similar kernel patches often use explicit type promotion (cast to u64) or reorder operations to ensure the evaluation does not produce undefined or wrap-around results under edge-case inputs.

---

Affected kernels, mapping, and vendor backports​

• Upstream: the fix is recorded in the kernel stable trees and associated commits referenced by CVE aggregators. OSV’s published entry and other trackers point to the stable-branch commit identifiers that implement the fix. Administrators should assume any kernel built from source before the inclusion of the referenced stable commits is vulnerable.
• Distributions: major Linux distributions typically ingest upstream stable fixes and publish package advisories mapping the CVE to fixed kernel package versions. However, exact package names and fixed kernel versions vary across distros; operators must consult their distribution’s security tracker or package changelogs to confirm whether their installed kernel includes the commit. SUSE and other vendor trackers have already recorded the CVE and noted their internal evaluation status.
• Embedded and OEM images: these are the highest residual-risk category. Device vendors and SoC/OEM kernel forks frequently lag upstream merges and backports. Devices built from older vendor kernels or appliances with rarely-updated firmware may remain vulnerable well after the upstream fix is merged. Inventorying such devices is crucial.

---

Remediation and mitigation — practical checklist​

• Inventory and prioritize.
• Run uname -r to enumerate kernel versions across your fleet.
• Identify hosts that bind devices to iommufd or expose IOMMU management interfaces to userspace (virtualization hosts, device passthrough servers, and systems that forward IOMMU control to guest components).
• Confirm the presence of the upstream fix.
• Consult your distribution’s security tracker or kernel package changelogs to map the CVE to a fixed package or kernel release.
• Apply vendor-provided kernel updates and reboot.
• Kernel changes require reboot into the patched image for remediation to take effect.
• If immediate patching is impossible:
• Restrict access to iommufd or device interfaces (drop unprivileged access to /dev/iommufd or use udev to limit device access).
• Remove device passthrough exposing iommufd to untrusted guests or containers.
• Harden virtualization hosts so untrusted guests cannot cause IOMMU manipulations that exercise dirty-tracking code.
• Monitor and detect:
• Watch kernel logs (dmesg, journalctl -k) for divide-by-zero traces, oops messages, or stack traces mentioning iommufd dirty-tracking routines or bitmap indexing.
• If a crash is observed, preserve kernel logs and console output for triage; those traces will be the primary artifacts to map an incident to the upstream commit.

This remediation playbook follows common kernel incident practice: patch + reboot is definitive; access restriction and device exposure reduction are practical compensating controls when immediate patching cannot be done.

---

Detection, forensics, and triage tips​

• Look for kernel oops lines mentioning division by zero or functions associated with iommufd dirty bitmap computations; messages will often show an instruction pointer and a stack backtrace that lists the vulnerable routine.
• Correlate crashes with recent userspace activity that manipulates IOMMUFD objects (for example guest migration workflows, explicit dirty-tracking ioctls, or device binding sequences).
• Preserve a full system capture: kernel logs, running kernel version, and module list (lsmod) — these data points are required to map a crash to a particular upstream commit when dealing with vendor backports or custom kernels.
• On multi-tenant hosts, treat any reproducible crash triggered by an untrusted workload as high priority for isolation and patching because it can be weaponized as a disruption primitive.

---

Risk analysis and prioritization guidance​

• Highest priority: virtualisation hosts, cloud hypervisors, CI runners, or build farms that expose IOMMU features (or allow guest-driven device control). The ability for a guest or untrusted workload to trigger a kernel oops can result in widespread outages or noisy multi-tenant disruption.
• Medium priority: workstations or desktops with unusual IOMMU/dma setups or where developers run device-binding tests (less likely to see pgshift==63 but still worth patching).
• Lower priority: consumer laptops with standard kernels and no user-space exposure to raw IOMMU control — though patching remains recommended as part of normal update maintenance, the practical exploitation surface is smaller.
• Long-tail: embedded appliances and vendor kernels must be tracked separately because they often receive bespoke backports and can remain vulnerable longer. Inventory vendor kernels and plan for coordination with OEM support channels.

---

Development lessons: defensive coding patterns in kernel space​

This CVE is a textbook example of why kernel code that mixes bit-level arithmetic, shifts, and page-size math benefits from:

• Explicit type promotions — perform arithmetic in a wider integer type (u64) before shifting/multiplying to avoid wraparound in narrow intermediate types.
• Operation reordering — divide by shift values when safe to avoid multiplication overflow before division.
• Sanity checks — early return or clamp on degenerate input values (e.g., treat pgshift >= threshold as a special case returning index=0).
• Unit testing with edge-case values — injecting extreme pgshift-like values or fuzzing page-size inputs can catch these corner cases.

Kernel maintainers prefer small, surgical fixes that remove the immediate unsafe behavior without wholesale refactors — the goal is to eliminate the crash vector while minimizing regressions on well-tested code paths. The pattern of inserting explicit casts or reordering shifts is widespread and an effective low-risk remediation strategy.

---

Final recommendations​

• Apply patched kernel packages from your distribution or upstream stable trees as soon as feasible and reboot systems that need this kernel change to take effect.
• Prioritize hosts that expose IOMMU or device binding functionality to untrusted code (virtualization hosts, cloud instances with passthrough, CI runners with device access).
• For environments that cannot patch immediately, restrict or remove access to iommufd interfaces and device passthrough; monitor kernel logs for divide‑by‑zero oops linked to iommufd dirty-tracking routines.
• Track vendor advisories and package changelogs to confirm that your exact kernel package contains the upstream commit referenced in the CVE record.

CVE‑2025‑40293 is an instructive but not exotic kernel correctness bug: the practical risk is an availability incident if the corner case is reached, and the upstream fix is a narrow arithmetic reorganization that is straightforward to backport. Operators who maintain multi-tenant hosts or systems that expose low-level IOMMU functionality should treat this as a standard priority patch — not because it enables immediate remote compromise, but because a stable, reproducible kernel crash in the wrong environment can have outsized operational impact.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center