CVE-2026-90409
UnknownSummary
In the Linux kernel, the drm/panthor driver does not verify that vm_bind mappings of user-exposed BOs avoid the region reserved for kernel BO mappings. This missing check can cause address space conflicts. The fix adds an overlap check and guards against 64-bit range overflow.
Risk Assessment
Overlapping mappings can lead to memory corruption or GPU driver malfunction, potentially enabling privilege escalation or system instability. This affects platforms with Mali GPUs handled by Panthor.
Recommendation
Update the Linux kernel to a version containing the drm/panthor fix. Restrict GPU device access for untrusted users until the update is applied.
Other vulnerabilities in Linux kernel (drm/panthor)
See all- CVE-2026-89826High
In the Linux kernel, panthor_fw_read_build_info() in the drm/panthor driver validates the metadata range using 32-bit addition (hdr.meta_start + hdr.meta_size), which can wrap and let an out-of-bounds range pass. It also reads the "git_sha: " prefix without checking metadata length, and meta_size == 0 can underflow the NULL terminator index.
- CVE-2026-89825High
In the Linux kernel, panthor_init_cs_iface() and panthor_init_csg_iface() in the drm/panthor driver validate firmware control interface offsets using 32-bit arithmetic and the size of host wrapper structures, so the arithmetic can wrap before the bounds check and the checked size does not match the actual mapped firmware control interface.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Add vm_bind region with kbo range overlap check When a VM is created, caller has to specify the range of the address space carve-out set aside for mapping kernel BO's. That means vm_bind mappings of UM-exposed BO's should not intersect with that region, but at the moment we're not checking this. At first, I thought of giving these values to drm_gpuvm_init() through its reserve_{offset, range} arguments, but it turns out that is meant for VM address spans that are not managed through the usual drm_gpuvm split/merge circuit, so storing the end of the user VA range at VM creation time and doing a quick check in the vm_bind ioctl path was the simplest workaround. The new check also makes sure vm_bind range doesn't overflow the size of a 64-bit unsigned integer. That was already being done further down the call stack inside drm_gpuvm_sm_map -> drm_gpuvm_range_valid, but it's best to fail early in the driver before GPUVM functions are invoked so that we won't waste time allocating vm_bind context resources.