Re: [PATCH 2/2] Input: test state seeding across device registration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] input: missing absinfo allocation check in input_set_abs_params causes NULL pointer dereference
- [Medium] input: dangling pointer match in test teardown allows accidental binding to unrelated devices
--

commit 2e31a0267a25d47a7a2da67f7fbb5534d7ebbae1
Author: Karlos Abel <kabel@voidship.net>

Input: test state seeding across device registration

This commit adds KUnit coverage for input events used to initialize device
state before registration. It exercises both original event buffers and larger
resizing buffers, verifying the correct retention and delivery of states.

> diff --git a/drivers/input/tests/input_test.c b/drivers/input/tests/input_test.c
> index e105ce71a920a..889d9e7ec922f 100644
> --- a/drivers/input/tests/input_test.c
> +++ b/drivers/input/tests/input_test.c
[ ... ]
> @@ -161,11 +161,179 @@ static void input_test_grab(struct kunit *test)
[ ... ]
> +static bool input_seed_match(struct input_handler *handler,
> +			     struct input_dev *dev)
> +{
> +	struct input_seed_test *seed = container_of(handler, struct input_seed_test,
> +						  handler);
> +
> +	return seed->dev == dev;
> +}
[ ... ]
> +	/* An ABS axis also raises the estimated event-buffer size. */
> +	if (resize) {
> +		input_set_abs_params(seed->dev, ABS_X, 0, 100, 0, 0);
> +		seed->dev->hint_events_per_packet = 128;
> +	}

[Severity: High]
Does this code risk a NULL pointer dereference if the internal allocation
for `absinfo` fails?

Functions like `input_set_abs_params()` set `EV_ABS` in `dev->evbit` and the
specific axis in `dev->absbit` before calling `input_alloc_absinfo()`. If this
allocation fails (e.g., due to memory pressure), they return silently, leaving
the capability bits permanently set while `dev->absinfo` remains NULL.

[ ... ]
> +	/* Initialize state before registration, without a SYN_REPORT. */
> +	input_set_timestamp(seed->dev, seed_timestamp);
> +	input_report_switch(seed->dev, SW_DOCK, 1);
> +	if (resize)
> +		input_report_abs(seed->dev, ABS_X, 42);

Because this test explicitly relies on seeding initial absolute axis state via
`input_report_abs()` before registration, if the allocation failed during
`input_set_abs_params()`, this subsequent event injection causes
`input_handle_abs_event()` to unconditionally dereference
`dev->absinfo[code].value`. This results in a NULL pointer dereference
regression before the delayed missing-absinfo check in
`input_register_device()` can catch it.

Should the failure state of `input_set_abs_params()` be checked here, or
should `input_alloc_absinfo()` be verified to have succeeded before
continuing?

[ ... ]
> +unregister_device:
> +	input_unregister_device(seed->dev);
> +	input_unregister_handler(&seed->handler);

[Severity: Medium]
Can this sequence lead to a use-after-free regression and accidental binding
to unrelated devices?

In this teardown path of `input_test_seed_events()`,
`input_unregister_device()` is called before `input_unregister_handler()`.
For a non-devres device, unregistering calls `input_put_device()`, dropping
the final reference and immediately freeing the device memory. However, the
custom test handler remains on the global `input_handler_list`.

If another input device registers concurrently during this window, the input
core iterates all handlers and calls `input_seed_match()`. This function
evaluates `seed->dev == dev` using the freed memory. If the slab allocator
reused that exact memory address for the newly registered device, the match
will incorrectly return true, and the test handler will erroneously attempt
to bind to the unrelated device.

Should `input_unregister_handler()` be called before
`input_unregister_device()` to avoid this race condition?

> +	return;
> +
> +unregister_handler:
> +	input_unregister_handler(&seed->handler);
> +free_device:
> +	input_free_device(seed->dev);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010180031.7-1-kabel@voidship.net?part=2