Re: Subject: [PATCH] Input: atkbd - validate scancode in firmware keymap entries

From: Dmitry Torokhov

Date: Sat Feb 28 2026 - 21:27:00 EST


On Fri, Feb 20, 2026 at 06:33:55PM -0800, Dmitry Torokhov wrote:
> Hi Ariel,
>
> On Fri, Feb 20, 2026 at 10:44:28AM +0200, Ariel Silver wrote:
> > The SCANCODE() macro extracts a 16-bit value (0..65535) from firmware
> > device property data, but atkbd_get_keymap_from_fwnode() uses it
> > directly to index atkbd->keycode[], which only has ATKBD_KEYMAP_SIZE
> > (512) elements. A firmware-supplied scancode >= 512 causes a heap
> > out-of-bounds write that can corrupt adjacent struct atkbd fields and
> > neighboring slab objects.
> >
> > Add a bounds check that rejects the entire firmware keymap if any entry
> > contains an out-of-range scancode, consistent with the validation
> > performed by matrix_keypad_parse_keymap() in drivers/input/matrix-keymap.c
> > for the same "linux,keymap" property format. When rejected, the driver
> > falls back to the default keycode table.
> >
> > Fixes: 9d17ad2369dc ("Input: atkbd - receive and use physcode->keycode
> > mapping from FW")
> > Reported-by: Ariel Silver <arielsilver77@xxxxxxxxx>
> > Signed-off-by: Ariel Silver <arielsilver77@xxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx
>
> Was it observed on real hardware or this is theoretical? I do not think
> this needs to go to stable, but otherwise I will apply it.

Queued for the next release, thank you.

--
Dmitry