Linux kernel DRM: property blob allocations escape cgroup accounting, letting a local user exhaust kernel memory

CVSS 5.5CVE-2026-43287NVIDIA / GPU stackcurated

Impact

DRM_IOCTL_MODE_CREATEPROPBLOB lets userspace allocate arbitrarily sized, kernel-resident property blobs, and the allocation was not charged to the caller's memory cgroup. An unprivileged process with access to a DRM device can therefore grow unbounded kernel memory that no container memory limit applies to, driving the host toward system-wide OOM. On a GPU node that means one tenant pod can OOM-kill the co-tenant training and inference workloads on the same machine despite correctly configured cgroup limits - the usual blast-radius control simply does not see this memory. Exposure depends on who can open a /dev/dri node with modesetting: headless compute nodes that only expose vendor compute devices are less affected than nodes that pass a DRM card through to tenants.

Who can reach it

Local user or container holding an open /dev/dri/cardN with DRM master or render-capable access. No authentication beyond device-file permissions; nothing network-reachable.

What to do

Take the stable kernel update that marks the blob allocation GFP_KERNEL_ACCOUNT, then drain and reboot each node - the change is in the DRM core, so there is no live patch or sysctl to flip. Interim mitigation is to stop exposing modesetting-capable DRM device nodes to tenant pods and rely on the vendor compute devices only.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-43287 https://git.kernel.org/stable/c/26b4309a3ab82a0697751cde52eb336c29c19035

Related entries

All NVIDIA / GPU stack 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.