Re: [PATCH] Drivers: hv: vmbus: Fix variable assignments in hv_ringbuffer_read()
From: Stephen Hemminger <stephen@networkplumber.org>
Date: 2020-07-24 17:10:58
Also in:
lkml
On Fri, 24 Jul 2020 09:46:06 -0700 "Andres Beltran" [off-list ref] wrote:
quoted hunk ↗ jump to hunk
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 <redacted> --- 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.