Cloudanix VulnDB

CVE-2025-40293

None

CVSS

—

EPSS

0.2%

Published

Dec 8, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel can cause the whole system to crash when certain memory-tracking features are used with unusual settings.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Division-by-zero in iommufd dirty-tracking bitmap index calculation when pgshift equals 63, caused by 64-bit multiplication overflow to zero before the division.

Why it matters to the business

Kernel panic or denial-of-service on Linux systems performing IOMMU dirty-page tracking with extreme page-shift values, disrupting virtualization, device passthrough, and container workloads.

How an attack unfolds

An attacker with local access crafts IOMMU operations or VFIO/iommufd user-space calls that force pgshift=63 during bitmap sizing, triggering the overflow path and immediate divide-by-zero fault in kernel context.

How to fix it

Upgrade the Linux kernel to the commit 07105e61882ff4a7d58db63cc5f9e90c6c60506c or later stable releases that reorganize the index calculation to divide by shift and avoid overflow.

How to confirm the fix worked

Verify the running kernel contains commit 07105e61882ff4a7d58db63cc5f9e90c6c60506c; attempt to reproduce the pgshift=63 bitmap allocation path in a test environment and confirm absence of divide-by-zero fault.

Typical attack path

  1. Obtain local unprivileged or container access on a vulnerable Linux kernel
  2. Invoke iommufd or VFIO APIs that allocate dirty-tracking bitmaps with pgshift set to 63
  3. Trigger the BITS_PER_TYPE multiplication that overflows to zero
  4. Execute the subsequent division, causing kernel oops and system crash or reboot

How to detect it

Search kernel logs (dmesg, journalctl) and crash dumps for divide-by-zero faults or oops originating from iommufd dirty-tracking bitmap code; correlate with processes performing VFIO or IOMMU operations.

  • divide error: 0000 [#1] SMP
  • RIP: 0010:iommufd.*dirty
  • BUG: unable to handle kernel paging request at
  • kernel BUG at drivers/iommu/iommufd

What your security team should do

  • Patch all affected kernels to the fixed commit within the next maintenance window
  • Prioritize systems running virtualization or device-assignment workloads that use iommufd
  • Monitor kernel logs for unexpected oops or divide-by-zero faults until patching is complete

The record

In the Linux kernel, the following vulnerability has been resolved: iommufd: Don't overflow during division for dirty tracking If pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflow to 0 and this triggers divide by 0. In this case the index should just be 0, so reorganize things to divide by shift and avoid hitting any overflows.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 6.1.0 6.1.159
Mageia:9 kernel 0 6.6.120-1.mga9
Mageia:9 kernel-linus 0 6.6.120-1.mga9
Mageia:9 kmod-virtualbox 0 7.1.14-14.mga9
Mageia:9 kmod-xtables-addons 0 3.24-88.mga9
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-azure 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.9.1.160000.2.6
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.9.1

Related vulnerabilities