Linux Kernel up to 6.12.102/6.18.41/7.1.5/7.2-rc3 xe xe_bo_init_locked use after free

CVSS Meta Temp Score CVSS is a standardized scoring system to determine possibilities of attacks. The Temp Score considers temporal factors like disclosure, exploit and countermeasures. The unique Meta Score calculates the average score of different sources to provide a normalized scoring system.	Current Exploit Price (≈) Our analysts are monitoring exploit markets and are in contact with vulnerability brokers. The range indicates the observed or calculated exploit price to be seen on exploit markets. A good indicator to understand the monetary effort required for and the popularity of an attack.	CTI Interest Score Our Cyber Threat Intelligence team is monitoring different web sites, mailing lists, exploit markets and social media networks. The CTI Interest Score identifies the interest of attackers and the security community for this specific vulnerability in real-time. A high score indicates an elevated risk to be targeted for this vulnerability.
8.4	$0-$5k	0.00-

Summaryinfo

A vulnerability identified as very critical has been detected in Linux Kernel up to 6.12.102/6.18.41/7.1.5/7.2-rc3. Affected by this issue is the function xe_bo_init_locked of the component xe. The manipulation leads to use after free. This vulnerability is documented as CVE-2026-68266. The attack needs to be performed locally. There is not any exploit available.

Detailsinfo

A vulnerability, which was classified as very critical, has been found in Linux Kernel up to 6.12.102/6.18.41/7.1.5/7.2-rc3. This issue affects the function xe_bo_init_locked of the component xe. The manipulation with an unknown input leads to a use after free vulnerability. Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: drm/xe: Hold a dma-buf reference for imported BOs An imported dma-buf BO is created as a ttm_bo_type_sg BO whose reservation object is the exporter's dma_buf->resv. The importer, however, only takes a dma-buf reference after a successful dma_buf_dynamic_attach(). Until then nothing keeps the exporter alive, so if the exporter is freed while the BO still references its resv, a later access to that resv is a use-after-free: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b9c Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:mutex_can_spin_on_owner+0x3f/0xc0 This can be reached on two paths: - dma_buf_dynamic_attach() fails, or - ttm_bo_init_reserved() fails during BO creation. In both cases the BO already has bo->base.resv pointing at the exporter resv, and sg BOs are always torn down via ttm_bo_delayed_delete(), which locks bo->base.resv asynchronously - potentially after the exporter has been freed. Take the dma-buf reference in xe_bo_init_locked(), before ttm_bo_init_reserved(), so it also covers a creation failure there, and release it in xe_ttm_bo_destroy(). The reference is held for the whole BO lifetime, keeping the shared resv alive on every path. v2: - Reworked the fix to avoid creating the imported sg BO before dma_buf_dynamic_attach() succeeds. - Attach with importer_priv == NULL and make invalidate_mappings ignore incomplete imports. v3: - Dropped the xe-side reordering approach since importer_priv must be valid when dma_buf_dynamic_attach() publishes the attachment. - Per Christian's suggestion on the v1 thread, keyed the check on import_attach rather than removing the sg guard entirely. - Fixes both xe and amdgpu in a single TTM patch. v4: - Moved import_attach check to after dma_resv_copy_fences() so fences are copied before returning for successful imports (Thomas). - Removed exporter-alive claim from commit message (Thomas). v5: - Add drm/xe patch to keep imported sg BOs off the LRU before attach succeeds; the TTM fix alone is not sufficient for xe if the BO is already LRU-visible. (Thomas) v4 patch: https://patchwork.freedesktop.org/patch/736663/?series=169129&rev=2 - Patch 1 (drm/ttm) carries Christian's Reviewed-by from v4. v6: - Reworked the fix based on Thomas' suggestion. Instead of the TTM resv individualization (v1-v5) plus the xe off-LRU/placement handling (v5), just hold a dma-buf reference for the imported BO lifetime so the shared resv can never be freed while the BO still references it. Single xe patch, no TTM change. (Thomas) - Take the reference in xe_bo_init_locked() before ttm_bo_init_reserved() so a TTM creation failure is covered too (Thomas). - Dropped the v5 series (drm/ttm + drm/xe off-LRU); the off-LRU approach also regressed in CI BAT via ttm_bo_pipeline_gutting() creating a ghost BO that outlived the exporter. Link to v5: https://patchwork.freedesktop.org/series/169984/ v7: - Move changelog above --- so it stays in the commit message. - Reorder changelog entries oldest-to-newest. (Thomas) (cherry picked from commit 3516f3fae6be35642f8f06f8a218da6425c0306a)

The advisory is shared at git.kernel.org. The identification of this vulnerability is CVE-2026-68266 since 07/30/2026. The exploitation is known to be easy. An attack has to be approached locally. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 08/10/2026).

Upgrading to version 6.12.103, 6.18.42, 7.1.6 or 7.2-rc4 eliminates this vulnerability. Applying the patch c22d65d62b3318e237c0e5b1177d90ab83d9fe06/c1954c66662de477a8f4309335b775f7b07bd28b/ba8c4cbb31c6f81fa5b12d6e28f1f706040aff48/62775525a27c3b0d56382e08ba81ee2d322058b6 is able to eliminate this problem.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.12.102
• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.18.17
• 6.18.18
• 6.18.19
• 6.18.20
• 6.18.21
• 6.18.22
• 6.18.23
• 6.18.24
• 6.18.25
• 6.18.26
• 6.18.27
• 6.18.28
• 6.18.29
• 6.18.30
• 6.18.31
• 6.18.32
• 6.18.33
• 6.18.34
• 6.18.35
• 6.18.36
• 6.18.37
• 6.18.38
• 6.18.39
• 6.18.40
• 6.18.41
• 7.1.0
• 7.1.1
• 7.1.2
• 7.1.3
• 7.1.4
• 7.1.5
• 7.2-rc1
• 7.2-rc2
• 7.2-rc3

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv3info

VulDB Meta Base Score: 8.8
VulDB Meta Temp Score: 8.4

VulDB Base Score: 8.8
VulDB Temp Score: 8.4
VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv2info

AV	AC	Au	C	I	A
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳
💳	💳	💳	💳	💳	💳

Vector	Complexity	Authentication	Confidentiality	Integrity	Availability
Unlock	Unlock	Unlock	Unlock	Unlock	Unlock
Unlock	Unlock	Unlock	Unlock	Unlock	Unlock
Unlock	Unlock	Unlock	Unlock	Unlock	Unlock

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍

Exploitinginfo

Class: Use after free
CWE: CWE-416 / CWE-119
CAPEC: 🔒
ATT&CK: 🔒

Physical: Partially
Local: Yes
Remote: No

Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒

0-Day	Unlock	Unlock	Unlock	Unlock
Today	Unlock	Unlock	Unlock	Unlock

Threat Intelligenceinfo

Interest: 🔍
Active Actors: 🔍
Active APT Groups: 🔍

Countermeasuresinfo

Recommended: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: Kernel 6.12.103/6.18.42/7.1.6/7.2-rc4
Patch: c22d65d62b3318e237c0e5b1177d90ab83d9fe06/c1954c66662de477a8f4309335b775f7b07bd28b/ba8c4cbb31c6f81fa5b12d6e28f1f706040aff48/62775525a27c3b0d56382e08ba81ee2d322058b6

Timelineinfo

07/30/2026 CVE reserved
08/10/2026 +11 days Advisory disclosed
08/10/2026 +0 days VulDB entry created
08/10/2026 +0 days VulDB entry last update

Sourcesinfo

Vendor: kernel.org

Advisory: git.kernel.org
Status: Confirmed

CVE: CVE-2026-68266 (🔒)
GCVE (CVE): GCVE-0-2026-68266
GCVE (VulDB): GCVE-100-387641

Entryinfo

Created: 08/10/2026 17:04
Changes: 08/10/2026 17:04 (59)
Complete: 🔍
Cache ID: 216::103

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion

Want to know what is going to be exploited?

We predict KEV entries!