---
id: CVE-2026-90409
title: |-
  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…
summary: |-
  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…
severity: none
vendor: Linux
product: Linux
affected:
  - >-
    Linux >= 647810ec247641eb5aec8caef818919a4518a0b1 <
    761cf9c63274a5b711c3dc829601723215710d2d
  - >-
    Linux >= 647810ec247641eb5aec8caef818919a4518a0b1 <
    985f5e12f3cdf43030e13c2bbd154913133b5c3f
  - Linux 6.10
published: '2026-09-17'
updated: '2026-09-17'
sourceUpdated: '2026-09-17T17:17:40.800'
source: NVD
sourceUrl: 'https://nvd.nist.gov/vuln/detail/CVE-2026-90409'
references:
  - url: 'https://git.kernel.org/stable/c/761cf9c63274a5b711c3dc829601723215710d2d'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
  - url: 'https://git.kernel.org/stable/c/985f5e12f3cdf43030e13c2bbd154913133b5c3f'
    label: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
tags:
  - nvd
  - cve.org
ingestedAt: '2026-09-17T16:21:47.798Z'
epss: 0.00189
epssPercentile: 0.08812
---

## Overview

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.

## Remediation

Refer to the linked advisories for vendor-supplied fixes and affected version ranges.