CVE-2026-31656

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat<br /> <br /> A use-after-free / refcount underflow is possible when the heartbeat<br /> worker and intel_engine_park_heartbeat() race to release the same<br /> engine-&gt;heartbeat.systole request.<br /> <br /> The heartbeat worker reads engine-&gt;heartbeat.systole and calls<br /> i915_request_put() on it when the request is complete, but clears<br /> the pointer in a separate, non-atomic step. Concurrently, a request<br /> retirement on another CPU can drop the engine wakeref to zero, triggering<br /> __engine_park() -&gt; intel_engine_park_heartbeat(). If the heartbeat<br /> timer is pending at that point, cancel_delayed_work() returns true and<br /> intel_engine_park_heartbeat() reads the stale non-NULL systole pointer<br /> and calls i915_request_put() on it again, causing a refcount underflow:<br /> <br /> ```<br /> [487.221889] Workqueue: i915-unordered engine_retire [i915]<br /> [487.222640] RIP: 0010:refcount_warn_saturate+0x68/0xb0<br /> ...<br /> [487.222707] Call Trace:<br /> [487.222711] <br /> [487.222716] intel_engine_park_heartbeat.part.0+0x6f/0x80 [i915]<br /> [487.223115] intel_engine_park_heartbeat+0x25/0x40 [i915]<br /> [487.223566] __engine_park+0xb9/0x650 [i915]<br /> [487.223973] ____intel_wakeref_put_last+0x2e/0xb0 [i915]<br /> [487.224408] __intel_wakeref_put_last+0x72/0x90 [i915]<br /> [487.224797] intel_context_exit_engine+0x7c/0x80 [i915]<br /> [487.225238] intel_context_exit+0xf1/0x1b0 [i915]<br /> [487.225695] i915_request_retire.part.0+0x1b9/0x530 [i915]<br /> [487.226178] i915_request_retire+0x1c/0x40 [i915]<br /> [487.226625] engine_retire+0x122/0x180 [i915]<br /> [487.227037] process_one_work+0x239/0x760<br /> [487.227060] worker_thread+0x200/0x3f0<br /> [487.227068] ? __pfx_worker_thread+0x10/0x10<br /> [487.227075] kthread+0x10d/0x150<br /> [487.227083] ? __pfx_kthread+0x10/0x10<br /> [487.227092] ret_from_fork+0x3d4/0x480<br /> [487.227099] ? __pfx_kthread+0x10/0x10<br /> [487.227107] ret_from_fork_asm+0x1a/0x30<br /> [487.227141] <br /> ```<br /> <br /> Fix this by replacing the non-atomic pointer read + separate clear with<br /> xchg() in both racing paths. xchg() is a single indivisible hardware<br /> instruction that atomically reads the old pointer and writes NULL. This<br /> guarantees only one of the two concurrent callers obtains the non-NULL<br /> pointer and performs the put, the other gets NULL and skips it.<br /> <br /> (cherry picked from commit 13238dc0ee4f9ab8dafa2cca7295736191ae2f42)