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>
Please register or sign in to comment