[PATCH v1 0/2] Input: evdev/uinput errno alignment

[PATCH v1 0/2] Input: evdev/uinput errno alignment

[Iván Ezequiel Rodriguez]

Hi,

Two small fixes so ioctl failures match what helpers and uapi docs
already document.

Patch 1 propagates the return value of input_ff_effect_from_user()
from EVIOCSFF instead of always mapping failures to -EFAULT (wrong
size becomes -EINVAL).

Patch 2 returns -EINVAL for UI_ABS_SETUP when the axis code is out of
range (was -ERANGE) and rejects ABS_MT_SLOT with a non-zero minimum.

Base: v7.3-rc1

Tested: built bzImage with CONFIG_INPUT_UINPUT=y and CONFIG_INPUT_EVDEV=y;
QEMU initramfs smoke:

  - UI_ABS_SETUP with code > ABS_MAX → EINVAL
  - UI_ABS_SETUP ABS_MT_SLOT with min != 0 → EINVAL
  - EVIOCSFF with wrong size → EINVAL

Thanks,
Iván

Iván Ezequiel Rodriguez (2):
  Input: evdev: propagate EVIOCSFF copy errors correctly
  Input: uinput: align UI_ABS_SETUP validation with uapi docs

 drivers/input/evdev.c       | 5 +++--
 drivers/input/misc/uinput.c | 9 ++++++++-
 2 files changed, 11 insertions(+), 3 deletions(-)

-- 
2.43.0

[PATCH v1 1/2] Input: evdev: propagate EVIOCSFF copy errors correctly

[Iván Ezequiel Rodriguez]

Return the error from input_ff_effect_from_user() instead of always
mapping failures to -EFAULT, so wrong buffer sizes surface as -EINVAL.

Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com>
---
 drivers/input/evdev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 3a718d600006..27bcf4f099be 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -1180,8 +1180,9 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 		return str_to_user(dev->uniq, size, p);
 
 	case EVIOC_MASK_SIZE(EVIOCSFF):
-		if (input_ff_effect_from_user(p, size, &effect))
-			return -EFAULT;
+		error = input_ff_effect_from_user(p, size, &effect);
+		if (error)
+			return error;
 
 		error = input_ff_upload(dev, &effect, file);
 		if (error)
-- 
2.43.0

Re: [PATCH v1 1/2] Input: evdev: propagate EVIOCSFF copy errors correctly

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Kernel stack memory leak via EVIOCSABS and EVIOCGABS ioctls.
- [High] Kernel stack memory leak and KMSAN uninit-value bug in EVIOCSFF ioctl for compat tasks.
--

commit a43660053a9496b6179da4d914ad9411bf768ddb
Author: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com>

Input: evdev: propagate EVIOCSFF copy errors correctly

Return the error from input_ff_effect_from_user() instead of always
mapping failures to -EFAULT, so wrong buffer sizes surface as -EINVAL.

> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index c7325226cb866..405d43f840f3e 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -1175,8 +1175,9 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
[ ... ]
>  	case EVIOC_MASK_SIZE(EVIOCSFF):
> -		if (input_ff_effect_from_user(p, size, &effect))
> -			return -EFAULT;
> +		error = input_ff_effect_from_user(p, size, &effect);
> +		if (error)
> +			return error;
>  
>  		error = input_ff_upload(dev, &effect, file);

[Severity: High]
This is a pre-existing issue, but can this leak kernel stack memory and
cause a use of uninitialized memory in compat mode?

In evdev_do_ioctl(), struct ff_effect effect is declared on the stack
without initialization. When a 32-bit compat userspace process calls the
EVIOCSFF ioctl, input_ff_effect_from_user() copies 44 bytes into the 48-byte
native struct, leaving 4 bytes uninitialized:

drivers/input/input-compat.c:input_ff_effect_from_user() {
    ...
    if (copy_from_user(compat_effect, buffer,
                       sizeof(struct ff_effect_compat)))
    ...
}

The kernel then copies the full 48-byte struct to the heap in
input_ff_upload():

drivers/input/ff-core.c:input_ff_upload() {
    ...
    ff->effects[id] = *effect;
    ...
}

If the input device is a uinput virtual device managed by a 64-bit daemon,
could the UI_BEGIN_FF_UPLOAD ioctl copy the full 48-byte struct to the
daemon, leaking the 4 bytes of uninitialized kernel stack memory?


While reviewing this, I noticed a similar pre-existing issue in the same
function with the EVIOCSABS and EVIOCGABS ioctls.

[Severity: High]
This is a pre-existing issue, but does this code leak kernel stack memory
to userspace?

In evdev_do_ioctl(), struct input_absinfo abs is declared without
initialization. A malicious user can provide a small size in the EVIOCSABS
ioctl command, causing only a partial copy and leaving the rest of the
struct uninitialized:

drivers/input/evdev.c:evdev_do_ioctl() {
    ...
    if (copy_from_user(&abs, p, min_t(size_t, size,
                                      sizeof(struct input_absinfo))))
    ...
}

The uninitialized stack memory is copied into the device's heap allocation:

drivers/input/evdev.c:evdev_do_ioctl() {
    ...
    dev->absinfo[t] = abs;
    ...
}

Can this memory subsequently be leaked to userspace when read back via the
EVIOCGABS ioctl?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831152156.166514-1-ivanrwcm25@gmail.com?part=1

[PATCH v1 2/2] Input: uinput: align UI_ABS_SETUP validation with uapi docs

[Iván Ezequiel Rodriguez]

Return -EINVAL for out-of-range axis codes and reject ABS_MT_SLOT
configurations whose minimum is not zero, as documented in uapi.

Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com>
---
 drivers/input/misc/uinput.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index d32fa4b508fc..e05c80182252 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -424,6 +424,13 @@ static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
 	min = abs->minimum;
 	max = abs->maximum;
 
+	if (code == ABS_MT_SLOT && min != 0) {
+		printk(KERN_DEBUG
+		       "%s: abs[%02x] minimum must be 0\n",
+		       UINPUT_NAME, code);
+		return -EINVAL;
+	}
+
 	if ((min != 0 || max != 0) && max < min) {
 		printk(KERN_DEBUG
 		       "%s: invalid abs[%02x] min:%d max:%d\n",
@@ -524,7 +531,7 @@ static int uinput_abs_setup(struct uinput_device *udev,
 		return -EFAULT;
 
 	if (setup.code > ABS_MAX)
-		return -ERANGE;
+		return -EINVAL;
 
 	dev = udev->dev;
 
-- 
2.43.0

Re: [PATCH v1 2/2] Input: uinput: align UI_ABS_SETUP validation with uapi docs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Adding a strict minimum == 0 validation for ABS_MT_SLOT breaks backward compatibility by rejecting previously accepted configurations.
--

commit 12ce67adcfd7a78984b09163e522a86103b65a3c
Author: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com>

Input: uinput: align UI_ABS_SETUP validation with uapi docs

This commit updates uinput to align with UAPI documentation by returning
-EINVAL for out-of-range axis codes. It also adds a strict validation check
to reject ABS_MT_SLOT configurations if the minimum value is not zero.

> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index d32fa4b508fc5..e05c80182252d 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -424,6 +424,13 @@ static int uinput_validate_absinfo(struct input_dev *dev, unsigned int code,
>  	min = abs->minimum;
>  	max = abs->maximum;
>  
> +	if (code == ABS_MT_SLOT && min != 0) {
> +		printk(KERN_DEBUG
> +		       "%s: abs[%02x] minimum must be 0\n",
> +		       UINPUT_NAME, code);
> +		return -EINVAL;
> +	}

[Severity: Critical]
Does adding this strict validation break backward compatibility for existing
userspace applications? 

Applications that historically passed non-zero minimum values for ABS_MT_SLOT
(which the kernel silently accepted and later clamped to 0) will now fail to
initialize uinput devices, receiving -EINVAL during the UI_ABS_SETUP ioctl.
This introduces a userspace regression by rejecting previously accepted 
configurations.

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831152156.166514-1-ivanrwcm25@gmail.com?part=2

[PATCH v2 0/2] Input: evdev/uinput errno alignment

[Iván Ezequiel Rodriguez]

Two small fixes making evdev and uinput report the error codes their
uapi documentation promises.

Changes since v1:
 - Dropped the ABS_MT_SLOT "minimum must be 0" validation from patch 2.
   It was a userspace regression: uinput_create_device() already calls
   input_mt_init_slots() for devices declaring ABS_MT_SLOT, and
   input_mt_init_slots() overwrites the axis with
   input_set_abs_params(dev, ABS_MT_SLOT, 0, num_slots - 1, 0, 0).
   A non-zero minimum is therefore accepted today and silently
   corrected, so rejecting it with -EINVAL would break existing
   callers.
 - Patch 2 is now limited to the -ERANGE to -EINVAL change and its
   commit message was reworded accordingly.
 - Patch 1 is unchanged.

v1: https://lore.kernel.org/linux-input/20260831152156.166514-1-ivanrwcm25@gmail.com/

Iván Ezequiel Rodriguez (2):
  Input: evdev: propagate EVIOCSFF copy errors correctly
  Input: uinput: return -EINVAL for out-of-range UI_ABS_SETUP axis code

 drivers/input/evdev.c       | 5 +++--
 drivers/input/misc/uinput.c | 2 +-
 2 files changed, 4 insertions(+), 3 deletions(-)

-- 
2.43.0

[PATCH v2 1/2] Input: evdev: propagate EVIOCSFF copy errors correctly

[Iván Ezequiel Rodriguez]

Return the error from input_ff_effect_from_user() instead of always
mapping failures to -EFAULT, so wrong buffer sizes surface as -EINVAL.

Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com>
---
 drivers/input/evdev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index 3a718d600006..27bcf4f099be 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -1180,8 +1180,9 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
 		return str_to_user(dev->uniq, size, p);
 
 	case EVIOC_MASK_SIZE(EVIOCSFF):
-		if (input_ff_effect_from_user(p, size, &effect))
-			return -EFAULT;
+		error = input_ff_effect_from_user(p, size, &effect);
+		if (error)
+			return error;
 
 		error = input_ff_upload(dev, &effect, file);
 		if (error)
-- 
2.43.0

Re: [PATCH v2 1/2] Input: evdev: propagate EVIOCSFF copy errors correctly

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] This problem wasn't introduced by this patch, but an Information Leak exists: Uninitialized kernel stack bytes from `struct ff_effect effect` are leaked to userspace.
--

commit bf36b6bd42a34ab4fa65c08221f5186ae11a4eac
Author: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com>

Input: evdev: propagate EVIOCSFF copy errors correctly

This commit updates evdev_do_ioctl() to return the actual error code from
input_ff_effect_from_user(), rather than always returning -EFAULT. This
ensures that incorrect buffer sizes correctly surface as -EINVAL.

> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index c7325226cb866..405d43f840f3e 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -1175,8 +1175,9 @@ static long evdev_do_ioctl(struct file *file, unsigned int cmd,
>  		return str_to_user(dev->uniq, size, p);
>  
>  	case EVIOC_MASK_SIZE(EVIOCSFF):
> -		if (input_ff_effect_from_user(p, size, &effect))
> -			return -EFAULT;
> +		error = input_ff_effect_from_user(p, size, &effect);
> +		if (error)
> +			return error;

[Severity: Critical]
This is a pre-existing issue, but could this leak uninitialized stack
memory to userspace?

In evdev_do_ioctl(), the 48-byte effect structure is declared uninitialized
on the stack:

drivers/input/evdev.c:evdev_do_ioctl() {
    ...
    struct ff_effect effect;
    ...
}

If a 32-bit compat application calls the EVIOCSFF ioctl,
input_ff_effect_from_user() in compat mode copies only 44 bytes from
userspace into this structure:

drivers/input/input-compat.c:input_ff_effect_from_user() {
    ...
		compat_effect = (struct ff_effect_compat *)effect;

		if (copy_from_user(compat_effect, buffer,
				   sizeof(struct ff_effect_compat)))
    ...
}

This leaves the trailing 4 bytes of kernel stack memory in the effect
structure uninitialized.

The full 48-byte structure, including the uninitialized stack bytes, is
then copied into driver storage by input_ff_upload():

drivers/input/ff-core.c:input_ff_upload() {
    ...
		ff->effects[id] = *effect;
    ...
}

If the device is managed by uinput, a 64-bit userspace daemon handling
the virtual device can read the full 48-byte structure, capturing the
uninitialized kernel stack bytes and leaking them to userspace:

drivers/input/misc/uinput.c:uinput_ioctl_handler() {
    ...
		ff_up.effect = *req->u.upload.effect;
    ...
}

Could we initialize struct ff_effect effect to zero in evdev_do_ioctl()
to prevent this information leak?

>  
>  		error = input_ff_upload(dev, &effect, file);
>  		if (error)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831152156.166514-1-ivanrwcm25@gmail.com?part=1

[PATCH v2 2/2] Input: uinput: return -EINVAL for out-of-range UI_ABS_SETUP axis code

[Iván Ezequiel Rodriguez]

uinput_abs_setup() rejects an axis code above ABS_MAX with -ERANGE, but
the UI_ABS_SETUP documentation in include/uapi/linux/uinput.h states the
ioctl may only fail with -EINVAL, -ENOMEM or -EFAULT. An out-of-range
code is exactly the "incorrect values" case described there, and every
other validation failure in this path already returns -EINVAL.

Return -EINVAL so the code matches its documented uapi contract.

Signed-off-by: Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com>
---
 drivers/input/misc/uinput.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index d32fa4b508fc..7d6266c2bd84 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -524,7 +524,7 @@ static int uinput_abs_setup(struct uinput_device *udev,
 		return -EFAULT;
 
 	if (setup.code > ABS_MAX)
-		return -ERANGE;
+		return -EINVAL;
 
 	dev = udev->dev;
 
-- 
2.43.0