Re: [PATCH v2] Input: xen-kbdfront - bound the backend-supplied keycode
From: Dmitry Torokhov
Date: Fri Nov 06 2026 - 01:22:52 EST
On Fri, Nov 06, 2026 at 10:02:17AM +0800, Guo Zihao wrote:
> Keycodes arrive from the shared ring the backend writes:
>
> if (test_bit(key->keycode, info->ptr->keybit)) {
> dev = info->ptr;
> } else if (test_bit(key->keycode, info->kbd->keybit)) {
> ...
> } else {
> pr_warn("unhandled keycode 0x%x\n", key->keycode);
> return;
> }
>
> The keycode is a plain u32 from the ring page, while the keybit
> bitmaps it is tested against are sized for the KEY_CNT keycode bits
> declared to the input core. A backend that sends a keycode at or
> above KEY_CNT makes test_bit() read past the bitmap to decide which
> device gets the event, and no keycode at or above KEY_MAX is a valid
> EV_KEY code in the first place.
>
> Since the event sits in memory the backend keeps writing access to,
> the keycode must also be fetched exactly once: re-reading key->keycode
> after the bounds check would let a concurrent backend write feed an
> unchecked value to test_bit() and input_event(). Snapshot the keycode
> into a local variable with READ_ONCE() before validating it, and use
> the snapshot (as well as the already snapshotted pressed value)
> throughout.
>
> Ignore keycodes the bitmaps cannot hold.
>
> Fixes: 4ee36dc08e5c ("xen pvfb: Para-virtual framebuffer, keyboard and pointer driver")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Guo Zihao <guozh23@xxxxxxxxxxxx>
Please explain your threat model.
Thanks.
--
Dmitry