Re: [PATCH] Input: maplemouse - fix NULL pointer dereference in open()

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Initialization of maple bus driver data occurs after exposing the input device to userspace, leading to a potential NULL pointer dereference.
- [High] Teardown asymmetry causes a race condition where a background callback is inadvertently re-armed during device removal, leading to UAF or NULL pointer dereference.
--

commit 5babe5754528798c9e3476330c1a7834fe83388a
Author: Florian Fuchs <fuchsfl@gmail.com>

Input: maplemouse - fix NULL pointer dereference in open()

Commit 555c765b0cc2 dropped the input_set_drvdata() call in probe, which
caused a NULL pointer dereference in open() because maple_get_drvdata()
was still being used. This patch restores input_set_drvdata() and
converts open() and close() to use input_get_drvdata().

> diff --git a/drivers/input/mouse/maplemouse.c b/drivers/input/mouse/maplemouse.c
> index c99f7e2342191..c41182766538a 100644
> --- a/drivers/input/mouse/maplemouse.c
> +++ b/drivers/input/mouse/maplemouse.c

[ ... ]

> @@ -58,7 +58,7 @@ static int dc_mouse_open(struct input_dev *dev)
>  
>  static void dc_mouse_close(struct input_dev *dev)
>  {
> -	struct dc_mouse *mse = maple_get_drvdata(to_maple_dev(&dev->dev));
> +	struct dc_mouse *mse = input_get_drvdata(dev);
>  
>  	maple_getcond_callback(mse->mdev, dc_mouse_callback, 0,
>  		MAPLE_FUNC_MOUSE);
>  }

[Severity: High]
This is a pre-existing issue, but does calling maple_getcond_callback() here
create a race condition during device removal?

During removal, remove_maple_mouse() clears the callback before unregistering
the device:

drivers/input/mouse/maplemouse.c:remove_maple_mouse() {
	...
	mdev->callback = NULL;
	input_unregister_device(mse->dev);
	...
}

If the device is open, input_unregister_device() synchronously calls
dc_mouse_close(). This unconditionally calls maple_getcond_callback(), which
re-arms mdev->callback back to dc_mouse_callback.

After input_unregister_device() returns, remove_maple_mouse() clears the
driver data and frees mse. If a delayed maple bus packet arrives after this,
dc_mouse_callback() will execute and attempt to use a freed mse pointer or a
NULL driver data pointer, causing a kernel panic.

Would it be safer to avoid re-arming the callback if the device is being
removed?

[ ... ]

> @@ -88,6 +88,7 @@ static int probe_maple_mouse(struct device *dev)
>  	mse->dev = input_dev;
>  	mse->mdev = mdev;
>  
> +	input_set_drvdata(input_dev, mse);
>  	input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REL);
>  	input_dev->keybit[BIT_WORD(BTN_MOUSE)] = BIT_MASK(BTN_LEFT) |
>  		BIT_MASK(BTN_RIGHT) | BIT_MASK(BTN_MIDDLE);

[Severity: High]
This is a pre-existing issue, but is it possible for a callback to fire
before driver data is fully initialized?

Later in probe_maple_mouse(), the device is registered:

drivers/input/mouse/maplemouse.c:probe_maple_mouse() {
	...
	error = input_register_device(input_dev);
	if (error)
		goto fail_register;

	mdev->driver = mdrv;
	maple_set_drvdata(mdev, mse);
	...
}

If userspace immediately opens the device upon registration, dc_mouse_open()
will schedule dc_mouse_callback(). If the callback executes before
maple_set_drvdata() completes, maple_get_drvdata(mapledev) inside the
callback will return NULL, leading to a NULL pointer dereference when
accessing mse->dev.

Could the maple_set_drvdata() call be moved before input_register_device()
to prevent this?

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