[PATCH i-g-t] lib/i915: Avoid non-canonical address dereference in gem_has_relocations()

[Krzysztof Karas]

Hi Sebastian,

> Fix a general protection fault in igt at gem_exec_big@single caused by
> passing a non-canonical address via relocs_ptr. The test previously
> used a stack-allocated relocation entry, which resulted in an invalid
> pointer being passed to the kernel, triggering a crash.
Did this happen as a result using freed heap allocated data?

> 
> This patch replaces the stack-allocated `reloc` with a NULL pointer,
> ensuring the kernel correctly interprets the absence of relocations and
> avoids undefined behavior.
> 
> A corresponding kernel patch to sanitize user input for relocs_ptr has
> been submitted to the i915 mailing list to further harden the interface.
I noticed that the mentioned patch has been met with some
pushback from the community. If you believe it is required on
the i915 side and worth mentioning here, then please move this
note into the section below "---". Otherwise, please remove
that part.
> 
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11713
> 
> Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka at intel.com>
> ---
>  lib/i915/gem_submission.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/i915/gem_submission.c b/lib/i915/gem_submission.c
> index 7d1c3970f..a03b2e369 100644
> --- a/lib/i915/gem_submission.c
> +++ b/lib/i915/gem_submission.c
> @@ -421,10 +421,10 @@ unsigned int gem_submission_measure(int i915, const intel_ctx_cfg_t *cfg,
>  
>  bool gem_has_relocations(int i915)
>  {
> -	struct drm_i915_gem_relocation_entry reloc = {};
> +	struct drm_i915_gem_relocation_entry *reloc = NULL;
>  	struct drm_i915_gem_exec_object2 obj = {
>  		.handle = gem_create(i915, 4096),
> -		.relocs_ptr = to_user_pointer(&reloc),
> +		.relocs_ptr = to_user_pointer(reloc),
>  		.relocation_count = 1,
>  	};
>  	struct drm_i915_gem_execbuffer2 execbuf = {
> -- 
> 2.34.1
> 

After addressing the comment above:
Reviewed-by: Krzysztof Karas <krzysztof.karas at intel.com>
---
Best Regards,
Krzysztof