A few not-really-an-issue fixes found by Claude:
1. ctx->buttons_down[number]: the 'number' value comes from
libinput_event_tablet_pad_get_button_number() and is written into
a fixed-size array of 32 elements without bounds checking. A crafted
or malicious device reporting button numbers >= 32 causes a stack
buffer overflow.
2. ctx->ring[number], ctx->strip[number], ctx->dial[number]: these are
fixed-size arrays of 2 elements each. Ring/strip/dial numbers from
libinput events are used as indices without bounds checking. Values
>= 2 cause out-of-bounds writes.
3. assert()-based error handling for open() and libevdev_new_from_fd():
assert() is compiled to a no-op in release builds (NDEBUG). This
means that in release builds, a failed open() returns fd=-1, and
libevdev_new_from_fd() is called with an invalid fd. The result is
undefined behavior.
4. Variable-length array (VLA) 'empty[termwidth]' in print_bar():
termwidth comes from an ioctl(TIOCGWINSZ) call and could be very
large, causing a stack overflow. Replace with a fixed-size buffer.
None of these really matter for a niche debugging tool.
Co-Authored-by: Claude Code <noreply@anthropic.com>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1467>
This patch adds a new API for enabling public "plugins" in libinput, in
addition to the exisitng internal ones. The API is currently limited to
specifying which paths should be loaded and whether to load them.
Public plugins are static, they are loaded before the context is initialized
and do not update after that.
If plugins are to be loaded, libinput will then run through those paths,
look up files and pass them to (future) plugins to load the actual
files.
Our debugging tools have an --enable-plugins and
--disable-plugins option that load from the default data paths
(/etc/libinput/plugins and /usr/lib{64}/libinput/plugins) and from
the $builddir/plugins directory.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1192>
