From: Stephen Hemminger <stephen@networkplumber.org>
To: "Andres Beltran" <lkmlabelt@gmail.com>
Cc: "KY Srinivasan" <kys@microsoft.com>,
"Haiyang Zhang" <haiyangz@microsoft.com>,
"Stephen Hemminger" <sthemmin@microsoft.com>,
<wei.liu@kernel.org>, <linux-hyperv@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
"Michael Kelley" <mikelley@microsoft.com>,
<parri.andrea@gmail.com>,
"Saruhan Karademir" <skarade@microsoft.com>
Subject: Re: [PATCH] Drivers: hv: vmbus: Fix variable assignments in hv_ringbuffer_read()
Date: Fri, 24 Jul 2020 10:10:47 -0700 [thread overview]
Message-ID: <20200724101047.34de7e49@hermes.lan> (raw)
In-Reply-To: <20200724164606.43699-1-lkmlabelt@gmail.com>
On Fri, 24 Jul 2020 09:46:06 -0700
"Andres Beltran" <lkmlabelt@gmail.com> wrote:
> Assignments to buffer_actual_len and requestid happen before packetlen
> is checked to be within buflen. If this condition is true,
> hv_ringbuffer_read() returns with these variables already set to some
> value even though no data is actually read. This might create
> inconsistencies in any routine calling hv_ringbuffer_read(). Assign values
> to such pointers after the packetlen check.
>
> Signed-off-by: Andres Beltran <lkmlabelt@gmail.com>
> ---
> drivers/hv/ring_buffer.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c
> index 356e22159e83..e277ce7372a4 100644
> --- a/drivers/hv/ring_buffer.c
> +++ b/drivers/hv/ring_buffer.c
> @@ -350,12 +350,13 @@ int hv_ringbuffer_read(struct vmbus_channel
> *channel,
>
> offset = raw ? 0 : (desc->offset8 << 3);
> packetlen = (desc->len8 << 3) - offset;
> - *buffer_actual_len = packetlen;
> - *requestid = desc->trans_id;
>
> if (unlikely(packetlen > buflen))
> return -ENOBUFS;
>
> + *buffer_actual_len = packetlen;
> + *requestid = desc->trans_id;
> +
> /* since ring is double mapped, only one copy is necessary */
> memcpy(buffer, (const char *)desc + offset, packetlen);
>
What is the rationale for this change, it may break other code.
A common API model in Windows world where this originated
is to have a call where caller first
makes request and then if the requested buffer is not big enough the
caller look at the actual length and allocate a bigger buffer.
Did you audit all the users of this API to make sure they aren't doing that.
next prev parent reply other threads:[~2020-07-24 17:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-24 16:46 [PATCH] Drivers: hv: vmbus: Fix variable assignments in hv_ringbuffer_read() Andres Beltran
2020-07-24 17:10 ` Stephen Hemminger [this message]
2020-07-24 17:48 ` Haiyang Zhang
2020-07-24 23:04 ` Andres Beltran
2020-07-26 23:53 ` Haiyang Zhang
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=20200724101047.34de7e49@hermes.lan \
--to=stephen@networkplumber.org \
--cc=haiyangz@microsoft.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmlabelt@gmail.com \
--cc=mikelley@microsoft.com \
--cc=parri.andrea@gmail.com \
--cc=skarade@microsoft.com \
--cc=sthemmin@microsoft.com \
--cc=wei.liu@kernel.org \
/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.