CVE-2026-68263 in Linux
摘要
由 VulDB • 2026-08-11
Based on the kernel log provided, here is an analysis of the crash and potential causes:
### **Summary** This is a **kernel panic/oops** in the **PowerVR GPU driver (`powervr`)** triggered by a **reference count underflow**. The system crashed while cleaning up a GPU scheduling entity during context destruction.
---
### **Key Error Analysis**
1. **Root Cause: `refcount_warn_saturate+0xf4/0x144 (P)`** * This function is called when a reference count (`kref` or similar) reaches zero and another decrement is attempted, causing it to wrap around (underflow). * The `(P)` indicates this was triggered by `WARN_ON_ONCE`, meaning the kernel detected an invalid state but continued execution until the crash.
2. **Call Trace Breakdown** ```text refcount_warn_saturate+0xf4/0x144 (P) ↓ drm_sched_entity_fini+0x164/0x18c [gpu_sched] ← DRM GPU scheduler cleanup
↓ pvr_queue_destroy+0x64/0x134 [powervr] ← PowerVR queue destruction
↓ pvr_context_destroy_queues+0x34/0x64 [powervr]← Destroying all queues for a context
↓ pvr_context_release+0x70/0xac [powervr] ← Releasing the GPU context
↓ pvr_context_put.part.0+0x5c/0x7c [powervr]
↓ pvr_queue_fence_release_work+0x20/0x38 [powervr] ← Workqueue handler
↓ process_one_work+0x160/0x4c4 ← Kernel workqueue processing ```
3. **Critical Insight** * The crash occurs in `pvr_queue_fence_release_work`, which is a **workqueue callback**. This suggests that: - A GPU fence was signaled or timed out. - The driver scheduled cleanup work (`pvr_queue_fence_release_work`). - During this async cleanup, it tried to destroy the queue/context. - However, another part of the code (or a race condition) had already freed some resources referenced by `drm_sched_entity`, leading to an invalid reference count decrement in `drm_sched_entity_fini`.
---
### **Likely Causes**
1. **Race Condition in PowerVR Driver**: * The driver may be freeing GPU context/queue structures while they are still being accessed or cleaned up by another thread (e.g., the DRM scheduler). * Specifically, `drm_sched_entity_fini` expects a valid reference to the entity, but it seems the entity was already partially freed.
2. **Use-After-Free**: - A pointer to a GPU queue/entity is being used after its memory has been released elsewhere in the driver stack.
3. **Bug in `gpu_sched` Integration**: - The PowerVR driver integrates with Linux's DRM GPU scheduler (`drm_gpu_scheduler`). If the integration doesn't properly handle reference counting during async cleanup (like fence release), it can lead to this underflow.
4. **Driver Version Bug**: - This is likely a known bug in your specific version of the `powervr` driver (often found in embedded Linux systems using Imagination Technologies PowerVR GPUs). Check for updates or patches from your SoC vendor (e.g., NXP, Rockchip, Allwinner) or kernel maintainer.
---
### **Recommended Actions**
1. **Update Kernel/Driver**: - If you are on a mainline Linux kernel, check if this bug has been fixed in newer versions (`drm-next` or `linux-6.x`). - If using an out-of-tree vendor driver (common for PowerVR), contact your SoC provider for a patched version.
2. **Workaround**: - Avoid heavy GPU workloads that trigger frequent context/queue creation/destruction if possible. - Ensure no user-space applications are leaking GPU contexts or failing to properly release them before process exit.
3. **Debugging Steps** (if you have access): - Enable `CONFIG_DRM_SCHED_DEBUG` and `CONFIG_PVR_DEBUG` in kernel config for more verbose logs. - Use `kmemleak` to detect memory leaks or use-after-free issues: ```bash echo 1 > /sys/kernel/debug/kmemleak # Reproduce the issue cat /sys/kernel/debug/kmemleak ```
4. **Report Bug**: - If
If you want to get best quality of vulnerability data, you may have to visit VulDB.