Skip to main content

Linux Kernel CVE-2026-63863

| EUVDEUVD-2026-45547 HIGH
2026-07-19 Linux GHSA-6jp3-p375-g5x4
Information Disclosure Linux
High
Disputed · 8.8 Vendor: Linux
Share

Severity by source

Sources disagree (Low–High)
Vendor (Linux) PRIMARY
8.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
vuln.today AI
5.5 MEDIUM

Local low-priv trigger of a lock imbalance yields a crash/DoS, so AV:L/PR:L and A:H only; no evidence of confidentiality/integrity impact or scope change, giving C:N/I:N/S:U.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
2.5 LOW
AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L
Red Hat
5.5 MEDIUM
qualitative

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 15:59 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
8.8 (HIGH)
Patch available
Jul 19, 2026 - 16:19 EUVD
CVE Published
Jul 19, 2026 - 14:04 cve.org
HIGH 8.8
CVE Published
Jul 19, 2026 - 14:04 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

In the Linux kernel, the following vulnerability has been resolved:

drm/gpusvm: Fix unbalanced unlock in drm_gpusvm_scan_mm()

There is a unbalanced lock/unlock to gpusvm notifier lock: [ 931.045868] ========= [ 931.046509] WARNING: bad unlock balance detected! [ 931.047149] 6.19.0-rc6+xe-**** #9 Tainted: G U [ 931.048150] ------------------------------------- [ 931.048790] kworker/u5:0/51 is trying to release lock (&gpusvm->notifier_lock) at: [ 931.049801] [<ffffffffa090c0d8>] drm_gpusvm_scan_mm+0x188/0x460 [drm_gpusvm_helper] [ 931.050802] but there are no more locks to release! [ 931.051463]

The drm_gpusvm_notifier_unlock() sits under err_free label and the first jump to err_free is just before calling the drm_gpusvm_notifier_lock() causing unbalanced unlock.

AnalysisAI

Local denial of service in the Linux kernel's DRM GPU SVM helper (drm_gpusvm_helper) arises from an unbalanced notifier-lock release in drm_gpusvm_scan_mm(): an early jump to the err_free label reaches drm_gpusvm_notifier_unlock() before the matching lock is taken, tripping the kernel's 'bad unlock balance' detector. Affected recent kernels (7.0 series, fixed in 7.0.10 and 7.1) can hit this path during GPU shared-virtual-memory scanning, leading to lock-state corruption and likely a crash or hang. There is no public exploit identified at time of analysis and EPSS is low (0.14%, 4th percentile); the fix is upstream in the stable tree.

Technical ContextAI

The flaw lives in drm_gpusvm, the DRM GPU Shared Virtual Memory helper library used by modern GPU drivers (notably Intel Xe) to mirror CPU address spaces into GPU page tables via mmu_notifiers. drm_gpusvm_scan_mm() walks the mm and relies on a per-gpusvm notifier_lock to serialize notifier updates. The bug is a control-flow/locking defect: the function's first goto err_free occurs before drm_gpusvm_notifier_lock() is called, yet the err_free cleanup path unconditionally calls drm_gpusvm_notifier_unlock(), releasing a lock that was never acquired. This is an improper-locking / unlock-without-lock class defect (conceptually CWE-667 Improper Locking / CWE-832 Unlock of a Resource that is not Locked); the upstream CVE record lists CWE as N/A. The result is corrupted lock accounting flagged by lockdep's 'bad unlock balance detected' warning, which can destabilize the kernel workqueue context (seen here in kworker) that drove the scan.

RemediationAI

Vendor-released patch: update to Linux kernel 7.0.10 or 7.1, which reorder the cleanup so drm_gpusvm_notifier_unlock() only runs after the lock is acquired. Apply the corresponding stable-tree commits 8efaa47a871662a8c21b819cec60786f7ef17ab4 and d287dee565c3c32e1ed76ec1847af46809c29b90 (https://git.kernel.org/stable/c/8efaa47a871662a8c21b819cec60786f7ef17ab4) if maintaining a custom tree. Where an immediate kernel update is not possible, the practical compensating control is to avoid loading/using the affected GPU SVM path: unbind or blacklist the GPU driver that pulls in drm_gpusvm_helper (e.g. the Intel Xe driver) on systems that do not require GPU compute/SVM, accepting the trade-off of losing hardware GPU acceleration, and restrict local access to untrusted users since exploitation requires local privileges. There is no network-facing workaround because the trigger is a local kernel code path.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Low
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Not-Affected

Share

CVE-2026-63863 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy