Hello,
I have recently come across following invalid entry:
gpio-keys {
compatible = "gpio-keys";
servicing-sw {
label = "servicing-sw";
gpios = <&gpio3 1 GPIO_ACTIVE_LOW>;
linux,code = <BTN_0>;
linux,input-type = <EV_SW>;
debounce-interval = <50>;
};
};
While the entry is clearly invalid, no tools currently detect it.
Documentation/devicetree/bindings/input/gpio-keys.yaml allows any uint32
as linux,code. The actual allowed values do depend on linux,input-type.
Should the gpio-keys.yaml be updated to actually restrict the range
based on linux,input-type?
If the yaml should validate range, it would have to be updated each time
new input event code is added. Is it acceptable? Or is there some way to
use the definitions from include/uapi/linux/input-event-codes.h in yaml?
The code does not sanitize the linux,code values. On 32-bit arm system,
the above example causes kernel panic due to memory corruption:
* gpio_keys_setup_key() in drivers/input/keyboard/gpio_keys.c calls
input_set_capability(input, EV_SW, BTN_0)
* input_set_capability() in drivers/input/input.c calls
__set_bit(BTN_0, dev->swbit)
* The setbit changes poller pointer least significant bit
* input_register_device() calls input_dev_poller_finalize(dev->poller)
* input_dev_poller_finalize() accesses memory at address 0x00000005
While provided example hopefully crashes every time making the issue
obvious, other code values can cause much more subtle issues.
Should the input_set_capability() warn if code is outside bitmap range?
Best Regards,
Tomasz Mon
