Message ID | 20210727205855.411487-25-keescook@chromium.org (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | Introduce strict memcpy() bounds checking | expand |
Context | Check | Description |
---|---|---|
netdev/tree_selection | success | Guessing tree name failed - patch did not apply |
On Tue, Jul 27, 2021 at 01:58:15PM -0700, Kees Cook wrote: > In preparation for FORTIFY_SOURCE performing compile-time and run-time > field bounds checking for memcpy(), memmove(), and memset(), avoid > intentionally writing across neighboring fields. > > Use struct_group() in struct hfa384x_tx_frame around members > frame_control, duration_id, address[1-4], and sequence_control, so they > can be referenced together. This will allow memcpy() and sizeof() to > more easily reason about sizes, improve readability, and avoid future > warnings about writing beyond the end of frame_control. > > "pahole" shows no size nor member offset changes to struct > hfa384x_tx_frame. "objdump -d" shows no meaningful object code changes > (i.e. only source line number induced differences.) > > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > drivers/staging/wlan-ng/hfa384x.h | 16 +++++++++------- > drivers/staging/wlan-ng/hfa384x_usb.c | 4 +++- > 2 files changed, 12 insertions(+), 8 deletions(-) Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
diff --git a/drivers/staging/wlan-ng/hfa384x.h b/drivers/staging/wlan-ng/hfa384x.h index 88e894dd3568..87eb87e3beab 100644 --- a/drivers/staging/wlan-ng/hfa384x.h +++ b/drivers/staging/wlan-ng/hfa384x.h @@ -476,13 +476,15 @@ struct hfa384x_tx_frame { /*-- 802.11 Header Information --*/ - u16 frame_control; - u16 duration_id; - u8 address1[6]; - u8 address2[6]; - u8 address3[6]; - u16 sequence_control; - u8 address4[6]; + struct_group(p80211, + u16 frame_control; + u16 duration_id; + u8 address1[6]; + u8 address2[6]; + u8 address3[6]; + u16 sequence_control; + u8 address4[6]; + ); __le16 data_len; /* little endian format */ /*-- 802.3 Header Information --*/ diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c b/drivers/staging/wlan-ng/hfa384x_usb.c index f2a0e16b0318..38aaae7a2d69 100644 --- a/drivers/staging/wlan-ng/hfa384x_usb.c +++ b/drivers/staging/wlan-ng/hfa384x_usb.c @@ -2516,7 +2516,9 @@ int hfa384x_drvr_txframe(struct hfa384x *hw, struct sk_buff *skb, cpu_to_le16s(&hw->txbuff.txfrm.desc.tx_control); /* copy the header over to the txdesc */ - memcpy(&hw->txbuff.txfrm.desc.frame_control, p80211_hdr, + BUILD_BUG_ON(sizeof(hw->txbuff.txfrm.desc.p80211) != + sizeof(union p80211_hdr)); + memcpy(&hw->txbuff.txfrm.desc.p80211, p80211_hdr, sizeof(union p80211_hdr)); /* if we're using host WEP, increase size by IV+ICV */
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use struct_group() in struct hfa384x_tx_frame around members frame_control, duration_id, address[1-4], and sequence_control, so they can be referenced together. This will allow memcpy() and sizeof() to more easily reason about sizes, improve readability, and avoid future warnings about writing beyond the end of frame_control. "pahole" shows no size nor member offset changes to struct hfa384x_tx_frame. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences.) Signed-off-by: Kees Cook <keescook@chromium.org> --- drivers/staging/wlan-ng/hfa384x.h | 16 +++++++++------- drivers/staging/wlan-ng/hfa384x_usb.c | 4 +++- 2 files changed, 12 insertions(+), 8 deletions(-)