From: sashiko-bot@kernel.org
To: "Hongling Zeng" <zenghongling@kylinos.cn>
Cc: linux-i3c@lists.infradead.org, Frank.Li@kernel.org,
"Alexandre Belloni" <alexandre.belloni@bootlin.com>
Subject: Re: [PATCH] i3c: fix potential NULL dereference in send_ccc_cmd_locked
Date: Tue, 28 Jul 2026 06:46:36 +0000 [thread overview]
Message-ID: <20260728064637.4C2F91F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260728063045.73473-1-zenghongling@kylinos.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [Medium] This problem wasn't introduced by this patch, but the patch provides an incomplete fix for a theoretical NULL pointer dereference, leaving an identical dereference unhandled on the success path.
--
--- Patch [1]: [PATCH] i3c: fix potential NULL dereference in send_ccc_cmd_locked ---
commit e29455a4616608ee623e301c945a087b370f698f
Author: Hongling Zeng <zenghongling@kylinos.cn>
i3c: fix potential NULL dereference in send_ccc_cmd_locked
This patch restricts resetting the payload actual_len to DIRECT commands
to avoid a potential NULL pointer dereference for broadcast commands with
NULL dests and ndests > 0.
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
> @@ -1051,7 +1051,7 @@ static int i3c_master_send_ccc_cmd_locked(struct i3c_master_controller *master,
> for (attempt = 0; attempt < max_attempts; attempt++) {
> unsigned int i;
>
> - if (cmd->rnw)
> + if (cmd->rnw && (cmd->id & I3C_CCC_DIRECT))
> for (i = 0; i < cmd->ndests; i++)
> cmd->dests[i].payload.actual_len = 0;
>
> cmd->err = I3C_ERROR_UNKNOWN;
> ret = master->ops->send_ccc_cmd(master, cmd);
> if (!ret && cmd->err == I3C_ERROR_UNKNOWN)
> break;
> }
>
> if (!ret)
> ret = i3c_ccc_validate_payload_len(cmd);
[Severity: Medium]
This is a pre-existing issue, but does this patch leave an identical NULL
pointer dereference unhandled on the success path?
If a broadcast command (where I3C_CCC_DIRECT is not set) with cmd->rnw true
and cmd->dests == NULL succeeds, the retry loop above is now safe. However,
execution proceeds to i3c_ccc_validate_payload_len():
drivers/i3c/master.c:i3c_ccc_validate_payload_len() {
if (!cmd->rnw)
return 0;
for (i = 0; i < cmd->ndests; i++) {
struct i3c_ccc_cmd_payload *p = &cmd->dests[i].payload;
...
}
Will this result in the exact same crash when evaluating
cmd->dests[i].payload?
Also, earlier in i3c_master_send_ccc_cmd_locked():
if ((cmd->id & I3C_CCC_DIRECT) && (!cmd->dests || !cmd->ndests))
return -EINVAL;
This early validation check only enforces cmd->dests != NULL for DIRECT
commands. Could this be updated to reject any command where cmd->dests is
NULL but cmd->ndests > 0, rather than patching individual dereferences?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260728063045.73473-1-zenghongling@kylinos.cn?part=1
--
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c
next prev parent reply other threads:[~2026-07-28 6:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 6:30 [PATCH] i3c: fix potential NULL dereference in send_ccc_cmd_locked Hongling Zeng
2026-07-28 6:46 ` sashiko-bot [this message]
2026-07-28 10:27 ` Mukesh Savaliya
2026-07-30 2:31 ` Hongling Zeng
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=20260728064637.4C2F91F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-i3c@lists.infradead.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=zenghongling@kylinos.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox