This CVE exposes a subtle but important pattern in the DRM scheduler subsystem: double-invocation of drm_sched_entity_fini() in the PowerVR driver that was functionally harmless until refcount tracking was added, then immediately triggered an underflow warning. The core issue is that drm_sched_entity_destroy() already calls drm_sched_entity_fini() internally, yet the driver's pvr_queue_destroy() path calls fini() again. This was not an obvious misuse — the driver's authors likely assumed both calls were necessary for complete cleanup in different destruction scenarios. The refcount instrumentation in commit fd177135f0e6 didn't introduce the bug; it exposed a latent violation of the scheduler's implicit ownership contract that had existed silently. The immediate fix — removing the redundant fini() call from the failure path — addresses the symptom but not the underlying ambiguity in the API design. The DRM scheduler provides destroy() and fini() as separate entry points without clear documentation of which component owns final cleanup, leaving driver authors to infer semantics from implementation behavior. Audit your DRM drivers for similar double-call patterns in entity teardown paths, particularly in code paths that invoke both kill/destroy and separate fini() calls. This is likely not an isolated case — the pattern of defensive instrumentation revealing latent ownership violations has appeared in multiple DRM scheduler changes, and the next refcount addition in a different scheduler path may expose more of these. Prioritise reviewing drivers that implement custom queue or context destruction sequences, as layered teardown paths are where ownership assumptions tend to diverge.
CVE-2026-68263
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedIn the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix double call to drm_sched_entity_fini() Call sequence of double call: pvr_context_destroy pvr_context_kill_queues pvr_queue_kill drm_sched_entity_destroy drm_sched_entity_fini // here pvr_context_put kref_put(..., pvr_context_release) pvr_context_destroy_queues pvr_queue_destroy drm_sched_entity_fini // here Call to drm_sched_entity_destroy() from pvr_context_kill_queues() calls drm_sched_entity_flush() + drm_sched_entity_fini(). drm_sched_entity_flush() ensures all pending jobs are completed and drm_sched_entity_fini() ensures no further submission is allowed as per expectation from pvr_context_kill_queues(). Double call to drm_sched_entity_fini() is misuse of the API so keep call only in pvr_context_create() failure path. Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 ("drm/sched: Account entity GPU time"): [ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcount_t: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drm_gpuvm drm_exec gpu_sched drm_shmem_helper xhci_plat_hcd xhci_hcd dwc3 usbcore usb_common snd_soc_simple_card snd_soc_simple_card_utils sa2ul sha512 sha256 dwc3_am62 sha1 authenc rti_wdt libsha512 at24 sch_fq_codel fuse dm_mod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvr_queue_fence_release_work [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcount_warn_saturate+0xf4/0x144 [ 789.490884] lr : refcount_warn_saturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcount_warn_saturate+0xf4/0x144 (P) [ 789.491043] drm_sched_entity_fini+0x164/0x18c [gpu_sched] [ 789.491081] pvr_queue_destroy+0x64/0x134 [powervr] [ 789.491110] pvr_context_destroy_queues+0x34/0x64 [powervr] [ 789.491138] pvr_context_release+0x70/0xac [powervr] [ 789.491166] pvr_context_put.part.0+0x5c/0x7c [powervr] [ 789.491193] pvr_context_put+0x14/0x24 [powervr] [ 789.491221] pvr_queue_fence_release_work+0x20/0x38 [powervr] [ 789.491249] process_one_work+0x160/0x4c4 [ 789.491264] worker_thread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] ret_from_fork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysisA detailed technical summary for this CVE is being prepared.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Local
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
From vendor dataThere is no version to upgrade to and no patch to apply. Every affected install stays exposed until the vendor ships a fix — or somebody else builds one.
Free. We build fixes in the order the community asks for them — and we’ll tell you the moment this one lands.
We develop and verify an original fix where the vendor hasn’t, from $1,950. Deployed to your staging first — never straight to production.
Scope it with usSee what else the community needs solved on the solutions-needed board.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-68263 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesThis CVE exposes a subtle but important pattern in the DRM scheduler subsystem: double-invocation of drm_sched_entity_fini() in the PowerVR driver that was functionally harmless until refcount tracking was added, then immediately triggered an underflow warning. The core issue is that drm_sched_entity_destroy() already calls drm_sched_entity_fini() internally, yet the driver's pvr_queue_destroy() path calls fini() again. This was not an obvious misuse — the driver's authors likely assumed both calls were necessary for complete cleanup in different destruction scenarios. The refcount instrumentation in commit fd177135f0e6 didn't introduce the bug; it exposed a latent violation of the scheduler's implicit ownership contract that had existed silently. The immediate fix — removing the redundant fini() call from the failure path — addresses the symptom but not the underlying ambiguity in the API design. The DRM scheduler provides destroy() and fini() as separate entry points without clear documentation of which component owns final cleanup, leaving driver authors to infer semantics from implementation behavior. Audit your DRM drivers for similar double-call patterns in entity teardown paths, particularly in code paths that invoke both kill/destroy and separate fini() calls. This is likely not an isolated case — the pattern of defensive instrumentation revealing latent ownership violations has appeared in multiple DRM scheduler changes, and the next refcount addition in a different scheduler path may expose more of these. Prioritise reviewing drivers that implement custom queue or context destruction sequences, as layered teardown paths are where ownership assumptions tend to diverge.
Practitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-68263 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data