CVE-2022-48675

What it actually does

The flaw is a nested deadlock in the Linux kernel IB/core ODP path: calling mmput() while holding umem_odp->umem_mutex can trigger exit_mmap() -> __mmu_notifier_release() -> mlx5_ib_invalidate_range() on the same task, which attempts to re-acquire the same mutex.

Why it matters to the business

Systems using InfiniBand or RDMA with on-demand paging may experience kernel deadlocks leading to system hangs, loss of availability, and potential denial of service; the issue affects a wide range of Linux kernel deployments though exploitation is not known to be occurring in the wild.

How an attack unfolds

An attacker with local access triggers page-fault handling in the mlx5_ib driver under the ODP flow, causing the workqueue path to invoke ib_umem_odp_map_dma_and_lock() and subsequently mmput(), which deadlocks when the notifier path attempts to acquire the already-held mutex.

How to fix it

Update the Linux kernel to a version containing commit e8de6cb5755eae7b793d8c00c8696c8667d44a7f, which replaces mmput() with mmput_async() in the ODP flow; apply the fix via distribution kernel packages that backport this commit.

How to confirm the fix worked

Verify the running kernel contains commit e8de6cb5755eae7b793d8c00c8696c8667d44a7f or an equivalent backport; review dmesg or kernel logs for absence of the deadlock call trace involving mlx5_ib_invalidate_range and mmput; test ODP workloads to confirm no deadlock occurs.

Typical attack path

1. Obtain local user access on a Linux system with mlx5_ib and ODP enabled
2. Trigger RDMA page-fault operations that reach pagefault_mr and ib_umem_odp_map_dma_and_lock
3. Cause mmput() to be called while umem_mutex is held
4. Induce the exit_mmap notifier path to attempt re-acquisition of the same mutex from the same task
5. Resulting deadlock renders the kernel unresponsive

How to detect it

Search kernel logs and crash dumps for the deadlock signature containing mlx5_ib_eqe_pf_action, ib_umem_odp_map_dma_and_lock, mmput, and __mmu_notifier_release; no public exploitation artifacts are known.

What your security team should do

• Prioritize kernel updates containing the referenced commit on all systems using mlx5_ib or InfiniBand ODP
• Monitor for distribution advisories that include this fix and schedule patching within normal maintenance windows given low EPSS and no known exploitation
• Consider disabling ODP if the feature is not required until patches can be applied