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@gmail.com>
Signed-off-by: Ariel Silver <arielsilver77@gmail.com>
Cc: stable@vger.kernel.org
---
 drivers/input/keyboard/atkbd.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index XXXXXXX..XXXXXXX 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -1111,6 +1111,13 @@ static int atkbd_get_keymap_from_fwnode(struct
atkbd *atkbd)
    for (i = 0; i < n; i++) {
        scancode = SCANCODE(ptr[i]);
        keycode = KEYCODE(ptr[i]);
+       if (scancode >= ATKBD_KEYMAP_SIZE) {
+           dev_warn(dev,
+                "invalid scancode 0x%x in FW keymap entry %d\n",
+                scancode, i);
+           kfree(ptr);
+           return -EINVAL;
+       }
        atkbd->keycode[scancode] = keycode;
    }

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@gmail.com>
> Signed-off-by: Ariel Silver <arielsilver77@gmail.com>
> Cc: stable@vger.kernel.org

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.

> ---
>  drivers/input/keyboard/atkbd.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index XXXXXXX..XXXXXXX 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -1111,6 +1111,13 @@ static int atkbd_get_keymap_from_fwnode(struct
> atkbd *atkbd)
>     for (i = 0; i < n; i++) {
>         scancode = SCANCODE(ptr[i]);
>         keycode = KEYCODE(ptr[i]);
> +       if (scancode >= ATKBD_KEYMAP_SIZE) {
> +           dev_warn(dev,
> +                "invalid scancode 0x%x in FW keymap entry %d\n",
> +                scancode, i);
> +           kfree(ptr);
> +           return -EINVAL;
> +       }
>         atkbd->keycode[scancode] = keycode;
>     }

I think you pasted this to gmail web interface which resulted in line
wrapping and messed up indentation. I untangled it but if you plan on
sending more kernel patches please try to not use web interface. Making
"git send-email" workig might be worth it, or look into "b4 send" with a
web endpoint.

Thanks.

-- 
Dmitry

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@gmail.com>
> > Signed-off-by: Ariel Silver <arielsilver77@gmail.com>
> > Cc: stable@vger.kernel.org
> 
> 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