[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGpZZ6ugh-SprR=oMkktEVuEJvNrK06TLqgskey0JkCdZCmvMA@mail.gmail.com>
Date: Fri, 24 Jul 2020 19:04:27 -0400
From: Andres Beltran <lkmlabelt@...il.com>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: KY Srinivasan <kys@...rosoft.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Wei Liu <wei.liu@...nel.org>, linux-hyperv@...r.kernel.org,
linux-kernel@...r.kernel.org,
Michael Kelley <mikelley@...rosoft.com>,
Andrea Parri <parri.andrea@...il.com>,
Saruhan Karademir <skarade@...rosoft.com>
Subject: Re: [PATCH] Drivers: hv: vmbus: Fix variable assignments in hv_ringbuffer_read()
On Fri, Jul 24, 2020 at 1:10 PM Stephen Hemminger
<stephen@...workplumber.org> wrote:
> 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.
>
The rationale for the change was to solve instances like the one
@Haiyang Zhang pointed out, especially in hv_utils, which needs
additional hardening. Unfortunately, there is an instance in
hv_pci_onchannelcallback() that does what you just described. Thus,
the fix will have to be made to all the callers of vmbus_recvpacket()
and vmbus_recvpacket_raw() to make sure they check the return value,
which most callers are not doing now. Thanks for pointing out this
behavior. I was not aware that the length can be checked by callers to
allocate a bigger buffer.
Powered by blists - more mailing lists