From: sashiko-bot@kernel.org
To: "Patrick Tudor" <ptudor@ptudor.net>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Olivia Mackall" <olivia@selenic.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>
Cc: devicetree@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH 3/3] hwrng: rng90: add KUnit tests
Date: Sat, 24 Oct 2026 23:22:16 +0000 [thread overview]
Message-ID: <sashiko-outbox-183943@kernel.org> (raw)
In-Reply-To: <20261024-rng90-submit-v1-v1-3-e265cfabc9af@ptudor.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] hwrng: rng90: NULL dereference in rng90_test_exit() if rng90_test_init() fails
--
commit 738c911c8957ee3bcb09ed18f6daa72a41daed79
Author: Patrick Tudor <ptudor@ptudor.net>
hwrng: rng90: add KUnit tests
This commit adds built-in KUnit tests for the RNG90 hardware random number
generator driver using a scripted I2C adapter to exercise command framing,
CRC validation, polling, recovery, health failures, and power management.
> diff --git a/drivers/char/hw_random/rng90-kunit.c b/drivers/char/hw_random/rng90-kunit.c
> new file mode 100644
> index 0000000000000..f6daffb2e3d97
> --- /dev/null
> +++ b/drivers/char/hw_random/rng90-kunit.c
> @@ -0,0 +1,820 @@
[ ... ]
> +static int rng90_test_init(struct kunit *test)
> +{
> + struct rng90_test_context *ctx;
> + int ret;
> +
> + ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
> + if (!ctx)
> + return -ENOMEM;
> + test->priv = ctx;
> + ctx->test = test;
> + ctx->adapter.owner = THIS_MODULE;
> + ctx->adapter.algo = &rng90_test_algorithm;
> + ctx->adapter.algo_data = ctx;
> + strscpy(ctx->adapter.name, "rng90-kunit", sizeof(ctx->adapter.name));
> + ret = i2c_add_adapter(&ctx->adapter);
> + if (ret)
> + return ret;
> + ctx->client = i2c_new_dummy_device(&ctx->adapter, RNG90_ADDRESS);
> + if (IS_ERR(ctx->client)) {
> + ret = PTR_ERR(ctx->client);
> + i2c_del_adapter(&ctx->adapter);
> + return ret;
> + }
> + ctx->priv.client = ctx->client;
> + mutex_init(&ctx->priv.lock);
> + i2c_set_clientdata(ctx->client, &ctx->priv);
> + /* Never register this predictable test source with the hwrng core. */
> + return 0;
> +}
> +
> +/* Verify the script was consumed, allowing a final busy step at the deadline. */
> +static void rng90_test_settled(struct rng90_test_context *ctx)
> +{
> + if (ctx->next < ctx->count &&
> + ctx->steps[ctx->next].repeat == RNG90_TEST_BUSY &&
> + ctx->steps[ctx->next].hits)
> + ctx->next++;
> + KUNIT_EXPECT_EQ(ctx->test, ctx->next, ctx->count);
> +}
> +
> +static void rng90_test_exit(struct kunit *test)
> +{
> + struct rng90_test_context *ctx = test->priv;
> +
> + rng90_test_settled(ctx);
> + i2c_unregister_device(ctx->client);
> + i2c_del_adapter(&ctx->adapter);
> +}
[Severity: Medium]
Can rng90_test_exit() dereference a null pointer or repeat adapter teardown
if rng90_test_init() fails?
In KUnit, kunit_run_case_catch_errors() invokes kunit_try_run_case_cleanup()
-> kunit_run_case_cleanup() -> suite->exit(test) even when suite->init(test)
returns a non-zero error code.
If kunit_kzalloc() fails in rng90_test_init(), test->priv remains NULL, and
rng90_test_exit() will dereference ctx in rng90_test_settled(ctx),
i2c_unregister_device(ctx->client), and i2c_del_adapter(&ctx->adapter).
Additionally, test->priv = ctx is assigned before i2c_add_adapter() and
i2c_new_dummy_device(). If i2c_new_dummy_device() fails, rng90_test_init()
calls i2c_del_adapter(&ctx->adapter) and leaves ctx->client as an error
pointer, after which rng90_test_exit() will run and call
i2c_del_adapter(&ctx->adapter) a second time.
Would it make sense to assign test->priv = ctx only after initialization
succeeds in rng90_test_init(), and check for !ctx in rng90_test_exit() before
cleaning up?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261024-rng90-submit-v1-v1-0-e265cfabc9af@ptudor.net?part=3
prev parent reply other threads:[~2026-10-24 23:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 20:18 [PATCH 0/3] hwrng: add Microchip RNG90 support Patrick Tudor
2026-10-24 20:18 ` [PATCH 1/3] dt-bindings: trivial-devices: add Microchip RNG90 Patrick Tudor
2026-10-26 12:43 ` Krzysztof Kozlowski
2026-10-24 20:18 ` [PATCH 2/3] hwrng: add Microchip RNG90 driver Patrick Tudor
2026-10-24 20:18 ` [PATCH 3/3] hwrng: rng90: add KUnit tests Patrick Tudor
2026-10-24 23:22 ` sashiko-bot [this message]
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=sashiko-outbox-183943@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=krzk+dt@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=olivia@selenic.com \
--cc=ptudor@ptudor.net \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.