GPU VulnDB

Database/Kernel, userspace & hypervisor

Linux kernel mm/mempolicy: NULL VMA deref in migrate_pages() crashes the host kernel

CVSS 5.5CVE-2024-56611Kernel, userspace & hypervisorcurated

Impact

do_migrate_pages() assumed every address space contains at least one VMA, so find_vma() could return NULL and be dereferenced, producing a general protection fault in kernel context. The result is a host kernel oops reached through the ordinary migrate_pages(2) syscall - no special privilege beyond being able to call it on a task's own address space. On a GPU node this is a whole-host availability problem: the kernel panic takes down every tenant's pods on that node together with the long-running training or inference jobs pinned to its accelerators, and NUMA page migration is exactly the kind of call that numactl-style tuning and NUMA-aware job launchers make routinely, so the path is live on fleets that bind workloads to sockets. The record describes only a crash; there is no indication of information disclosure or privilege escalation.

Who can reach it

Local user on the host or inside a container that is not blocking migrate_pages(2) via seccomp. No authentication beyond local shell access, and no CAP_SYS_NICE is needed to migrate one's own pages. Not reachable from the network or from a GPU device interface.

What to do

Take the stable kernel fix (commits listed in the record; merged for 6.13 and backported to the affected stable branches) from your distribution and reboot each node onto the patched kernel - drain the node first, since this is a core mm change with no live-patch or runtime toggle. As an interim mitigation, block migrate_pages(2) in container seccomp profiles where NUMA migration is not required by the workload.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.