Re: [PATCH] HID: logitech-hidpp: fix race condition when accessing stale stack pointer

[Jiri Kosina]

On Wed, 1 Apr 2026, Benoit Sevens wrote:

> From: Beno=C3=AEt Sevens <bsevens@xxxxxxxxxx>
> 
> The driver uses hidpp->send_receive_buf to point to a stack-allocated
> buffer in the synchronous command path (__do_hidpp_send_message_sync).
> However, this pointer is not cleared when the function returns.
> 
> If an event is processed (e.g. by a different thread) while the
> send_mutex is held by a new command, but before that command has
> updated send_receive_buf, the handler (hidpp_raw_hidpp_event) will
> observe that the mutex is locked and dereference the stale pointer.
> 
> This results in an out-of-bounds access on a different thread's kernel
> stack (or a NULL pointer dereference on the very first command).
> 
> Fix this by:
> 1. Clearing hidpp->send_receive_buf to NULL before releasing the mutex
>    in the synchronous command path.
> 2. Moving the assignment of the local 'question' and 'answer' pointers
>    inside the mutex_is_locked() block in the handler, and adding
>    a NULL check before dereferencing.

Now applied.

Benjamin had some ideas on further cleanup (allocating with __free__ 
instead of using stack pointer), but that'd be a little bigger cleanup, so 
let's keep that separate.

Thanks,

-- 
Jiri Kosina
SUSE Labs