[PATCH] staging: vt6655: fix potential memory conruption bug

[PATCH] staging: vt6655: fix potential memory conruption bug

[Nam Cao]

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

Re: [PATCH] staging: vt6655: fix potential memory conruption bug

[Greg KH]

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

Re: [PATCH] staging: vt6655: fix potential memory conruption bug

[Nam Cao]

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

Re: [PATCH] staging: vt6655: fix potential memory conruption bug

[Greg KH]

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