Bug 2513146 (CVE-2026-68234) - CVE-2026-68234 kernel: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved
Summary: CVE-2026-68234 kernel: drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_re...
Keywords:
Status: NEW
Alias: CVE-2026-68234
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-10 12:21 UTC by OSIDB Bzimport
Modified: 2026-08-11 10:57 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description OSIDB Bzimport 2026-08-10 12:21:44 UTC
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix bo->pin leaking in amdgpu_bo_create_reserved

amdgpu_bo_create_reserved() only allocates a new BO when
*bo_ptr (struct amdgpu_bo **bo_ptr as input parameter) is
NULL, it simply skips creation when *bo_ptr is non-NULL.
But it unconditionally reserves, pins, gart allocates
and maps the BO afterwards.

When the same non-NULL BO pointer is passed in again,
for example firmware buffers that live in adev and are
re-loaded on every resume / cp_resume / start
under AMDGPU_FW_LOAD_DIRECT, amdgpu_bo_pin() just increases
pin_count unconditionally, however the matching teardown only unpins
once, so pin_count never drops to zero, so TTM is not able
to move, swap or evict a BO, causing BO leaks.

This commit fixes this issue by only pinning the bo
once at creation, and repeated calls no longer
take additional pin references.

(cherry picked from commit 3ddc0ae76202c447b6aec61e907b852bc94671cf)


Note You need to log in before you can comment on or make changes to this bug.