drivers/staging/vt6655/device_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
A line of code is attempting to set the entire struct vnt_rdes0 to
zero by treating it as unsigned int. However, this only works if
sizeof(unsigned int) is equal to sizeof(struct vnt_rdes0) (4 bytes),
which is not guaranteed. This may cause memory conruption if
sizeof(unsigned int) is 8 bytes for example. Fix the problem by using
memset instead.
Signed-off-by: Nam Cao <namcaov@gmail.com>
---
drivers/staging/vt6655/device_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/vt6655/device_main.c b/drivers/staging/vt6655/device_main.c
index 8e2a976aaaad..a38657769c20 100644
--- a/drivers/staging/vt6655/device_main.c
+++ b/drivers/staging/vt6655/device_main.c
@@ -867,7 +867,7 @@ static bool device_alloc_rx_buf(struct vnt_private *priv,
return false;
}
- *((unsigned int *)&rd->rd0) = 0; /* FIX cast */
+ memset((void *)&rd->rd0, 0, sizeof(rd->rd0));
rd->rd0.res_count = cpu_to_le16(priv->rx_buf_sz);
rd->rd0.owner = OWNED_BY_NIC;
--
2.25.1
On Fri, Sep 09, 2022 at 07:30:39AM +0200, Nam Cao wrote: > A line of code is attempting to set the entire struct vnt_rdes0 to > zero by treating it as unsigned int. However, this only works if > sizeof(unsigned int) is equal to sizeof(struct vnt_rdes0) (4 bytes), > which is not guaranteed. This may cause memory conruption if > sizeof(unsigned int) is 8 bytes for example. Fix the problem by using > memset instead. sizeof(unsigned int) is not going to be 8 bytes, so there's no memory issue here. But your fix is good, so can you please just rewrite this to be "make it more obvious what is happening" type of patch? thanks, greg k-h
Hi Greg, Just out of curiosity, how can we be sure that sizeof(unsigned int) is never 8 bytes? The C standard doesn't say anything about this, as far as I know. Patch v2 will come later today or tomorrow. Best regards, Nam On Fri, Sep 9, 2022 at 7:47 AM Greg KH <gregkh@linuxfoundation.org> wrote: > > sizeof(unsigned int) is not going to be 8 bytes, so there's no memory > issue here. But your fix is good, so can you please just rewrite this > to be "make it more obvious what is happening" type of patch? > > thanks, > > greg k-h
A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Fri, Sep 09, 2022 at 08:01:29AM +0200, Nam Cao wrote: > Hi Greg, > > Just out of curiosity, how can we be sure that sizeof(unsigned int) > is never 8 bytes? The C standard doesn't say anything about this, as > far as I know. Do you know of a Linux architecture that this is true? Linux has a few more requirements than C does (i.e. an unsigned long has to hold a pointer) so don't go by the C requirements please. thanks, greg k-h
© 2016 - 2026 Red Hat, Inc.