[Feature Request]: CVE on libinput and its relationship to this driver

[GLLM]

Describe the bug

A CVE was disclosed on libinput : https://www.phoronix.com/news/libinput-1.31.2-Security-Fix
& https://lore.freedesktop.org/wayland-devel/aiDRA35Gggyi5mTY@quokka/T/#u
enabling an arbitrary root cood execution.

libinput 1.31.2 fixes this.
Shouldn't the min version for libinput be updated ?

Expected behavior

min version for libinput should be >= libinput 1.31.2

Relevant log output

Desktop

• Program version [e.g. 57c742a]
• Distro [e.g. Arch Linux]
• Kernel [e.g. 5.18.15.arch1-2]

[ldrahnik]

@GLLM Great observation!

Someone else's opinion is welcome.

I suggest adding now at least this message (or something like that) to the install process when is detected version of $ libinput --version lower than mentioned versions:

Please ensure your `$ libinput --version` version is atleast on version <mentioned versions>, we recommend it because was published this expoit (link) on lower versions and this project relies on `libinput` and during install process is added `uinput` group to your current user which increases the risk of using mentioned exploit on your laptop. Do you accept the increased risk?

And I suggest also consider installing this driver as a system package without adding i2c and uinput groups to the current user or have 2 versions of install process: system and user.

Btw. my version is for example on Elementary OS 7.1 after $ sudo apt upgrade:

$ libinput --version
1.20.0

Related to these other repozitories: https://github.com/asus-linux-drivers/asus-wmi-hotkeys-driver, https://github.com/asus-linux-drivers/asus-numberpad-driver, https://github.com/asus-linux-drivers/asus-accel-tablet-mode-driver

[karandesai2005]

Hey @ldrahnik ! So I Looked into this properly and here's my assessment.
The CVE (CVE-2026-50292) is a udev CRLF injection in libinput's libinput-device-group helper. A malicious uinput device can set a PHYS sysattr with a \n in it, causing udev to parse it as two separate key-value pairs and execute attacker-controlled properties (e.g. REMOVE_CMD) as root.
Why this driver specifically matters: the install process adds the current user to the uinput group. That's exactly what elevates a normal user to the threat level where this CVE becomes exploitable — on a default system uinput is root-only, but once your install script grants group access, a logged-in user can create malicious uinput devices and trigger the vulnerable code path in libinput.
I agree with your suggested approach. A version check during install makes sense.

Here's a concrete implementation:

LIBINPUT_VERSION=$(libinput --version 2>/dev/null)
REQUIRED="1.30.4"
if [ "$(printf '%s\n' "$REQUIRED" "$LIBINPUT_VERSION" | sort -V | head -n1)" != "$REQUIRED" ]; then
    echo "WARNING: libinput $LIBINPUT_VERSION detected."
    echo "CVE-2026-50292 affects libinput < 1.30.4 / < 1.31.3."
    echo "This driver adds you to the 'uinput' group, which increases your exposure."
    echo "Please update libinput before continuing, or proceed at your own risk."
    read -p "Continue anyway? [y/N] " confirm
    [ "$confirm" = "y" ] || exit 1
fi

On your second point about system vs user install: also agree. Running the daemon as a system service without uinput group membership (using a dedicated service user with minimal permissions instead) would be the cleaner long-term architecture. Happy to help think through that if useful.

[ldrahnik]

Thank you @karandesai2005 for the comment. Pushed commit with proposed change to affected repositories in this org.