[PATCH] drm/ioc32: stop speculation on the drm_compat_ioctl path

[PATCH] drm/ioc32: stop speculation on the drm_compat_ioctl path

[Greg Kroah-Hartman]

The drm compat ioctl path takes a user controlled pointer, and then
dereferences it into a table of function pointers, the signature method
of spectre problems.  Fix this up by calling array_index_nospec() on the
index to the function pointer list.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: stable <stable@kernel.org>
Assisted-by: gkh_clanker_2000
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
My scripts caught this codepath as not being "protected" for the
old-school spectre attack.  I don't know how realistic it is, but it
seems like this is the correct thing to be doing for a 32bit ioctl on
the drm path, as "local" users can make these.

 drivers/gpu/drm/drm_ioc32.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index e6b5b06de148..f3e40d1e6098 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -28,6 +28,7 @@
  * IN THE SOFTWARE.
  */
 #include <linux/compat.h>
+#include <linux/nospec.h>
 #include <linux/ratelimit.h>
 #include <linux/export.h>
 
@@ -374,6 +375,7 @@ long drm_compat_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
 	if (nr >= ARRAY_SIZE(drm_compat_ioctls))
 		return drm_ioctl(filp, cmd, arg);
 
+	nr = array_index_nospec(nr, ARRAY_SIZE(drm_compat_ioctls));
 	fn = drm_compat_ioctls[nr].fn;
 	if (!fn)
 		return drm_ioctl(filp, cmd, arg);
-- 
2.53.0

Claude review: drm/ioc32: stop speculation on the drm_compat_ioctl path

[Claude Code Review Bot]

Overall Series Review

Subject: drm/ioc32: stop speculation on the drm_compat_ioctl path
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Patches: 1
Reviewed: 2026-03-25T06:35:42.842238

---

This is a single, straightforward patch that adds Spectre v1 speculation barrier protection to the DRM compat ioctl path. The fix is correct and follows the standard kernel pattern for mitigating Spectre bounds-check bypass attacks. The change is minimal, well-targeted, and appropriate for stable backport.

---
Generated by Claude Code Patch Reviewer

Claude review: drm/ioc32: stop speculation on the drm_compat_ioctl path

[Claude Code Review Bot]

Patch Review

**Assessment: Good patch, correct approach.**

The patch adds `array_index_nospec()` to clamp the user-controlled `nr` index after the bounds check at line 375, preventing speculative out-of-bounds access into the `drm_compat_ioctls` function pointer table.

```c
if (nr >= ARRAY_SIZE(drm_compat_ioctls))
    return drm_ioctl(filp, cmd, arg);

nr = array_index_nospec(nr, ARRAY_SIZE(drm_compat_ioctls));
fn = drm_compat_ioctls[nr].fn;
```

This is textbook Spectre v1 mitigation: a user-controlled value (`nr`, derived from `DRM_IOCTL_NR(cmd)`) is used as an index into an array of function pointers (`drm_compat_ioctls[nr]`) after a bounds check. The CPU can speculatively execute past the bounds check with an out-of-bounds index, so `array_index_nospec()` ensures the index is clamped to the valid range even in the speculative path.

**Minor observations:**

1. The `#include <linux/nospec.h>` is correctly placed in alphabetical order.

2. Note that `nr` is also used again at line 387 (`drm_compat_ioctls[nr].name`) for the debug log, which is also protected by the same sanitized value — good.

3. The commit message mentions "Assisted-by: gkh_clanker_2000" — this appears to be an AI/script-assisted finding. The tag is non-standard (not `Co-developed-by` or similar recognized tags), but this is a style/process matter for the maintainers to decide on.

4. The practical exploitability is low (as Greg notes in the cover text), since the attacker needs local access and the compat ioctl path is a relatively constrained attack surface. Nonetheless, this is the right defensive measure to apply.

**Verdict:** No functional issues. The patch is correct and ready to apply.

---
Generated by Claude Code Patch Reviewer