From: Peter Hutterer <peter.hutterer@who-t.net>
To: sashiko-bot@kernel.org
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH] Input: uinput/uhid - disallow control characters in phys paths
Date: Thu, 23 Jul 2026 15:54:37 +1000 [thread overview]
Message-ID: <amGrm7qnjHvXPYeX@quokka> (raw)
In-Reply-To: <20260717050748.5DC071F000E9@smtp.kernel.org>
On Fri, Jul 17, 2026 at 05:07:47AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] The patch provides an incomplete mitigation for CVE-2026-50292. It sanitizes the `phys` property to prevent udev property injection via control characters (newlines), but completely fails to sanitize the `name` and `uniq` properties, which are also exported to uevents and controlled by userspace.
> --
>
> --- Patch [1]: [PATCH] Input: uinput/uhid - disallow control characters in phys paths ---
> commit 1a76e90e7acc09a84a52efddc46e598419020a19
> Author: Peter Hutterer <peter.hutterer@who-t.net>
>
> Input: uinput/uhid - disallow control characters in phys paths
>
> This commit sanitizes the phys property in uinput and uhid devices to replace
> control characters with '?'. This prevents userspace from injecting malicious
> udev properties via newlines, which previously triggered CVE-2026-50292.
>
> > diff --git a/drivers/hid/uhid.c b/drivers/hid/uhid.c
> > index 37b60c3aaf66a..baf1fe8290f75 100644
> > --- a/drivers/hid/uhid.c
> > +++ b/drivers/hid/uhid.c
> > @@ -518,6 +518,7 @@ static int uhid_dev_create2(struct uhid_device *uhid,
> > strscpy(hid->name, ev->u.create2.name, sizeof(hid->name));
> > BUILD_BUG_ON(sizeof(hid->phys) != sizeof(ev->u.create2.phys));
> > strscpy(hid->phys, ev->u.create2.phys, sizeof(hid->phys));
> > + input_sanitize_phys(hid->phys);
> > BUILD_BUG_ON(sizeof(hid->uniq) != sizeof(ev->u.create2.uniq));
> > strscpy(hid->uniq, ev->u.create2.uniq, sizeof(hid->uniq));
>
> [Severity: High]
> This isn't a bug introduced by this patch, but while this successfully mitigates
> CVE-2026-50292 for the phys property, does it still leave the name and uniq
> properties vulnerable?
>
> In uhid_dev_create2(), the user-controlled ev->u.create2.name and
> ev->u.create2.uniq strings are copied directly without passing through a
> similar sanitization function.
>
> Additionally, in drivers/input/misc/uinput.c:uinput_dev_setup(), the name
> property is also set without sanitization:
>
> dev->name = kstrndup(setup.name, UINPUT_MAX_NAME_SIZE, GFP_KERNEL);
>
> If a user with write access to /dev/uinput or /dev/uhid sets the name or uniq
> properties to strings containing newlines, wouldn't this still allow the
> injection of arbitrary udev environment variables when INPUT_ADD_HOTPLUG_VAR
> formats them for uevents?
name and uniq are controlled by the firmware and thus by the vendor and
control characters (or at least non-ascii) may be legitimately present.
There is no such thing as a sanitized name.
Cheers,
Peter
next prev parent reply other threads:[~2026-07-23 5:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 4:49 [PATCH] Input: uinput/uhid - disallow control characters in phys paths Peter Hutterer
2026-07-17 5:07 ` sashiko-bot
2026-07-23 5:54 ` Peter Hutterer [this message]
2026-07-24 23:51 ` Dmitry Torokhov
2026-07-24 7:51 ` David Rheinsberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amGrm7qnjHvXPYeX@quokka \
--to=peter.hutterer@who-t.net \
--cc=dmitry.torokhov@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=sashiko-bot@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.