Re: [PATCH v10 7/8] iio: osf: add core KUnit tests

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] kunit: UAF in osf_session_producer due to missing kthread lifecycle action
- [Medium] kunit: mutex re-initialization in osf_test_new_session
--

commit b82aa72688edb8c728c31226b6fec70af9389122
Author: Jinseob Kim <kimjinseob88@gmail.com>

iio: osf: add core KUnit tests

This commit adds core regression test cases for frame handling, sample-cache
admission, and other operations for the Open Sensor Fusion IIO device.
It introduces KUnit configuration and build wiring to exercise these paths.

> diff --git a/drivers/iio/opensensorfusion/osf_core_test.c b/drivers/iio/opensensorfusion/osf_core_test.c
> new file mode 100644
> index 0000000000000..d96753ab2a458
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/osf_core_test.c

[ ... ]

> +static void osf_test_new_session(struct osf_test_context *ctx)
> +{
> +	osf_test_cleanup(ctx);
> +	osf_core_init(&ctx->osf, ctx->dev);

[Severity: Medium]
Does this code trigger a debugobjects warning by re-initializing an active
mutex?

osf_core_init() performs the following operations:

drivers/iio/opensensorfusion/osf_core.c:osf_core_init() {
	*osf = (struct osf_device) {
		.dev = dev,
	};
	mutex_init(&osf->latest_lock);
}

By wiping the osf_device structure and calling mutex_init() again on
latest_lock without first calling mutex_destroy(), this can cause debugobjects
to emit an init active warning.

Could a cleanup of the old mutex be added, or the re-initialization avoided?

> +	osf_core_start(&ctx->osf);
> +	ctx->indio_dev = NULL;
> +	ctx->buffer = NULL;
> +}

[ ... ]

> +static void osf_session_fault_buffer_race_test(struct kunit *test)
> +{
> +	struct osf_test_context *ctx = test->priv;

[ ... ]

> +	producer = kthread_run(osf_session_producer, race, "osf-session-test");
> +	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, producer);

[Severity: Medium]
Can this kthread leak and cause a use-after-free if the KUnit test is aborted
prematurely?

If the test is aborted due to a KUnit timeout or an unhandled signal, the
manual kthread_stop() at the end of the test will be bypassed. The KUnit
framework will then free the race structure, but osf_session_producer will
continue running in the background.

When the background thread subsequently accesses race->rx_lock or race->ctx,
it will access freed memory and potentially crash the kernel.

Could kunit_add_action() be used to guarantee the termination of the kthread
during test cleanup?

> +	KUNIT_EXPECT_NE(test, wait_for_completion_timeout(&race->started, HZ), 0UL);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1789753020.git.kimjinseob88@gmail.com?part=7