All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Richard Fitzgerald" <rf@opensource.cirrus.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v7 3/3] clk: cs2600: Add KUnit test for CS2600 driver
Date: Fri, 07 Aug 2026 16:10:09 +0000	[thread overview]
Message-ID: <20260807161010.DCE571F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807155406.752721-4-rf@opensource.cirrus.com>

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing length validation for read messages in the dummy I2C transfer function allows a heap buffer overflow.
- [Medium] Integer overflow in delta frequency calculation causes improperly strict test failure bounds.
- [Medium] Device node reference leak on KUnit assertion failure.
--

--- Patch [3]: [PATCH v7 3/3] clk: cs2600: Add KUnit test for CS2600 driver ---
commit 2362317ae5c3adcc9e6eb5a18429400bcf90b30f
Author: Richard Fitzgerald <rf@opensource.cirrus.com>

    clk: cs2600: Add KUnit test for CS2600 driver

This commit adds a KUnit test for the CS2600 clock driver using a mock I2C
host driver and regmap. It validates the frequency ratio and PLL
configuration register fields against hardcoded tables of expected settings.

> diff --git a/drivers/clk/cirrus/clk-cs2600-kunit.c b/drivers/clk/cirrus/clk-cs2600-kunit.c
> new file mode 100644
> index 0000000000000..2fd3f3ff4ef3f
> --- /dev/null
> +++ b/drivers/clk/cirrus/clk-cs2600-kunit.c
[ ... ]
> +	for (i = 0; cs2600_kunit_bclk_divs[i].pll_out != 0; i++) {
[ ... ]
> +		/*
> +		 * Actual reported frequency can be slightly out because of
> +		 * PLL resolution, but should be within worst-case PPM.
> +		 */
> +		fdelta = (cs2600_kunit_bclk_divs[i].bf_out * CS2600_20_12_PPM) >> 20;

[Severity: Medium]
Could this 32-bit multiplication overflow for large values of bf_out before
the result is stored in the 64-bit fdelta?

[ ... ]
> +	for (i = 0; cs2600_kunit_fsync_divs[i].pll_out != 0; i++) {
[ ... ]
> +		/*
> +		 * Actual reported frequency can be slightly out because of
> +		 * PLL resolution, but should be within worst-case PPM.
> +		 */
> +		fdelta = (cs2600_kunit_fsync_divs[i].bf_out * CS2600_20_12_PPM) >> 20;

[Severity: Medium]
Does this have the same 32-bit overflow vulnerability as the BCLK divider
calculation above?

[ ... ]
> +	/* If there is a second packet it is a read */
> +	if (num == 2) {
> +		ret = cs2600_kunit_i2c_read(priv, addr, &val);
> +		if (ret < 0)
> +			return ret;
> +
> +		bebuf = (__force __be16 *)msgs[1].buf;
> +		bebuf[0] = cpu_to_be16(val);

[Severity: High]
Could this write out of bounds if the read message length is less than 2
bytes, since msgs[1].len is not validated before the write?

> +
> +		return 2;
> +	}
[ ... ]
> +static int cs2600_kunit_case_common_init(struct kunit *test)
> +{
[ ... ]
> +	/* Wait for probes if the test case init already loaded the overlay */
> +	np = of_find_node_by_name(NULL, "cs2600-test-consumer");
> +	if (!IS_ERR_OR_NULL(np))
> +		cs2600_kunit_wait_for_probes(test);
> +	of_node_put(np);

[Severity: Medium]
If an assertion inside cs2600_kunit_wait_for_probes() fails, the KUnit
framework aborts the test thread. Does this result in a leaked device node
reference since the of_node_put() call would be bypassed?

> +
> +	return 0;
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260807155406.752721-1-rf@opensource.cirrus.com?part=3

      reply	other threads:[~2026-08-07 16:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 15:54 [PATCH v7 0/3] Cirrus Logic CS2600 clock device Richard Fitzgerald
2026-08-07 15:54 ` [PATCH v7 1/3] dt-bindings: clock: cs2600: Add support for the CS2600 Richard Fitzgerald
2026-08-07 15:54 ` [PATCH v7 2/3] clk: cs2600: Add Fractional-N clock driver Richard Fitzgerald
2026-08-07 16:07   ` sashiko-bot
2026-08-07 20:55   ` Uwe Kleine-König
2026-08-07 15:54 ` [PATCH v7 3/3] clk: cs2600: Add KUnit test for CS2600 driver Richard Fitzgerald
2026-08-07 16:10   ` 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=20260807161010.DCE571F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=rf@opensource.cirrus.com \
    --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.