On Fri, 24 Jul 2020 09:46:06 -0700 "Andres Beltran" <lkmlabelt@xxxxxxxxx> 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@xxxxxxxxx> > --- > 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.
