Skip to contentSkip to conversation

wireless: wext-spy: Fix out-of-bounds warning

PATCH In review Gustavo A. R. Silva 4 participants 4 messages Apr 22, 2021

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH v2 1/1 wireless: wext-spy: Fix out-of-bounds warning

Fix the following out-of-bounds warning:

net/wireless/wext-spy.c:178:2: warning: 'memcpy' offset [25, 28] from the object at 'threshold' is out of the bounds of referenced subobject 'low' with type 'struct iw_quality' at offset 20 [-Warray-bounds]

The problem is that the original code is trying to copy data into a couple of struct members adjacent to each other in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &threshold.low and &spydata->spy_thr_low. As these are just a couple of struct members, fix this by using direct assignments, instead of memcpy().

This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy().

---
Changes in v2:
- Use direct struct assignments instead of memcpy().
- Fix one more instance of this same issue in function iw_handler_get_thrspy().
- Update changelog text.
- Add Kees' RB tag.

 net/wireless/wext-spy.c | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)
net/wireless/wext-spy.c +7 -7
index 33bef22e44e9..b379a0371653 100644
@@ -120,8 +120,8 @@ int iw_handler_set_thrspy(struct net_device *	dev,
 		return -EOPNOTSUPP;
 
 	/* Just do it */
-	memcpy(&(spydata->spy_thr_low), &(threshold->low),
-	       2 * sizeof(struct iw_quality));
+	spydata->spy_thr_low = threshold->low;
+	spydata->spy_thr_high = threshold->high;
 
 	/* Clear flag */
 	memset(spydata->spy_thr_under, '\0', sizeof(spydata->spy_thr_under));
@@ -147,8 +147,8 @@ int iw_handler_get_thrspy(struct net_device *	dev,
 		return -EOPNOTSUPP;
 
 	/* Just do it */
-	memcpy(&(threshold->low), &(spydata->spy_thr_low),
-	       2 * sizeof(struct iw_quality));
+	threshold->low = spydata->spy_thr_low;
+	threshold->high = spydata->spy_thr_high;
 
 	return 0;
 }
@@ -173,10 +173,10 @@ static void iw_send_thrspy_event(struct net_device *	dev,
 	memcpy(threshold.addr.sa_data, address, ETH_ALEN);
 	threshold.addr.sa_family = ARPHRD_ETHER;
 	/* Copy stats */
-	memcpy(&(threshold.qual), wstats, sizeof(struct iw_quality));
+	threshold.qual = *wstats;
 	/* Copy also thresholds */
-	memcpy(&(threshold.low), &(spydata->spy_thr_low),
-	       2 * sizeof(struct iw_quality));
+	threshold.low = spydata->spy_thr_low;
+	threshold.high = spydata->spy_thr_high;
 
 	/* Send event to user space */
 	wireless_send_event(dev, SIOCGIWTHRSPY, &wrqu, (char *) &threshold);
Signature · 1 line
2.27.0
maintainer
#1 lore raw
Quoted 6 lines · Gustavo A. R. Silva

Changes in v2:
 - Use direct struct assignments instead of memcpy().
 - Fix one more instance of this same issue in function iw_handler_get_thrspy().
 - Update changelog text.

Thanks.

Quoted 1 line

 - Add Kees' RB tag.

He probably won't mind in this case, but you did some pretty substantial changes to the patch, so I really wouldn't recommend keeping it there.

johannes

#2 lore raw
Quoted 8 lines · Johannes Berg
Quoted 6 lines · Gustavo A. R. Silva

Changes in v2:
 - Use direct struct assignments instead of memcpy().
 - Fix one more instance of this same issue in function iw_handler_get_thrspy().
 - Update changelog text.

Quoted 6 lines

Thanks.

Quoted 1 line

 - Add Kees' RB tag.

He probably won't mind in this case, but you did some pretty substantial changes to the patch, so I really wouldn't recommend keeping it there.

Right.

Kees, could you please confirm you RB tag in this new version?

Thanks
--
Gustavo

Reviewed-by
#3 lore raw
In reply to Johannes Berg
Quoted 8 lines · Johannes Berg
Quoted 6 lines · Gustavo A. R. Silva

Changes in v2:
 - Use direct struct assignments instead of memcpy().
 - Fix one more instance of this same issue in function iw_handler_get_thrspy().
 - Update changelog text.

Quoted 6 lines

Thanks.

Quoted 1 line

 - Add Kees' RB tag.

He probably won't mind in this case, but you did some pretty substantial changes to the patch, so I really wouldn't recommend keeping it there.

Thanks for double-checking! Yeah, I'm fine with it; Gustavo and I had talked in the past about similar solutions in other places, so he forwarded the intent from those conversations. (Not that you had any visibility into that!) But, yes, still:

Thanks!

Signature · 1 line
Kees Cook