CVE-2023-52981

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915: Fix request ref counting during error capture &amp; debugfs dump<br /> <br /> When GuC support was added to error capture, the reference counting<br /> around the request object was broken. Fix it up.<br /> <br /> The context based search manages the spinlocking around the search<br /> internally. So it needs to grab the reference count internally as<br /> well. The execlist only request based search relies on external<br /> locking, so it needs an external reference count but within the<br /> spinlock not outside it.<br /> <br /> The only other caller of the context based search is the code for<br /> dumping engine state to debugfs. That code wasn&amp;#39;t previously getting<br /> an explicit reference at all as it does everything while holding the<br /> execlist specific spinlock. So, that needs updaing as well as that<br /> spinlock doesn&amp;#39;t help when using GuC submission. Rather than trying to<br /> conditionally get/put depending on submission model, just change it to<br /> always do the get/put.<br /> <br /> v2: Explicitly document adding an extra blank line in some dense code<br /> (Andy Shevchenko). Fix multiple potential null pointer derefs in case<br /> of no request found (some spotted by Tvrtko, but there was more!).<br /> Also fix a leaked request in case of !started and another in<br /> __guc_reset_context now that intel_context_find_active_request is<br /> actually reference counting the returned request.<br /> v3: Add a _get suffix to intel_context_find_active_request now that it<br /> grabs a reference (Daniele).<br /> v4: Split the intel_guc_find_hung_context change to a separate patch<br /> and rename intel_context_find_active_request_get to<br /> intel_context_get_active_request (Tvrtko).<br /> v5: s/locking/reference counting/ in commit message (Tvrtko)<br /> <br /> (cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)