CVE-2024-56742

What it actually does

The flaw is a missing error path in mlx5vf_add_migration_pages that leaks allocated pages when insertion into the SG table fails; the pages are never released because mlx5vf_free_data_buffer only frees pages that were successfully added.

Why it matters to the business

Repeated triggering on systems using VFIO with mlx5 devices can slowly exhaust kernel memory, leading to degraded performance or eventual denial of service. The issue affects a wide range of older Ubuntu kernels but carries low urgency given the low EPSS score and absence from KEV.

How an attack unfolds

An attacker with local access on an affected kernel triggers the mlx5 migration page-allocation path under conditions that cause the SG-table insertion to fail, leaving the allocated pages unreferenced and accumulating over multiple invocations until memory pressure becomes noticeable.

How to fix it

Upgrade each affected package to the listed fixed version: linux 3.13.0-132.181 (14.04), linux-aws 4.4.0-1002.2 (14.04), linux-azure 4.15.0-1023.24~14.04.1 (14.04), linux-lts-xenial 4.4.0-79.100~14.04.1 (14.04), linux 4.4.0-79.100 (16.04), linux-aws 4.4.0-1018.27 (16.04), linux-azure 4.11.0-1009.9 (16.04), linux-gcp 4.10.0-1004.4 (16.04), linux-gke 4.4.0-1014.14 (16.04), linux-hwe 4.10.0-32.36~16.04.1 (16.04), linux-kvm 4.4.0-1004.9 (16.04), linux-oem 4.13.0-1008.9 (16.04), linux-raspi2 4.4.0-1057.64 (16.04), linux-snapdragon 4.4.0-1059.63 (16.04), linux-aws-hwe 4.15.0-1030.31~16.04.1 (16.04), linux-oracle 4.15.0-1007.9~16.04.1 (16.04), linux 4.13.0-16.19 (18.04). Reboot after installation.

How to confirm the fix worked

Confirm the running kernel version matches or exceeds the fixed package version for the installed Ubuntu release; additionally run memory-leak detection tools or monitor /proc/meminfo over time while exercising VFIO mlx5 migration workloads.

Typical attack path

1. Obtain local execution on a system running an affected Ubuntu linux package with mlx5 VFIO enabled
2. Exercise the migration code path that calls mlx5vf_add_migration_pages
3. Force repeated allocation failures so that pages are not added to the SG table
4. Allow the leak to accumulate until memory pressure impacts the system

How to detect it

Review kernel logs for allocation failures inside mlx5vf_add_migration_pages, correlate with rising slab or page-cache usage that cannot be attributed to running workloads, and inspect dmesg or /var/log/syslog for repeated vfio/mlx5 migration errors.

What your security team should do

• Prioritize patching of any internet-facing or multi-tenant systems that expose VFIO mlx5 devices
• Apply the exact fixed kernel packages listed for each Ubuntu release
• Schedule reboots within the change window after package installation
• Review systems for continued memory-growth anomalies after patching