summaryrefslogtreecommitdiff
path: root/net/xfrm/xfrm_interface_core.c
diff options
context:
space:
mode:
authorNathan Chancellor <nathan@kernel.org>2024-02-21 14:46:21 -0700
committerSteffen Klassert <steffen.klassert@secunet.com>2024-02-26 11:59:40 +0100
commit1a807e46aa93ebad1dfbed4f82dc3bf779423a6e (patch)
tree7c4b6b5e598fc4cfce5d626d23b0cf89ca86c40c /net/xfrm/xfrm_interface_core.c
parent983a73da1f996faee9997149eb05b12fa7bd8cbf (diff)
xfrm: Avoid clang fortify warning in copy_to_user_tmpl()
After a couple recent changes in LLVM, there is a warning (or error with CONFIG_WERROR=y or W=e) from the compile time fortify source routines, specifically the memset() in copy_to_user_tmpl(). In file included from net/xfrm/xfrm_user.c:14: ... include/linux/fortify-string.h:438:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] 438 | __write_overflow_field(p_size_field, size); | ^ 1 error generated. While ->xfrm_nr has been validated against XFRM_MAX_DEPTH when its value is first assigned in copy_templates() by calling validate_tmpl() first (so there should not be any issue in practice), LLVM/clang cannot really deduce that across the boundaries of these functions. Without that knowledge, it cannot assume that the loop stops before i is greater than XFRM_MAX_DEPTH, which would indeed result a stack buffer overflow in the memset(). To make the bounds of ->xfrm_nr clear to the compiler and add additional defense in case copy_to_user_tmpl() is ever used in a path where ->xfrm_nr has not been properly validated against XFRM_MAX_DEPTH first, add an explicit bound check and early return, which clears up the warning. Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1985 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Diffstat (limited to 'net/xfrm/xfrm_interface_core.c')
0 files changed, 0 insertions, 0 deletions