From: sashiko-bot@kernel.org
To: "Can Peng" <pengcan@kylinos.cn>
Cc: linux-hyperv@vger.kernel.org
Subject: Re: [PATCH] drivers: hv: use kmalloc_array in mshv_root_scheduler_init
Date: Wed, 20 May 2026 07:55:47 +0000 [thread overview]
Message-ID: <20260520075548.08C7E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260520071632.557990-1-pengcan@kylinos.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] A CPU hotplug offline operation can lead to a NULL pointer dereference in `mshv_vp_dispatch` because user tasks can still execute on the offlining CPU after the per-CPU buffers have been freed.
--
commit 182b63fe189dbbf1da723a03d972eaa7cbb71f56
Author: Can Peng <pengcan@kylinos.cn>
drivers: hv: use kmalloc_array in mshv_root_scheduler_init
Replace kmalloc() with kmalloc_array() to prevent potential overflow, as
recommended in Documentation/process/deprecated.rst.
> diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
> index bd1359eb58dd4..146726cc4e9ba 100644
> --- a/drivers/hv/mshv_root_main.c
> +++ b/drivers/hv/mshv_root_main.c
> @@ -2241,7 +2241,7 @@ static int mshv_root_scheduler_init(unsigned int cpu)
> outputarg = (void **)this_cpu_ptr(root_scheduler_output);
>
> /* Allocate two consecutive pages. One for input, one for output. */
> - p = kmalloc(2 * HV_HYP_PAGE_SIZE, GFP_KERNEL);
> + p = kmalloc_array(2, HV_HYP_PAGE_SIZE, GFP_KERNEL);
^^^^^^^^^^^^^
[Severity: High]
This isn't a bug introduced by this patch, but is there a pre-existing
issue where a CPU hotplug offline operation can lead to a NULL pointer
dereference in mshv_vp_dispatch()?
The CPU hotplug teardown callback mshv_root_scheduler_cleanup() is registered
at CPUHP_AP_ONLINE_DYN. During a CPU offline operation, it frees the per-CPU
buffers and sets the pointers to NULL:
drivers/hv/mshv_root_main.c:mshv_root_scheduler_cleanup() {
...
*inputarg = NULL;
*outputarg = NULL;
...
}
User tasks can still execute on the offlining CPU at this high state in
the offline sequence. If a vCPU thread scheduled on the offlining CPU invokes
mshv_vp_dispatch() after the teardown callback has run, it unconditionally
dereferences the input buffer:
drivers/hv/mshv_root_main.c:mshv_vp_dispatch() {
...
preempt_disable();
input = *this_cpu_ptr(root_scheduler_input);
...
memset(input, 0, sizeof(*input));
...
}
Does this sequence result in a NULL pointer dereference if the input buffer
pointer has already been cleared by the cleanup callback?
> if (!p)
> return -ENOMEM;
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260520071632.557990-1-pengcan@kylinos.cn?part=1
next prev parent reply other threads:[~2026-05-20 7:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-20 7:16 [PATCH] drivers: hv: use kmalloc_array in mshv_root_scheduler_init Can Peng
2026-05-20 7:55 ` sashiko-bot [this message]
2026-05-27 22:27 ` Wei Liu
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=20260520075548.08C7E1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=pengcan@kylinos.cn \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox