CVE-2026-89449

What it actually does

In the Linux IOMMU mock-device path, a failed device_add() after a successful iommu_fwspec_init() leaks the outer dev_iommu heap object because the error path frees only the nested fwspec. Each failure permanently consumes a small kernel slab allocation (on the order of ~192 bytes). Repeated triggering grows unreclaimable kernel memory and can lead to allocator failures or host denial of service.

Why it matters to the business

The operational risk is availability: leaked kernel memory can cause allocation failures, instability, or reboot. The issue is not in CISA KEV, has no reported exploit maturity or ransomware use, and was disclosed about 30 days ago, so there is no mandated emergency deadline. Practical exposure is mainly kernels built with IOMMUFD mock/selftest interfaces enabled (debug, CI, and fuzzing images more than typical locked-down production). Where that test surface is present, a local user or compromised process could apply memory pressure; elsewhere business impact is low.

How an attack unfolds

An attacker with local access to a kernel that exposes IOMMUFD test/mock ioctls opens the iommufd device and issues mock domain or mock device creation commands. The kernel path initializes firmware-spec state (allocating both the fwspec and the parent dev_iommu object) and then calls device_add(). When registration fails, only fwspec is freed, leaking the parent object. Repeating the failing add accumulates leaked slab memory until the host hits memory pressure, allocation errors, or a crash. No unauthenticated remote vector is described; reachability depends on the test ioctl interface being compiled in and usable.

How to fix it

Apply the upstream Linux kernel fix that, on the device_add() failure path in iommu_mock_device_add(), calls dev_iommu_free(dev) instead of iommu_fwspec_free(dev), releasing both fwspec and the outer dev_iommu object and clearing dev->iommu. Install the distribution kernel package that contains this commit as soon as it is available. Until then, build and deploy production kernels without IOMMUFD test/mock options (for example CONFIG_IOMMUFD_TEST), restrict who can open iommufd devices, and do not expose those test ioctls in containers or multi-tenant images. There is no setting that stops the leak if the mock add path remains reachable.

How to confirm the fix worked

Confirm the running kernel changelog or source uses dev_iommu_free on the iommu_mock_device_add device_add failure path. After patching, with kmemleak enabled, force mock device-add failure and verify no new unreferenced objects whose backtrace includes dev_iommu_get or iommu_fwspec_init from that path. On production hosts, verify IOMMUFD test config is disabled (for example /boot/config-$(uname -r) or /proc/config.gz) and that iommufd test ioctls are unavailable. Track vendor advisories and installed kernel package versions until a fixed build is confirmed.

Typical attack path

1. Find a Linux host whose kernel includes IOMMUFD mock/selftest support and an accessible iommufd device
2. Obtain local access sufficient to open that device and issue test ioctls
3. Invoke mock device or mock domain creation so iommu_mock_device_add runs iommu_fwspec_init then fails in device_add
4. Repeat the failing add to leak successive dev_iommu allocations
5. Continue until kernel memory pressure causes service failure, OOM behavior, or host reboot

How to detect it

This issue leaves leaked kernel slab objects, not malware files or network callbacks. Search kernel logs, kmemleak dumps, and crash/vmcore output for unreferenced objects whose backtrace includes dev_iommu_get, iommu_fwspec_init, iommu_mock_device_add, or iommufd selftest frames, especially allocations around 192 bytes. Correlate with local ioctl activity on iommufd file descriptors and with processes using IOMMUFD test commands. Monitor kmalloc caches in that size class for monotonic unreclaimable growth during iommufd test use. Finding test config enabled on a production kernel indicates exposure, not proof of past exploitation. There is no reliable network indicator of compromise.

• iommu_mock_device_add
• iommu_fwspec_init
• dev_iommu_get
• iommufd_test_mock_domain
• mock_dev_create
• iommufd_test+
• drivers/iommu/iommu.c
• drivers/iommu/iommufd/selftest.c
• BUG: memory leak
• unreferenced object

What your security team should do

• Inventory Linux images for IOMMUFD mock/selftest support and treat those hosts as the actual exposure set
• Deploy kernel updates that include the iommu_mock_device_add leak fix as they ship from your vendor
• Disable IOMMUFD test/mock build options on production, multi-tenant, and customer-facing images
• Restrict open and ioctl access to iommufd character devices to trusted administrators only
• Watch kmemleak and slab growth for iommu-related unreclaimed objects until fleets are patched
• Do not treat this as a KEV-style emergency, but patch debug/CI/fuzz kernels where the path is intentionally enabled