lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 18 Aug 2021 14:13:51 +0900 From: Vincent MAILHOL <mailhol.vincent@...adoo.fr> To: Kees Cook <keescook@...omium.org> Cc: Wolfgang Grandegger <wg@...ndegger.com>, Marc Kleine-Budde <mkl@...gutronix.de>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Arunachalam Santhanam <arunachalam.santhanam@...bosch.com>, linux-can <linux-can@...r.kernel.org>, netdev <netdev@...r.kernel.org>, open list <linux-kernel@...r.kernel.org>, linux-hardening@...r.kernel.org Subject: Re: [PATCH] can: etas_es58x: Replace 0-element raw_msg array On Wed. 18 Aug 2021 at 12:40, Kees Cook <keescook@...omium.org> wrote: > While raw_msg isn't a fixed size, it does have a maximum size. Adjust the > struct to represent this and avoid the following warning when building > with -Wzero-length-bounds: > > drivers/net/can/usb/etas_es58x/es58x_fd.c: In function 'es58x_fd_tx_can_msg': > drivers/net/can/usb/etas_es58x/es58x_fd.c:360:35: warning: array subscript 65535 is outside the bounds of an interior zero-length array 'u8[0]' {aka 'unsigned char[]'} [-Wzero-length-bounds] > 360 | tx_can_msg = (typeof(tx_can_msg))&es58x_fd_urb_cmd->raw_msg[msg_len]; > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from drivers/net/can/usb/etas_es58x/es58x_core.h:22, > from drivers/net/can/usb/etas_es58x/es58x_fd.c:17: > drivers/net/can/usb/etas_es58x/es58x_fd.h:231:6: note: while referencing 'raw_msg' > 231 | u8 raw_msg[0]; > | ^~~~~~~ > > Cc: Wolfgang Grandegger <wg@...ndegger.com> > Cc: Marc Kleine-Budde <mkl@...gutronix.de> > Cc: "David S. Miller" <davem@...emloft.net> > Cc: Jakub Kicinski <kuba@...nel.org> > Cc: Arunachalam Santhanam <arunachalam.santhanam@...bosch.com> > Cc: Vincent Mailhol <mailhol.vincent@...adoo.fr> > Cc: linux-can@...r.kernel.org > Cc: netdev@...r.kernel.org > Signed-off-by: Kees Cook <keescook@...omium.org> > --- > drivers/net/can/usb/etas_es58x/es581_4.h | 2 +- > drivers/net/can/usb/etas_es58x/es58x_fd.h | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/can/usb/etas_es58x/es581_4.h b/drivers/net/can/usb/etas_es58x/es581_4.h > index 4bc60a6df697..af38c4938859 100644 > --- a/drivers/net/can/usb/etas_es58x/es581_4.h > +++ b/drivers/net/can/usb/etas_es58x/es581_4.h > @@ -192,7 +192,7 @@ struct es581_4_urb_cmd { > struct es581_4_rx_cmd_ret rx_cmd_ret; > __le64 timestamp; > u8 rx_cmd_ret_u8; > - u8 raw_msg[0]; > + u8 raw_msg[USHRT_MAX]; > } __packed; > > __le16 reserved_for_crc16_do_not_use; > diff --git a/drivers/net/can/usb/etas_es58x/es58x_fd.h b/drivers/net/can/usb/etas_es58x/es58x_fd.h > index ee18a87e40c0..e0319b8358ef 100644 > --- a/drivers/net/can/usb/etas_es58x/es58x_fd.h > +++ b/drivers/net/can/usb/etas_es58x/es58x_fd.h > @@ -228,7 +228,7 @@ struct es58x_fd_urb_cmd { > struct es58x_fd_tx_ack_msg tx_ack_msg; > __le64 timestamp; > __le32 rx_cmd_ret_le32; > - u8 raw_msg[0]; > + u8 raw_msg[USHRT_MAX]; > } __packed; > > __le16 reserved_for_crc16_do_not_use; > -- > 2.30.2 raw_msg is part of a union so its maximum size is implicitly the biggest size of the other member of that union: | struct es58x_fd_urb_cmd { | __le16 SOF; | u8 cmd_type; | u8 cmd_id; | u8 channel_idx; | __le16 msg_len; | | union { | struct es58x_fd_tx_conf_msg tx_conf_msg; | u8 tx_can_msg_buf[ES58X_FD_TX_BULK_MAX * ES58X_FD_CANFD_TX_LEN]; | u8 rx_can_msg_buf[ES58X_FD_RX_BULK_MAX * ES58X_FD_CANFD_RX_LEN]; | struct es58x_fd_echo_msg echo_msg[ES58X_FD_ECHO_BULK_MAX]; | struct es58x_fd_rx_event_msg rx_event_msg; | struct es58x_fd_tx_ack_msg tx_ack_msg; | __le64 timestamp; | __le32 rx_cmd_ret_le32; | u8 raw_msg[0]; | } __packed; | | __le16 reserved_for_crc16_do_not_use; | } __packed; ram_msg can then be used to manipulate the other fields at the byte level. I am sorry but I fail to understand why this is an issue. Also, the proposed fix drastically increases the size of the structure. Yours sincerely, Vincent
Powered by blists - more mailing lists