Gustavo A. R. Silva 1352eec8c0 scsi: ufs: core: Fix out-of-bounds warnings in ufshcd_exec_raw_upiu_cmd()
Fix the following out-of-bounds warnings by enclosing some structure
members into new structure objects upiu_req and upiu_rsp:

include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [29, 48] from the object at 'treq' is out of the bounds of referenced subobject 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds]
include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset [61, 80] from the object at 'treq' is out of the bounds of referenced subobject 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds]
arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset [29, 48] from the object at 'treq' is out of the bounds of referenced subobject 'req_header' with type 'struct utp_upiu_header' at offset 16 [-Warray-bounds]
arch/m68k/include/asm/string.h:72:25: warning: '__builtin_memcpy' offset [61, 80] from the object at 'treq' is out of the bounds of referenced subobject 'rsp_header' with type 'struct utp_upiu_header' at offset 48 [-Warray-bounds]

Refactor the code by making it more structured.

The problem is that the original code is trying to copy data into a bunch
of struct members adjacent to each other in a single call to memcpy(). Now
that a new struct _upiu_req_ enclosing all those adjacent members is
introduced, memcpy() doesn't overrun the length of &treq.req_header,
because the address of the new struct object _upiu_req_ is used as the
destination, instead. The same problem is present when memcpy() overruns
the length of the source &treq.rsp_header; in this case the address of the
new struct object _upiu_rsp_ is used, instead.

Also, this helps with the ongoing efforts to enable -Warray-bounds and
avoid confusing the compiler.

Link: https://github.com/KSPP/linux/issues/109
Link: https://lore.kernel.org/lkml/60640558.lsAxiK6otPwTo9rv%25lkp@intel.com/
Link: https://lore.kernel.org/r/20210331224338.GA347171@embeddedor
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Build-tested-by: kernel test robot <lkp@intel.com>
2021-04-05 23:38:45 -04:00
..
2021-01-22 21:14:09 -05:00
2021-03-24 23:06:27 -04:00
2021-03-24 22:58:33 -04:00
2021-03-24 22:54:24 -04:00
2020-03-11 23:07:59 -04:00
2021-01-13 00:15:13 -05:00
2021-01-22 21:14:07 -05:00
2021-01-22 21:14:08 -05:00
2021-01-22 21:14:07 -05:00
2021-02-22 10:24:58 -08:00
2021-01-22 21:14:08 -05:00
2020-02-24 14:54:25 -05:00
2020-03-11 23:07:59 -04:00
2021-03-24 23:07:14 -04:00
2020-09-02 22:49:06 -04:00
2020-08-23 17:36:59 -05:00
2018-11-06 21:31:28 -05:00
2020-12-07 20:24:09 -05:00
2021-01-22 21:14:07 -05:00
2020-10-14 15:15:35 -07:00
2021-01-26 22:11:17 -05:00
2020-12-07 20:24:09 -05:00
2020-12-07 20:24:09 -05:00
2020-08-23 17:36:59 -05:00
2020-10-14 15:15:35 -07:00
2021-03-24 23:03:43 -04:00
2021-02-22 10:24:58 -08:00
2021-03-29 23:09:10 -04:00
2020-12-01 14:53:39 -07:00
2021-03-18 23:35:54 -04:00
2020-10-14 15:15:35 -07:00
2019-07-11 15:14:01 -07:00
2020-02-24 15:01:57 -05:00
2021-01-22 21:14:10 -05:00
2020-10-14 15:15:35 -07:00
2021-01-22 21:14:12 -05:00
2019-07-11 15:14:01 -07:00