forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable -Warray-bounds (GCC 11 and earlier) #109
Labels
Comments
Currently, there are 60 of these warnings in next-20201102:
|
Hi, if I want to reproduce these warnings need to upgrade gcc? |
sudipm-mukherjee
pushed a commit
to sudipm-mukherjee/linux-test
that referenced
this issue
Feb 2, 2021
… icmsg_negotiate There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct icmsg_negotiate, instead of a one-element array. Also, this helps the ongoing efforts to enable -Warray-bounds and fix the following warnings: drivers/hv/channel_mgmt.c:315:23: warning: array subscript 1 is above array bounds of ‘struct ic_version[1]’ [-Warray-bounds] drivers/hv/channel_mgmt.c:316:23: warning: array subscript 1 is above array bounds of ‘struct ic_version[1]’ [-Warray-bounds] [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/20210201174334.GA171933@embeddedor Signed-off-by: Wei Liu <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 2, 2021
…t _MPI2_CONFIG_PAGE_IO_UNIT_3 There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct _MPI2_CONFIG_PAGE_IO_UNIT_3, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warning: drivers/scsi/mpt3sas/mpt3sas_ctl.c:3193:63: warning: array subscript 24 is above array bounds of ‘U16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds] [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Signed-off-by: Gustavo A. R. Silva <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 3, 2021
…t _MPI2_CONFIG_PAGE_IO_UNIT_3 There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct _MPI2_CONFIG_PAGE_IO_UNIT_3, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, this helps the ongoing efforts to enable -Warray-bounds and fix the following warnings: drivers/scsi/mpt3sas/mpt3sas_ctl.c:3193:63: warning: array subscript 24 is above array bounds of ‘U16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds] [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Signed-off-by: Gustavo A. R. Silva <[email protected]>
ColinIanKing
pushed a commit
to ColinIanKing/linux-next
that referenced
this issue
Feb 8, 2021
… icmsg_negotiate There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct icmsg_negotiate, instead of a one-element array. Also, this helps the ongoing efforts to enable -Warray-bounds and fix the following warnings: drivers/hv/channel_mgmt.c:315:23: warning: array subscript 1 is above array bounds of ‘struct ic_version[1]’ [-Warray-bounds] drivers/hv/channel_mgmt.c:316:23: warning: array subscript 1 is above array bounds of ‘struct ic_version[1]’ [-Warray-bounds] [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/20210201174334.GA171933@embeddedor Signed-off-by: Wei Liu <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 10, 2021
…ISLANDS_SMC_SWSTATE There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct SISLANDS_SMC_SWSTATE, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warnings: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2448:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2449:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2450:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2451:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2452:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:5570:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/6023be58.sk66L%2FV4vuSJI5mI%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 10, 2021
…ber in struct ndis_80211_var_ie There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct ndis_80211_var_ie, instead of a one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warnings: CC [M] drivers/staging/rtl8723bs/core/rtw_wlan_util.o In file included from ./drivers/staging/rtl8723bs/include/drv_types.h:20, from drivers/staging/rtl8723bs/core/rtw_wlan_util.c:9: drivers/staging/rtl8723bs/core/rtw_wlan_util.c: In function ‘HT_caps_handler’: ./drivers/staging/rtl8723bs/include/basic_types.h:108:11: warning: array subscript 1 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 108 | (EF1BYTE(*((u8 *)(__pstart)))) | ^ ./drivers/staging/rtl8723bs/include/basic_types.h:42:8: note: in definition of macro ‘EF1BYTE’ 42 | ((u8)(_val)) | ^~~~ ./drivers/staging/rtl8723bs/include/basic_types.h:127:4: note: in expansion of macro ‘LE_P1BYTE_TO_HOST_1BYTE’ 127 | (LE_P1BYTE_TO_HOST_1BYTE(__pstart) >> (__bitoffset)) & \ | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/staging/rtl8723bs/include/rtw_ht.h:97:55: note: in expansion of macro ‘LE_BITS_TO_1BYTE’ 97 | #define GET_HT_CAPABILITY_ELE_RX_STBC(_pEleStart) LE_BITS_TO_1BYTE((_pEleStart)+1, 0, 2) | ^~~~~~~~~~~~~~~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1104:58: note: in expansion of macro ‘GET_HT_CAPABILITY_ELE_RX_STBC’ 1104 | if (TEST_FLAG(phtpriv->stbc_cap, STBC_HT_ENABLE_TX) && GET_HT_CAPABILITY_ELE_RX_STBC(pIE->data)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1051:75: warning: array subscript 2 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1051 | if ((pmlmeinfo->HT_caps.u.HT_cap_element.AMPDU_para & 0x3) > (pIE->data[i] & 0x3)) | ~~~~~~~~~^~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c: In function ‘check_assoc_AP’: drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1606:19: warning: array subscript 4 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1606 | if (pIE->data[4] == 1) | ~~~~~~~~~^~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1609:20: warning: array subscript 5 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1609 | if (pIE->data[5] & RT_HT_CAP_USE_92SE) | ~~~~~~~~~^~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1613:19: warning: array subscript 5 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1613 | if (pIE->data[5] & RT_HT_CAP_USE_SOFTAP) | ~~~~~~~~~^~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1617:20: warning: array subscript 6 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1617 | if (pIE->data[6] & RT_HT_CAP_USE_JAGUAR_BCUT) { | ~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/602434b8.jc5DoXJ0bmHoxgIL%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 10, 2021
…ay member There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct hfi_sys_set_property_pkt instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warnings: drivers/media/platform/qcom/venus/hfi_cmds.c: In function ‘pkt_sys_coverage_config’: drivers/media/platform/qcom/venus/hfi_cmds.c:57:11: warning: array subscript 1 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 57 | pkt->data[1] = mode; | ~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/602416da.iZqae7Dbk7nyl6OY%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 10, 2021
…ATOM_Vega10_GFXCLK_Dependency_Table There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct _ATOM_Vega10_GFXCLK_Dependency_Table, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warning: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c: In function ‘vega10_get_pp_table_entry_callback_func’: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:3113:30: warning: array subscript 4 is above array bounds of ‘ATOM_Vega10_GFXCLK_Dependency_Record[1]’ {aka ‘struct _ATOM_Vega10_GFXCLK_Dependency_Record[1]’} [-Warray-bounds] 3113 | gfxclk_dep_table->entries[4].ulClk; | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/6023ff3d.WY3sSCkGRQPdPlVo%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 11, 2021
…ray member in struct NISLANDS_SMC_SWSTATE There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct NISLANDS_SMC_SWSTATE, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: drivers/gpu/drm/radeon/ni_dpm.c: In function ‘ni_convert_power_state_to_smc’: drivers/gpu/drm/radeon/ni_dpm.c:2521:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2521 | smc_state->levels[i].dpm2.MaxPS = | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2523:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2523 | smc_state->levels[i].dpm2.NearTDPDec = NISLANDS_DPM2_NEAR_TDP_DEC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2524:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2524 | smc_state->levels[i].dpm2.AboveSafeInc = NISLANDS_DPM2_ABOVE_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2525:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2525 | smc_state->levels[i].dpm2.BelowSafeInc = NISLANDS_DPM2_BELOW_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2526 | smc_state->levels[i].stateFlags |= | ^~ drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2526 | smc_state->levels[i].stateFlags |= | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ 2527 | ((i != (state->performance_level_count - 1)) && power_boost_limit) ? | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2528 | PPSMC_STATEFLAG_POWERBOOST : 0; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/radeon/ni_dpm.c:2442:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2442 | smc_state->levels[i + 1].aT = cpu_to_be32(a_t); [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/6023ed54.BfIY+9Uz81I6nq19%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 11, 2021
…ray members There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array members in struct hfi_msg_sys_property_info_pkt and hfi_msg_session_property_info_pkt instead of one-element arrays. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: CC [M] drivers/media/platform/qcom/venus/hfi_msgs.o drivers/media/platform/qcom/venus/hfi_msgs.c: In function ‘hfi_sys_property_info’: drivers/media/platform/qcom/venus/hfi_msgs.c:246:35: warning: array subscript 1 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 246 | if (req_bytes < 128 || !pkt->data[1] || pkt->num_properties > 1) | ~~~~~~~~~^~~ drivers/media/platform/qcom/venus/hfi_msgs.c: In function ‘hfi_session_prop_info’: drivers/media/platform/qcom/venus/hfi_msgs.c:342:62: warning: array subscript 1 is above array bounds of ‘u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 342 | if (!req_bytes || req_bytes % sizeof(*buf_req) || !pkt->data[1]) | ~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Build-tested-by: <[email protected]> Link: https://lore.kernel.org/lkml/6023dd80.MmTeFf8SzwX0iK7%2F%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]>
sudipm-mukherjee
pushed a commit
to sudipm-mukherjee/linux-test
that referenced
this issue
Feb 11, 2021
… icmsg_negotiate There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct icmsg_negotiate, instead of a one-element array. Also, this helps the ongoing efforts to enable -Warray-bounds and fix the following warnings: drivers/hv/channel_mgmt.c:315:23: warning: array subscript 1 is above array bounds of ‘struct ic_version[1]’ [-Warray-bounds] drivers/hv/channel_mgmt.c:316:23: warning: array subscript 1 is above array bounds of ‘struct ic_version[1]’ [-Warray-bounds] [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/20210201174334.GA171933@embeddedor Signed-off-by: Wei Liu <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Feb 12, 2021
…ber in struct ndis_80211_var_ie There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct ndis_80211_var_ie, instead of a one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warnings: CC [M] drivers/staging/rtl8723bs/core/rtw_wlan_util.o In file included from ./drivers/staging/rtl8723bs/include/drv_types.h:20, from drivers/staging/rtl8723bs/core/rtw_wlan_util.c:9: drivers/staging/rtl8723bs/core/rtw_wlan_util.c: In function ‘HT_caps_handler’: ./drivers/staging/rtl8723bs/include/basic_types.h:108:11: warning: array subscript 1 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 108 | (EF1BYTE(*((u8 *)(__pstart)))) | ^ ./drivers/staging/rtl8723bs/include/basic_types.h:42:8: note: in definition of macro ‘EF1BYTE’ 42 | ((u8)(_val)) | ^~~~ ./drivers/staging/rtl8723bs/include/basic_types.h:127:4: note: in expansion of macro ‘LE_P1BYTE_TO_HOST_1BYTE’ 127 | (LE_P1BYTE_TO_HOST_1BYTE(__pstart) >> (__bitoffset)) & \ | ^~~~~~~~~~~~~~~~~~~~~~~ ./drivers/staging/rtl8723bs/include/rtw_ht.h:97:55: note: in expansion of macro ‘LE_BITS_TO_1BYTE’ 97 | #define GET_HT_CAPABILITY_ELE_RX_STBC(_pEleStart) LE_BITS_TO_1BYTE((_pEleStart)+1, 0, 2) | ^~~~~~~~~~~~~~~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1104:58: note: in expansion of macro ‘GET_HT_CAPABILITY_ELE_RX_STBC’ 1104 | if (TEST_FLAG(phtpriv->stbc_cap, STBC_HT_ENABLE_TX) && GET_HT_CAPABILITY_ELE_RX_STBC(pIE->data)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1051:75: warning: array subscript 2 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1051 | if ((pmlmeinfo->HT_caps.u.HT_cap_element.AMPDU_para & 0x3) > (pIE->data[i] & 0x3)) | ~~~~~~~~~^~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c: In function ‘check_assoc_AP’: drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1606:19: warning: array subscript 4 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1606 | if (pIE->data[4] == 1) | ~~~~~~~~~^~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1609:20: warning: array subscript 5 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1609 | if (pIE->data[5] & RT_HT_CAP_USE_92SE) | ~~~~~~~~~^~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1613:19: warning: array subscript 5 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1613 | if (pIE->data[5] & RT_HT_CAP_USE_SOFTAP) | ~~~~~~~~~^~~ drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1617:20: warning: array subscript 6 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 1617 | if (pIE->data[6] & RT_HT_CAP_USE_JAGUAR_BCUT) { | ~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/602434b8.jc5DoXJ0bmHoxgIL%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/20210210224937.GA11922@embeddedor Signed-off-by: Greg Kroah-Hartman <[email protected]>
FireBurn
pushed a commit
to FireBurn/linux
that referenced
this issue
Feb 16, 2021
…ISLANDS_SMC_SWSTATE There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct SISLANDS_SMC_SWSTATE, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warnings: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2448:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2449:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2450:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2451:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2452:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:5570:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/6023be58.sk66L%2FV4vuSJI5mI%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
FireBurn
pushed a commit
to FireBurn/linux
that referenced
this issue
Feb 16, 2021
…ATOM_Vega10_GFXCLK_Dependency_Table There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct _ATOM_Vega10_GFXCLK_Dependency_Table, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warning: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c: In function ‘vega10_get_pp_table_entry_callback_func’: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:3113:30: warning: array subscript 4 is above array bounds of ‘ATOM_Vega10_GFXCLK_Dependency_Record[1]’ {aka ‘struct _ATOM_Vega10_GFXCLK_Dependency_Record[1]’} [-Warray-bounds] 3113 | gfxclk_dep_table->entries[4].ulClk; | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/6023ff3d.WY3sSCkGRQPdPlVo%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
FireBurn
pushed a commit
to FireBurn/linux
that referenced
this issue
Feb 16, 2021
…ray member in struct NISLANDS_SMC_SWSTATE There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct NISLANDS_SMC_SWSTATE, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: drivers/gpu/drm/radeon/ni_dpm.c: In function ‘ni_convert_power_state_to_smc’: drivers/gpu/drm/radeon/ni_dpm.c:2521:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2521 | smc_state->levels[i].dpm2.MaxPS = | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2523:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2523 | smc_state->levels[i].dpm2.NearTDPDec = NISLANDS_DPM2_NEAR_TDP_DEC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2524:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2524 | smc_state->levels[i].dpm2.AboveSafeInc = NISLANDS_DPM2_ABOVE_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2525:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2525 | smc_state->levels[i].dpm2.BelowSafeInc = NISLANDS_DPM2_BELOW_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2526 | smc_state->levels[i].stateFlags |= | ^~ drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2526 | smc_state->levels[i].stateFlags |= | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ 2527 | ((i != (state->performance_level_count - 1)) && power_boost_limit) ? | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2528 | PPSMC_STATEFLAG_POWERBOOST : 0; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/radeon/ni_dpm.c:2442:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2442 | smc_state->levels[i + 1].aT = cpu_to_be32(a_t); [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/6023ed54.BfIY+9Uz81I6nq19%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
sudipm-mukherjee
pushed a commit
to sudipm-mukherjee/linux-test
that referenced
this issue
Feb 19, 2021
…ISLANDS_SMC_SWSTATE There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct SISLANDS_SMC_SWSTATE, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warnings: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2448:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2449:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2450:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2451:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:2452:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] drivers/gpu/drm/amd/amdgpu/../pm/powerplay/si_dpm.c:5570:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/6023be58.sk66L%2FV4vuSJI5mI%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
sudipm-mukherjee
pushed a commit
to sudipm-mukherjee/linux-test
that referenced
this issue
Feb 19, 2021
…ATOM_Vega10_GFXCLK_Dependency_Table There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct _ATOM_Vega10_GFXCLK_Dependency_Table, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds and fix the following warning: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c: In function ‘vega10_get_pp_table_entry_callback_func’: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_hwmgr.c:3113:30: warning: array subscript 4 is above array bounds of ‘ATOM_Vega10_GFXCLK_Dependency_Record[1]’ {aka ‘struct _ATOM_Vega10_GFXCLK_Dependency_Record[1]’} [-Warray-bounds] 3113 | gfxclk_dep_table->entries[4].ulClk; | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/6023ff3d.WY3sSCkGRQPdPlVo%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
sudipm-mukherjee
pushed a commit
to sudipm-mukherjee/linux-test
that referenced
this issue
Feb 19, 2021
…ray member in struct NISLANDS_SMC_SWSTATE There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct NISLANDS_SMC_SWSTATE, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: drivers/gpu/drm/radeon/ni_dpm.c: In function ‘ni_convert_power_state_to_smc’: drivers/gpu/drm/radeon/ni_dpm.c:2521:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2521 | smc_state->levels[i].dpm2.MaxPS = | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2523:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2523 | smc_state->levels[i].dpm2.NearTDPDec = NISLANDS_DPM2_NEAR_TDP_DEC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2524:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2524 | smc_state->levels[i].dpm2.AboveSafeInc = NISLANDS_DPM2_ABOVE_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2525:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2525 | smc_state->levels[i].dpm2.BelowSafeInc = NISLANDS_DPM2_BELOW_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2526 | smc_state->levels[i].stateFlags |= | ^~ drivers/gpu/drm/radeon/ni_dpm.c:2526:35: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2526 | smc_state->levels[i].stateFlags |= | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~ 2527 | ((i != (state->performance_level_count - 1)) && power_boost_limit) ? | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2528 | PPSMC_STATEFLAG_POWERBOOST : 0; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/radeon/ni_dpm.c:2442:20: warning: array subscript 1 is above array bounds of ‘NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct NISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2442 | smc_state->levels[i + 1].aT = cpu_to_be32(a_t); [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/6023ed54.BfIY+9Uz81I6nq19%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Mar 4, 2021
…struct ndis_802_11_var_ie There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct ndis_802_11_var_ie, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warning: drivers/staging/rtl8188eu/core/rtw_wlan_util.c: In function ‘HT_caps_handler’: drivers/staging/rtl8188eu/core/rtw_wlan_util.c:665:65: warning: array subscript 2 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 665 | if ((pmlmeinfo->HT_caps.ampdu_params_info & 0x3) > (pIE->data[i] & 0x3)) | ~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Signed-off-by: Gustavo A. R. Silva <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Mar 4, 2021
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct aac_raw_io2 instead of one-element array, and use the struct_size() and flex_array_size() helpers. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: drivers/scsi/aacraid/aachba.c: In function ‘aac_build_sgraw2’: drivers/scsi/aacraid/aachba.c:3970:18: warning: array subscript 1 is above array bounds of ‘struct sge_ieee1212[1]’ [-Warray-bounds] 3970 | if (rio2->sge[j].length % (i*PAGE_SIZE)) { | ~~~~~~~~~^~~ drivers/scsi/aacraid/aachba.c:3974:27: warning: array subscript 1 is above array bounds of ‘struct sge_ieee1212[1]’ [-Warray-bounds] 3974 | nseg_new += (rio2->sge[j].length / (i*PAGE_SIZE)); | ~~~~~~~~~^~~ drivers/scsi/aacraid/aachba.c:4011:28: warning: array subscript 1 is above array bounds of ‘struct sge_ieee1212[1]’ [-Warray-bounds] 4011 | for (j = 0; j < rio2->sge[i].length / (pages * PAGE_SIZE); ++j) { | ~~~~~~~~~^~~ drivers/scsi/aacraid/aachba.c:4012:24: warning: array subscript 1 is above array bounds of ‘struct sge_ieee1212[1]’ [-Warray-bounds] 4012 | addr_low = rio2->sge[i].addrLow + j * pages * PAGE_SIZE; | ~~~~~~~~~^~~ drivers/scsi/aacraid/aachba.c:4014:33: warning: array subscript 1 is above array bounds of ‘struct sge_ieee1212[1]’ [-Warray-bounds] 4014 | sge[pos].addrHigh = rio2->sge[i].addrHigh; | ~~~~~~~~~^~~ drivers/scsi/aacraid/aachba.c:4015:28: warning: array subscript 1 is above array bounds of ‘struct sge_ieee1212[1]’ [-Warray-bounds] 4015 | if (addr_low < rio2->sge[i].addrLow) | ~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/60414244.ur4%2FkI+fBF1ohKZs%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]>
FireBurn
pushed a commit
to FireBurn/linux
that referenced
this issue
Mar 6, 2021
…truct SISLANDS_SMC_SWSTATE There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of a flexible-array member in struct SISLANDS_SMC_SWSTATE, instead of a one-element array, and use the struct_size() helper to calculate the size for the allocation. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: drivers/gpu/drm/radeon/si_dpm.c: In function ‘si_convert_power_state_to_smc’: drivers/gpu/drm/radeon/si_dpm.c:2350:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2350 | smc_state->levels[i].dpm2.MaxPS = (u8)((SISLANDS_DPM2_MAX_PULSE_SKIP * (max_sclk - min_sclk)) / max_sclk); | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/si_dpm.c:2351:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2351 | smc_state->levels[i].dpm2.NearTDPDec = SISLANDS_DPM2_NEAR_TDP_DEC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/si_dpm.c:2352:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2352 | smc_state->levels[i].dpm2.AboveSafeInc = SISLANDS_DPM2_ABOVE_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/si_dpm.c:2353:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2353 | smc_state->levels[i].dpm2.BelowSafeInc = SISLANDS_DPM2_BELOW_SAFE_INC; | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/si_dpm.c:2354:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 2354 | smc_state->levels[i].dpm2.PwrEfficiencyRatio = cpu_to_be16(pwr_efficiency_ratio); | ~~~~~~~~~~~~~~~~~^~~ drivers/gpu/drm/radeon/si_dpm.c:5105:20: warning: array subscript 1 is above array bounds of ‘SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’ {aka ‘struct SISLANDS_SMC_HW_PERFORMANCE_LEVEL[1]’} [-Warray-bounds] 5105 | smc_state->levels[i + 1].aT = cpu_to_be32(a_t); | ~~~~~~~~~~~~~~~~~^~~~~~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Build-tested-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/603f9a8f.aDLrpMFzzSApzVYQ%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Mar 9, 2021
…struct ndis_802_11_var_ie There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct ndis_802_11_var_ie, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warning: drivers/staging/rtl8188eu/core/rtw_wlan_util.c: In function ‘HT_caps_handler’: drivers/staging/rtl8188eu/core/rtw_wlan_util.c:665:65: warning: array subscript 2 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 665 | if ((pmlmeinfo->HT_caps.ampdu_params_info & 0x3) > (pIE->data[i] & 0x3)) | ~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/20210304020228.GA45139@embeddedor Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Mar 10, 2021
…ember There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code according to the use of flexible-array members in smt_sif_operation structure, instead of one-element arrays. Also, make use of the struct_size() helper instead of the open-coded version to calculate the size of the struct-with-flex-array. Additionally, make use of the typeof operator to properly determine the object type to be passed to macro smtod(). Also, this helps the ongoing efforts to enable -Warray-bounds by fixing the following warnings: CC [M] drivers/net/fddi/skfp/smt.o drivers/net/fddi/skfp/smt.c: In function ‘smt_send_sif_operation’: drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ | ^~~ drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ | ^~~ drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ | ^~~ drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ | ^~~ drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ | ^~~ drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ | ^~~ drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ | ^~~ drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ | ^~~ drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ | ^~~ drivers/net/fddi/skfp/smt.c:1084:30: warning: array subscript 1 is above array bounds of ‘struct smt_p_lem[1]’ [-Warray-bounds] 1084 | smt_fill_lem(smc,&sif->lem[i],i) ; | ~~~~~~~~^~~ In file included from drivers/net/fddi/skfp/h/smc.h:42, from drivers/net/fddi/skfp/smt.c:15: drivers/net/fddi/skfp/h/smt.h:767:19: note: while referencing ‘lem’ 767 | struct smt_p_lem lem[1] ; /* phy lem status */ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Signed-off-by: Gustavo A. R. Silva <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Mar 10, 2021
…struct ndis_802_11_var_ie There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use flexible-array member in struct ndis_802_11_var_ie, instead of one-element array. Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warning: drivers/staging/rtl8188eu/core/rtw_wlan_util.c: In function ‘HT_caps_handler’: drivers/staging/rtl8188eu/core/rtw_wlan_util.c:665:65: warning: array subscript 2 is above array bounds of ‘u8[1]’ {aka ‘unsigned char[1]’} [-Warray-bounds] 665 | if ((pmlmeinfo->HT_caps.ampdu_params_info & 0x3) > (pIE->data[i] & 0x3)) | ~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP#79 Link: KSPP#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/20210304020228.GA45139@embeddedor Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this issue
Mar 11, 2021
Dynamic memory allocation isn't actually needed and it can be replaced by statically allocating memory for struct object io_unit_pg3 with 36 hardcoded entries for its GPIOVal array. Also, this helps the with ongoing efforts to enable -Warray-bounds by fixing the following warning: drivers/scsi/mpt3sas/mpt3sas_ctl.c: In function ‘BRM_status_show’: drivers/scsi/mpt3sas/mpt3sas_ctl.c:3257:63: warning: array subscript 24 is above array bounds of ‘U16[1]’ {aka ‘short unsigned int[1]’} [-Warray-bounds] 3257 | backup_rail_monitor_status = le16_to_cpu(io_unit_pg3->GPIOVal[24]); ./include/uapi/linux/byteorder/little_endian.h:36:51: note: in definition of macro ‘__le16_to_cpu’ 36 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x)) | ^ drivers/scsi/mpt3sas/mpt3sas_ctl.c:3257:31: note: in expansion of macro ‘le16_to_cpu’ 3257 | backup_rail_monitor_status = le16_to_cpu(io_unit_pg3->GPIOVal[24]); Link: KSPP#109 Link: https://lore.kernel.org/lkml/202103101058.16ED27BE3@keescook/ Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]>
rsuntk
pushed a commit
to rsuntk/android_kernel_samsung_a13-a04s
that referenced
this issue
Aug 2, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
sfX-bot
pushed a commit
to AXP-OS/android_kernel_sony_sdm845
that referenced
this issue
Aug 2, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this issue
Aug 8, 2024
Source: Kernel.org MR: 151783 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.10.y ChangeID: b20d88bf1eab5f33103457f535dad686c849b325 Description: [ Upstream commit c0a744d ] There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use an anonymous union with a couple of anonymous structs in order to keep userspace unchanged: $ pahole -C nfs_fhbase_new fs/nfsd/nfsfh.o struct nfs_fhbase_new { union { struct { __u8 fb_version_aux; /* 0 1 */ __u8 fb_auth_type_aux; /* 1 1 */ __u8 fb_fsid_type_aux; /* 2 1 */ __u8 fb_fileid_type_aux; /* 3 1 */ __u32 fb_auth[1]; /* 4 4 */ }; /* 0 8 */ struct { __u8 fb_version; /* 0 1 */ __u8 fb_auth_type; /* 1 1 */ __u8 fb_fsid_type; /* 2 1 */ __u8 fb_fileid_type; /* 3 1 */ __u32 fb_auth_flex[0]; /* 4 0 */ }; /* 0 4 */ }; /* 0 8 */ /* size: 8, cachelines: 1, members: 1 */ /* last cacheline: 8 bytes */ }; Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: fs/nfsd/nfsfh.c: In function ‘nfsd_set_fh_dentry’: fs/nfsd/nfsfh.c:191:41: warning: array subscript 1 is above array bounds of ‘__u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 191 | ntohl((__force __be32)fh->fh_fsid[1]))); | ~~~~~~~~~~~^~~ ./include/linux/kdev_t.h:12:46: note: in definition of macro ‘MKDEV’ 12 | #define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi)) | ^~ ./include/uapi/linux/byteorder/little_endian.h:40:26: note: in expansion of macro ‘__swab32’ 40 | #define __be32_to_cpu(x) __swab32((__force __u32)(__be32)(x)) | ^~~~~~~~ ./include/linux/byteorder/generic.h:136:21: note: in expansion of macro ‘__be32_to_cpu’ 136 | #define ___ntohl(x) __be32_to_cpu(x) | ^~~~~~~~~~~~~ ./include/linux/byteorder/generic.h:140:18: note: in expansion of macro ‘___ntohl’ 140 | #define ntohl(x) ___ntohl(x) | ^~~~~~~~ fs/nfsd/nfsfh.c:191:8: note: in expansion of macro ‘ntohl’ 191 | ntohl((__force __be32)fh->fh_fsid[1]))); | ^~~~~ fs/nfsd/nfsfh.c:192:32: warning: array subscript 2 is above array bounds of ‘__u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 192 | fh->fh_fsid[1] = fh->fh_fsid[2]; | ~~~~~~~~~~~^~~ fs/nfsd/nfsfh.c:192:15: warning: array subscript 1 is above array bounds of ‘__u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 192 | fh->fh_fsid[1] = fh->fh_fsid[2]; | ~~~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Armin Kuster <[email protected]>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this issue
Aug 8, 2024
Source: Kernel.org MR: 151783 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.10.y ChangeID: b20d88bf1eab5f33103457f535dad686c849b325 Description: [ Upstream commit c0a744d ] There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use an anonymous union with a couple of anonymous structs in order to keep userspace unchanged: $ pahole -C nfs_fhbase_new fs/nfsd/nfsfh.o struct nfs_fhbase_new { union { struct { __u8 fb_version_aux; /* 0 1 */ __u8 fb_auth_type_aux; /* 1 1 */ __u8 fb_fsid_type_aux; /* 2 1 */ __u8 fb_fileid_type_aux; /* 3 1 */ __u32 fb_auth[1]; /* 4 4 */ }; /* 0 8 */ struct { __u8 fb_version; /* 0 1 */ __u8 fb_auth_type; /* 1 1 */ __u8 fb_fsid_type; /* 2 1 */ __u8 fb_fileid_type; /* 3 1 */ __u32 fb_auth_flex[0]; /* 4 0 */ }; /* 0 4 */ }; /* 0 8 */ /* size: 8, cachelines: 1, members: 1 */ /* last cacheline: 8 bytes */ }; Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: fs/nfsd/nfsfh.c: In function ‘nfsd_set_fh_dentry’: fs/nfsd/nfsfh.c:191:41: warning: array subscript 1 is above array bounds of ‘__u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 191 | ntohl((__force __be32)fh->fh_fsid[1]))); | ~~~~~~~~~~~^~~ ./include/linux/kdev_t.h:12:46: note: in definition of macro ‘MKDEV’ 12 | #define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi)) | ^~ ./include/uapi/linux/byteorder/little_endian.h:40:26: note: in expansion of macro ‘__swab32’ 40 | #define __be32_to_cpu(x) __swab32((__force __u32)(__be32)(x)) | ^~~~~~~~ ./include/linux/byteorder/generic.h:136:21: note: in expansion of macro ‘__be32_to_cpu’ 136 | #define ___ntohl(x) __be32_to_cpu(x) | ^~~~~~~~~~~~~ ./include/linux/byteorder/generic.h:140:18: note: in expansion of macro ‘___ntohl’ 140 | #define ntohl(x) ___ntohl(x) | ^~~~~~~~ fs/nfsd/nfsfh.c:191:8: note: in expansion of macro ‘ntohl’ 191 | ntohl((__force __be32)fh->fh_fsid[1]))); | ^~~~~ fs/nfsd/nfsfh.c:192:32: warning: array subscript 2 is above array bounds of ‘__u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 192 | fh->fh_fsid[1] = fh->fh_fsid[2]; | ~~~~~~~~~~~^~~ fs/nfsd/nfsfh.c:192:15: warning: array subscript 1 is above array bounds of ‘__u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 192 | fh->fh_fsid[1] = fh->fh_fsid[2]; | ~~~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Armin Kuster <[email protected]>
jpuhlman
pushed a commit
to MontaVista-OpenSourceTechnology/linux-mvista
that referenced
this issue
Aug 8, 2024
Source: Kernel.org MR: 151783 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.10.y ChangeID: b20d88bf1eab5f33103457f535dad686c849b325 Description: [ Upstream commit c0a744d ] There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use an anonymous union with a couple of anonymous structs in order to keep userspace unchanged: $ pahole -C nfs_fhbase_new fs/nfsd/nfsfh.o struct nfs_fhbase_new { union { struct { __u8 fb_version_aux; /* 0 1 */ __u8 fb_auth_type_aux; /* 1 1 */ __u8 fb_fsid_type_aux; /* 2 1 */ __u8 fb_fileid_type_aux; /* 3 1 */ __u32 fb_auth[1]; /* 4 4 */ }; /* 0 8 */ struct { __u8 fb_version; /* 0 1 */ __u8 fb_auth_type; /* 1 1 */ __u8 fb_fsid_type; /* 2 1 */ __u8 fb_fileid_type; /* 3 1 */ __u32 fb_auth_flex[0]; /* 4 0 */ }; /* 0 4 */ }; /* 0 8 */ /* size: 8, cachelines: 1, members: 1 */ /* last cacheline: 8 bytes */ }; Also, this helps with the ongoing efforts to enable -Warray-bounds by fixing the following warnings: fs/nfsd/nfsfh.c: In function ‘nfsd_set_fh_dentry’: fs/nfsd/nfsfh.c:191:41: warning: array subscript 1 is above array bounds of ‘__u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 191 | ntohl((__force __be32)fh->fh_fsid[1]))); | ~~~~~~~~~~~^~~ ./include/linux/kdev_t.h:12:46: note: in definition of macro ‘MKDEV’ 12 | #define MKDEV(ma,mi) (((ma) << MINORBITS) | (mi)) | ^~ ./include/uapi/linux/byteorder/little_endian.h:40:26: note: in expansion of macro ‘__swab32’ 40 | #define __be32_to_cpu(x) __swab32((__force __u32)(__be32)(x)) | ^~~~~~~~ ./include/linux/byteorder/generic.h:136:21: note: in expansion of macro ‘__be32_to_cpu’ 136 | #define ___ntohl(x) __be32_to_cpu(x) | ^~~~~~~~~~~~~ ./include/linux/byteorder/generic.h:140:18: note: in expansion of macro ‘___ntohl’ 140 | #define ntohl(x) ___ntohl(x) | ^~~~~~~~ fs/nfsd/nfsfh.c:191:8: note: in expansion of macro ‘ntohl’ 191 | ntohl((__force __be32)fh->fh_fsid[1]))); | ^~~~~ fs/nfsd/nfsfh.c:192:32: warning: array subscript 2 is above array bounds of ‘__u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 192 | fh->fh_fsid[1] = fh->fh_fsid[2]; | ~~~~~~~~~~~^~~ fs/nfsd/nfsfh.c:192:15: warning: array subscript 1 is above array bounds of ‘__u32[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds] 192 | fh->fh_fsid[1] = fh->fh_fsid[2]; | ~~~~~~~~~~~^~~ [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: Armin Kuster <[email protected]>
MSe1969
pushed a commit
to lin16-microg/android_kernel_motorola_msm8916
that referenced
this issue
Aug 17, 2024
Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/
MSe1969
pushed a commit
to lin16-microg/android_kernel_motorola_msm8916
that referenced
this issue
Aug 17, 2024
Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/
FakeShell
pushed a commit
to FuriLabs/linux-android-furiphone-krypton
that referenced
this issue
Aug 19, 2024
[ Upstream commit e93bdd78406da9ed01554c51e38b2a02c8ef8025 ] 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(). Link: KSPP/linux#109 Reported-by: kernel test robot <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/20210422200032.GA168995@embeddedor Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
FakeShell
pushed a commit
to FuriLabs/linux-android-furiphone-krypton
that referenced
this issue
Aug 19, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
FakeShell
pushed a commit
to FuriLabs/linux-android-furiphone-krypton
that referenced
this issue
Aug 20, 2024
[ Upstream commit 6321c7acb82872ef6576c520b0e178eaad3a25c0 ] Fix the following out-of-bounds warning: In function 'ip_copy_addrs', inlined from '__ip_queue_xmit' at net/ipv4/ip_output.c:517:2: net/ipv4/ip_output.c:449:2: warning: 'memcpy' offset [40, 43] from the object at 'fl' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 36 [-Warray-bounds] 449 | memcpy(&iph->saddr, &fl4->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 450 | sizeof(fl4->saddr) + sizeof(fl4->daddr)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 &iph->saddr and &fl4->saddr. 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(). Link: KSPP/linux#109 Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
FakeShell
pushed a commit
to FuriLabs/linux-android-furiphone-krypton
that referenced
this issue
Aug 20, 2024
[ Upstream commit 323e0cb473e2a8706ff162b6b4f4fa16023c9ba7 ] Fix the following out-of-bounds warnings: net/core/flow_dissector.c: In function '__skb_flow_dissect': >> net/core/flow_dissector.c:1104:4: warning: 'memcpy' offset [24, 39] from the object at '<unknown>' is out of the bounds of referenced subobject 'saddr' with type 'struct in6_addr' at offset 8 [-Warray-bounds] 1104 | memcpy(&key_addrs->v6addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1105 | sizeof(key_addrs->v6addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ipv6.h:5, from net/core/flow_dissector.c:6: include/uapi/linux/ipv6.h:133:18: note: subobject 'saddr' declared here 133 | struct in6_addr saddr; | ^~~~~ >> net/core/flow_dissector.c:1059:4: warning: 'memcpy' offset [16, 19] from the object at '<unknown>' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 12 [-Warray-bounds] 1059 | memcpy(&key_addrs->v4addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1060 | sizeof(key_addrs->v4addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ip.h:17, from net/core/flow_dissector.c:5: include/uapi/linux/ip.h:103:9: note: subobject 'saddr' declared here 103 | __be32 saddr; | ^~~~~ 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(). So, the compiler legitimately complains about it. As these are just a couple of members, fix this by copying each one of them in separate calls to 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(). Link: KSPP/linux#109 Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
FakeShell
pushed a commit
to FuriLabs/linux-android-furiphone-krypton
that referenced
this issue
Aug 20, 2024
[ Upstream commit 6321c7acb82872ef6576c520b0e178eaad3a25c0 ] Fix the following out-of-bounds warning: In function 'ip_copy_addrs', inlined from '__ip_queue_xmit' at net/ipv4/ip_output.c:517:2: net/ipv4/ip_output.c:449:2: warning: 'memcpy' offset [40, 43] from the object at 'fl' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 36 [-Warray-bounds] 449 | memcpy(&iph->saddr, &fl4->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 450 | sizeof(fl4->saddr) + sizeof(fl4->daddr)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 &iph->saddr and &fl4->saddr. 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(). Link: KSPP/linux#109 Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
FakeShell
pushed a commit
to FuriLabs/linux-android-furiphone-krypton
that referenced
this issue
Aug 20, 2024
[ Upstream commit 323e0cb473e2a8706ff162b6b4f4fa16023c9ba7 ] Fix the following out-of-bounds warnings: net/core/flow_dissector.c: In function '__skb_flow_dissect': >> net/core/flow_dissector.c:1104:4: warning: 'memcpy' offset [24, 39] from the object at '<unknown>' is out of the bounds of referenced subobject 'saddr' with type 'struct in6_addr' at offset 8 [-Warray-bounds] 1104 | memcpy(&key_addrs->v6addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1105 | sizeof(key_addrs->v6addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ipv6.h:5, from net/core/flow_dissector.c:6: include/uapi/linux/ipv6.h:133:18: note: subobject 'saddr' declared here 133 | struct in6_addr saddr; | ^~~~~ >> net/core/flow_dissector.c:1059:4: warning: 'memcpy' offset [16, 19] from the object at '<unknown>' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 12 [-Warray-bounds] 1059 | memcpy(&key_addrs->v4addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1060 | sizeof(key_addrs->v4addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ip.h:17, from net/core/flow_dissector.c:5: include/uapi/linux/ip.h:103:9: note: subobject 'saddr' declared here 103 | __be32 saddr; | ^~~~~ 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(). So, the compiler legitimately complains about it. As these are just a couple of members, fix this by copying each one of them in separate calls to 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(). Link: KSPP/linux#109 Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
sfX-bot
pushed a commit
to AXP-OS/android_kernel_oneplus_sm8150
that referenced
this issue
Aug 21, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
sfX-bot
pushed a commit
to AXP-OS/android_kernel_oneplus_sm8150
that referenced
this issue
Aug 22, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
sfX-bot
pushed a commit
to AXP-OS/android_kernel_oneplus_sm8150
that referenced
this issue
Aug 22, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
sfX-bot
pushed a commit
to AXP-OS/android_kernel_samsung_exynos7870
that referenced
this issue
Aug 24, 2024
Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/
sfX-bot
pushed a commit
to AXP-OS/android_kernel_oneplus_sm8150
that referenced
this issue
Aug 26, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
nokidevz
pushed a commit
to xiaomi-mt6781-dev/kernel_xiaomi_mt6781
that referenced
this issue
Aug 30, 2024
[ Upstream commit e93bdd78406da9ed01554c51e38b2a02c8ef8025 ] 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(). Link: KSPP/linux#109 Reported-by: kernel test robot <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/20210422200032.GA168995@embeddedor Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
nokidevz
pushed a commit
to xiaomi-mt6781-dev/kernel_xiaomi_mt6781
that referenced
this issue
Aug 30, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
PlaidCat
added a commit
to ctrliq/kernel-src-tree
that referenced
this issue
Sep 12, 2024
jira LE-1907 Rebuild_History Non-Buildable kernel-4.18.0-365.el8 commit-author Gustavo A. R. Silva <[email protected]> commit 1e3d976 Fix the following out-of-bounds warning: net/core/flow_dissector.c:835:3: warning: 'memcpy' offset [33, 48] from the object at 'flow_keys' is out of the bounds of referenced subobject 'ipv6_src' with type '__u32[4]' {aka 'unsigned int[4]'} at offset 16 [-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(). So, the compiler legitimately complains about it. As these are just a couple of members, fix this by copying each one of them in separate calls to 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(). Link: KSPP/linux#109 Reported-by: kernel test robot <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: David S. Miller <[email protected]> (cherry picked from commit 1e3d976) Signed-off-by: Jonathan Maple <[email protected]>
PlaidCat
added a commit
to ctrliq/kernel-src-tree
that referenced
this issue
Sep 13, 2024
jira LE-1907 Rebuild_History Non-Buildable kernel-4.18.0-373.el8 commit-author Gustavo A. R. Silva <[email protected]> commit b254946 There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use "flexible array members"[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Refactor the code a bit according to the use of a flexible-array member in struct scan_chan_list_params instead of a one-element array, and use the struct_size() helper. Also, save 25 (too many) bytes that were being allocated: $ pahole -C channel_param drivers/net/wireless/ath/ath11k/reg.o struct channel_param { u8 chan_id; /* 0 1 */ u8 pwr; /* 1 1 */ u32 mhz; /* 2 4 */ /* Bitfield combined with next fields */ u32 half_rate:1; /* 4:16 4 */ u32 quarter_rate:1; /* 4:17 4 */ u32 dfs_set:1; /* 4:18 4 */ u32 dfs_set_cfreq2:1; /* 4:19 4 */ u32 is_chan_passive:1; /* 4:20 4 */ u32 allow_ht:1; /* 4:21 4 */ u32 allow_vht:1; /* 4:22 4 */ u32 allow_he:1; /* 4:23 4 */ u32 set_agile:1; /* 4:24 4 */ u32 psc_channel:1; /* 4:25 4 */ /* XXX 6 bits hole, try to pack */ u32 phy_mode; /* 8 4 */ u32 cfreq1; /* 12 4 */ u32 cfreq2; /* 16 4 */ char maxpower; /* 20 1 */ char minpower; /* 21 1 */ char maxregpower; /* 22 1 */ u8 antennamax; /* 23 1 */ u8 reg_class_id; /* 24 1 */ /* size: 25, cachelines: 1, members: 21 */ /* sum members: 23 */ /* sum bitfield members: 10 bits, bit holes: 1, sum bit holes: 6 bits */ /* last cacheline: 25 bytes */ } __attribute__((__packed__)); as previously, sizeof(struct scan_chan_list_params) was 32 bytes: $ pahole -C scan_chan_list_params drivers/net/wireless/ath/ath11k/reg.o struct scan_chan_list_params { u32 pdev_id; /* 0 4 */ u16 nallchans; /* 4 2 */ struct channel_param ch_param[1]; /* 6 25 */ /* size: 32, cachelines: 1, members: 3 */ /* padding: 1 */ /* last cacheline: 32 bytes */ }; and now with the flexible array transformation it is just 8 bytes: $ pahole -C scan_chan_list_params drivers/net/wireless/ath/ath11k/reg.o struct scan_chan_list_params { u32 pdev_id; /* 0 4 */ u16 nallchans; /* 4 2 */ struct channel_param ch_param[]; /* 6 0 */ /* size: 8, cachelines: 1, members: 3 */ /* padding: 2 */ /* last cacheline: 8 bytes */ }; 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(). This issue was found with the help of Coccinelle and audited and fixed, manually. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/20210823172159.GA25800@embeddedor (cherry picked from commit b254946) Signed-off-by: Jonathan Maple <[email protected]>
sfX-bot
pushed a commit
to AXP-OS/android_kernel_sony_sdm845
that referenced
this issue
Sep 18, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
sfX-bot
pushed a commit
to AXP-OS/android_kernel_sony_sdm845
that referenced
this issue
Sep 19, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
sfX-bot
pushed a commit
to AXP-OS/android_kernel_samsung_exynos7870
that referenced
this issue
Sep 19, 2024
Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/
FranklinAzriel
pushed a commit
to Quixoticly/android_kernel_samsung_mt6765-old
that referenced
this issue
Sep 27, 2024
[ Upstream commit e93bdd78406da9ed01554c51e38b2a02c8ef8025 ] 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(). Link: KSPP/linux#109 Reported-by: kernel test robot <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Kees Cook <[email protected]> Link: https://lore.kernel.org/r/20210422200032.GA168995@embeddedor Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
FranklinAzriel
pushed a commit
to Quixoticly/android_kernel_samsung_mt6765-old
that referenced
this issue
Sep 27, 2024
commit 8d4abca95ecc82fc8c41912fa0085281f19cc29f upstream. Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/ Signed-off-by: Greg Kroah-Hartman <[email protected]>
sfX-bot
pushed a commit
to AXP-OS/android_kernel_samsung_exynos7870
that referenced
this issue
Sep 30, 2024
Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds: arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member _config_ of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header _hdr_. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above). Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy(). This also 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(). Link: KSPP/linux#109 Fixes: dae52d0 ("V4L/DVB: ngene: Initial check-in") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/linux-hardening/20210420001631.GA45456@embeddedor/
fluffball3
pushed a commit
to fluffball3/android_kernel_samsung_m33x
that referenced
this issue
Oct 3, 2024
[ Upstream commit 2d3e5caf96b9449af951e63476657acd759c1a30 ] There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use an anonymous union with a couple of anonymous structs in order to keep userspace unchanged: $ pahole -C ip_msfilter net/ipv4/ip_sockglue.o struct ip_msfilter { union { struct { __be32 imsf_multiaddr_aux; /* 0 4 */ __be32 imsf_interface_aux; /* 4 4 */ __u32 imsf_fmode_aux; /* 8 4 */ __u32 imsf_numsrc_aux; /* 12 4 */ __be32 imsf_slist[1]; /* 16 4 */ }; /* 0 20 */ struct { __be32 imsf_multiaddr; /* 0 4 */ __be32 imsf_interface; /* 4 4 */ __u32 imsf_fmode; /* 8 4 */ __u32 imsf_numsrc; /* 12 4 */ __be32 imsf_slist_flex[0]; /* 16 0 */ }; /* 0 16 */ }; /* 0 20 */ /* size: 20, cachelines: 1, members: 1 */ /* last cacheline: 20 bytes */ }; Also, refactor the code accordingly and make use of the struct_size() and flex_array_size() helpers. 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(). [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: 5c3be3e0eb44 ("ipmr: fix incorrect parameter validation in the ip_mroute_getsockopt() function") Signed-off-by: Sasha Levin <[email protected]>
fluffball3
pushed a commit
to fluffball3/android_kernel_samsung_m33x
that referenced
this issue
Oct 3, 2024
[ Upstream commit db243b796439c0caba47865564d8acd18a301d18 ] There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. Use an anonymous union with a couple of anonymous structs in order to keep userspace unchanged and refactor the related code accordingly: $ pahole -C group_filter net/ipv4/ip_sockglue.o struct group_filter { union { struct { __u32 gf_interface_aux; /* 0 4 */ /* XXX 4 bytes hole, try to pack */ struct __kernel_sockaddr_storage gf_group_aux; /* 8 128 */ /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago --- */ __u32 gf_fmode_aux; /* 136 4 */ __u32 gf_numsrc_aux; /* 140 4 */ struct __kernel_sockaddr_storage gf_slist[1]; /* 144 128 */ }; /* 0 272 */ struct { __u32 gf_interface; /* 0 4 */ /* XXX 4 bytes hole, try to pack */ struct __kernel_sockaddr_storage gf_group; /* 8 128 */ /* --- cacheline 2 boundary (128 bytes) was 8 bytes ago --- */ __u32 gf_fmode; /* 136 4 */ __u32 gf_numsrc; /* 140 4 */ struct __kernel_sockaddr_storage gf_slist_flex[0]; /* 144 0 */ }; /* 0 144 */ }; /* 0 272 */ /* size: 272, cachelines: 5, members: 1 */ /* last cacheline: 16 bytes */ }; $ pahole -C compat_group_filter net/ipv4/ip_sockglue.o struct compat_group_filter { union { struct { __u32 gf_interface_aux; /* 0 4 */ struct __kernel_sockaddr_storage gf_group_aux __attribute__((__aligned__(4))); /* 4 128 */ /* --- cacheline 2 boundary (128 bytes) was 4 bytes ago --- */ __u32 gf_fmode_aux; /* 132 4 */ __u32 gf_numsrc_aux; /* 136 4 */ struct __kernel_sockaddr_storage gf_slist[1] __attribute__((__aligned__(4))); /* 140 128 */ } __attribute__((__packed__)) __attribute__((__aligned__(4))); /* 0 268 */ struct { __u32 gf_interface; /* 0 4 */ struct __kernel_sockaddr_storage gf_group __attribute__((__aligned__(4))); /* 4 128 */ /* --- cacheline 2 boundary (128 bytes) was 4 bytes ago --- */ __u32 gf_fmode; /* 132 4 */ __u32 gf_numsrc; /* 136 4 */ struct __kernel_sockaddr_storage gf_slist_flex[0] __attribute__((__aligned__(4))); /* 140 0 */ } __attribute__((__packed__)) __attribute__((__aligned__(4))); /* 0 140 */ } __attribute__((__aligned__(1))); /* 0 268 */ /* size: 268, cachelines: 5, members: 1 */ /* forced alignments: 1 */ /* last cacheline: 12 bytes */ } __attribute__((__packed__)); 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(). [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays Link: KSPP/linux#79 Link: KSPP/linux#109 Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: 5c3be3e0eb44 ("ipmr: fix incorrect parameter validation in the ip_mroute_getsockopt() function") Signed-off-by: Sasha Levin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Currently, there are 114 of these warnings in next-20201002:
Address all the warnings above in order to enable -Warray-bounds. See:
gcc-10: disable 'array-bounds' warning for now
Detect out of bounds array indexes
The text was updated successfully, but these errors were encountered: