Detecting invalid gpio keys configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux