-
Notifications
You must be signed in to change notification settings - Fork 15
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
"copy source size is too small" after LLVM commit 3589cacfa8da89b9b5051e4dba659caa575e6b3f #2007
Comments
struct {
short hci_handledev_class[3];
} sco_sock_getsockopt_old_cinfo;
typeof(__builtin_choose_expr(
sizeof(char), 0,
__builtin_choose_expr(
sizeof(short), 0,
__builtin_choose_expr(sizeof(int), 0,
__builtin_choose_expr(sizeof(long), 0, 0)))))
sco_sock_getsockopt_old___val_gu;
void kmsan_unpoison_memory(void *address) {}
void __attribute__((__error__("copy source size is too small")))
__bad_copy_from();
long copy_to_user(void *from, long n) {
void *addr = from;
long bytes = n;
int sz = __builtin_object_size(addr, 0);
if (__builtin_expect(sz >= 0 && sz < bytes, 0))
__bad_copy_from();
return 0;
}
int sco_sock_getsockopt_old() {
int len;
long __tmp = sco_sock_getsockopt_old___val_gu;
kmsan_unpoison_memory(&__tmp);
len = __tmp;
len = __builtin_choose_expr(
0, 0, ({
typeof(0) __UNIQUE_ID___x1646 = len;
unsigned __UNIQUE_ID___y1647 = sizeof(sco_sock_getsockopt_old_cinfo);
__UNIQUE_ID___x1646 < __UNIQUE_ID___y1647 ? __UNIQUE_ID___x1646 : 0;
}));
copy_to_user(&sco_sock_getsockopt_old_cinfo, len);
return 0;
} GCC 13.2.0:
Clang @ llvm/llvm-project@0cbbcf1:
Clang @ llvm/llvm-project@3589cac:
|
@nathanchance Great! Could you please file this issue in llvm-project? |
Done, thanks! llvm/llvm-project#85647 |
After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size(): In file included from net/bluetooth/sco.c:27: In file included from include/linux/module.h:13: In file included from include/linux/stat.h:19: In file included from include/linux/time.h:60: In file included from include/linux/time32.h:13: In file included from include/linux/timex.h:67: In file included from arch/x86/include/asm/timex.h:6: In file included from arch/x86/include/asm/tsc.h:10: In file included from arch/x86/include/asm/msr.h:15: In file included from include/linux/percpu.h:7: In file included from include/linux/smp.h:118: include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small 244 | __bad_copy_from(); | ^ The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled. len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build. The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before. Cc: stable@vger.kernel.org Closes: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Nathan Chancellor <nathan@kernel.org>
After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size(): In file included from net/bluetooth/sco.c:27: In file included from include/linux/module.h:13: In file included from include/linux/stat.h:19: In file included from include/linux/time.h:60: In file included from include/linux/time32.h:13: In file included from include/linux/timex.h:67: In file included from arch/x86/include/asm/timex.h:6: In file included from arch/x86/include/asm/tsc.h:10: In file included from arch/x86/include/asm/msr.h:15: In file included from include/linux/percpu.h:7: In file included from include/linux/smp.h:118: include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small 244 | __bad_copy_from(); | ^ The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled. len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build. The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before. Cc: stable@vger.kernel.org Closes: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Nathan Chancellor <nathan@kernel.org>
After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size(): In file included from net/bluetooth/sco.c:27: In file included from include/linux/module.h:13: In file included from include/linux/stat.h:19: In file included from include/linux/time.h:60: In file included from include/linux/time32.h:13: In file included from include/linux/timex.h:67: In file included from arch/x86/include/asm/timex.h:6: In file included from arch/x86/include/asm/tsc.h:10: In file included from arch/x86/include/asm/msr.h:15: In file included from include/linux/percpu.h:7: In file included from include/linux/smp.h:118: include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small 244 | __bad_copy_from(); | ^ The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled. len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build. The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before. Cc: stable@vger.kernel.org Closes: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size(): In file included from net/bluetooth/sco.c:27: In file included from include/linux/module.h:13: In file included from include/linux/stat.h:19: In file included from include/linux/time.h:60: In file included from include/linux/time32.h:13: In file included from include/linux/timex.h:67: In file included from arch/x86/include/asm/timex.h:6: In file included from arch/x86/include/asm/tsc.h:10: In file included from arch/x86/include/asm/msr.h:15: In file included from include/linux/percpu.h:7: In file included from include/linux/smp.h:118: include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small 244 | __bad_copy_from(); | ^ The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled. len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build. The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before. Cc: stable@vger.kernel.org Closes: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Patch has been accepted: https://git.kernel.org/bluetooth/bluetooth-next/c/0ef86e9051d7e6f0d56b3a07ad851e4a2a65860d |
Link: ClangBuiltLinux/linux#2007 Link: https://git.kernel.org/bluetooth/bluetooth-next/c/7d80e7ebf9e333dc5463a48a914f55caef15f62f Signed-off-by: Nathan Chancellor <nathan@kernel.org>
After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size(): In file included from net/bluetooth/sco.c:27: In file included from include/linux/module.h:13: In file included from include/linux/stat.h:19: In file included from include/linux/time.h:60: In file included from include/linux/time32.h:13: In file included from include/linux/timex.h:67: In file included from arch/x86/include/asm/timex.h:6: In file included from arch/x86/include/asm/tsc.h:10: In file included from arch/x86/include/asm/msr.h:15: In file included from include/linux/percpu.h:7: In file included from include/linux/smp.h:118: include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small 244 | __bad_copy_from(); | ^ The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled. len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build. The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before. Cc: stable@vger.kernel.org Closes: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size(): In file included from net/bluetooth/sco.c:27: In file included from include/linux/module.h:13: In file included from include/linux/stat.h:19: In file included from include/linux/time.h:60: In file included from include/linux/time32.h:13: In file included from include/linux/timex.h:67: In file included from arch/x86/include/asm/timex.h:6: In file included from arch/x86/include/asm/tsc.h:10: In file included from arch/x86/include/asm/msr.h:15: In file included from include/linux/percpu.h:7: In file included from include/linux/smp.h:118: include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small 244 | __bad_copy_from(); | ^ The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled. len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build. The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before. Cc: stable@vger.kernel.org Closes: ClangBuiltLinux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size(): In file included from net/bluetooth/sco.c:27: In file included from include/linux/module.h:13: In file included from include/linux/stat.h:19: In file included from include/linux/time.h:60: In file included from include/linux/time32.h:13: In file included from include/linux/timex.h:67: In file included from arch/x86/include/asm/timex.h:6: In file included from arch/x86/include/asm/tsc.h:10: In file included from arch/x86/include/asm/msr.h:15: In file included from include/linux/percpu.h:7: In file included from include/linux/smp.h:118: include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small 244 | __bad_copy_from(); | ^ The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled. len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build. The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before. Cc: stable@vger.kernel.org Closes: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This is now resolved in Linus's tree and it should go back to stable automatically. https://git.kernel.org/linus/9bf4e919ccad613b3596eebf1ff37b05b6405307 I will close this issue but leave the upstream report open. |
commit 9bf4e91 upstream. After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size(): In file included from net/bluetooth/sco.c:27: In file included from include/linux/module.h:13: In file included from include/linux/stat.h:19: In file included from include/linux/time.h:60: In file included from include/linux/time32.h:13: In file included from include/linux/timex.h:67: In file included from arch/x86/include/asm/timex.h:6: In file included from arch/x86/include/asm/tsc.h:10: In file included from arch/x86/include/asm/msr.h:15: In file included from include/linux/percpu.h:7: In file included from include/linux/smp.h:118: include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small 244 | __bad_copy_from(); | ^ The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled. len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build. The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before. Cc: stable@vger.kernel.org Closes: ClangBuiltLinux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
I got a message that this has been queued up for the next series of stable releases. |
Source: Kernel.org MR: 172287 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.10.y ChangeID: e844bccad7eebc102b2b48946051ebe6ed314b24 Description: commit 5fe6caa upstream. Commit 9bf4e91 worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e91 ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster@mvista.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Source: Kernel.org MR: 172287 Type: Integration Disposition: Backport from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable linux-5.10.y ChangeID: e844bccad7eebc102b2b48946051ebe6ed314b24 Description: commit 5fe6caa upstream. Commit 9bf4e91 worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e91 ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster@mvista.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Edwiin Kusuma Jaya <kutemeikito0905@gmail.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: onettboots <blackcocopet@gmail.com>
commit 9bf4e919ccad613b3596eebf1ff37b05b6405307 upstream. After an innocuous optimization change in LLVM main (19.0.0), x86_64 allmodconfig (which enables CONFIG_KCSAN / -fsanitize=thread) fails to build due to the checks in check_copy_size(): In file included from net/bluetooth/sco.c:27: In file included from include/linux/module.h:13: In file included from include/linux/stat.h:19: In file included from include/linux/time.h:60: In file included from include/linux/time32.h:13: In file included from include/linux/timex.h:67: In file included from arch/x86/include/asm/timex.h:6: In file included from arch/x86/include/asm/tsc.h:10: In file included from arch/x86/include/asm/msr.h:15: In file included from include/linux/percpu.h:7: In file included from include/linux/smp.h:118: include/linux/thread_info.h:244:4: error: call to '__bad_copy_from' declared with 'error' attribute: copy source size is too small 244 | __bad_copy_from(); | ^ The same exact error occurs in l2cap_sock.c. The copy_to_user() statements that are failing come from l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This does not occur with GCC with or without KCSAN or Clang without KCSAN enabled. len is defined as an 'int' because it is assigned from '__user int *optlen'. However, it is clamped against the result of sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit platforms). This is done with min_t() because min() requires compatible types, which results in both len and the result of sizeof() being casted to 'unsigned int', meaning len changes signs and the result of sizeof() is truncated. From there, len is passed to copy_to_user(), which has a third parameter type of 'unsigned long', so it is widened and changes signs again. This excessive casting in combination with the KCSAN instrumentation causes LLVM to fail to eliminate the __bad_copy_from() call, failing the build. The official recommendation from LLVM developers is to consistently use long types for all size variables to avoid the unnecessary casting in the first place. Change the type of len to size_t in both l2cap_sock_getsockopt_old() and sco_sock_getsockopt_old(). This clears up the error while allowing min_t() to be replaced with min(), resulting in simpler code with no casts and fewer implicit conversions. While len is a different type than optlen now, it should result in no functional change because the result of sizeof() will clamp all values of optlen in the same manner as before. Cc: stable@vger.kernel.org Closes: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Justin Stitt <justinstitt@google.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 92d26492b4acdc05a3ad1f7795b6cae91292b00d) Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Edwiin Kusuma Jaya <kutemeikito0905@gmail.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: onettboots <blackcocopet@gmail.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: onettboots <blackcocopet@gmail.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: onettboots <blackcocopet@gmail.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: KanonifyX <153967762+KanonifyX@users.noreply.github.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
stable inclusion from stable-v6.6.64 commit 19714c9e8885b6580d0e226b07a98dd011b7f5ae category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IBL4B6 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=19714c9e8885b6580d0e226b07a98dd011b7f5ae -------------------------------- commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Wen Zhiwei <wenzhiwei@kylinos.cn>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: KanonifyX <153967762+KanonifyX@users.noreply.github.com>
BugLink: https://bugs.launchpad.net/bugs/2095283 commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e91 worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e91 ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: KanonifyX <153967762+KanonifyX@users.noreply.github.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: KanonifyX <153967762+KanonifyX@users.noreply.github.com>
commit 5fe6caa62b07fd39cd6a28acc8f92ba2955e11a6 upstream. Commit 9bf4e919ccad worked around an issue introduced after an innocuous optimisation change in LLVM main: > len is defined as an 'int' because it is assigned from > '__user int *optlen'. However, it is clamped against the result of > sizeof(), which has a type of 'size_t' ('unsigned long' for 64-bit > platforms). This is done with min_t() because min() requires compatible > types, which results in both len and the result of sizeof() being casted > to 'unsigned int', meaning len changes signs and the result of sizeof() > is truncated. From there, len is passed to copy_to_user(), which has a > third parameter type of 'unsigned long', so it is widened and changes > signs again. This excessive casting in combination with the KCSAN > instrumentation causes LLVM to fail to eliminate the __bad_copy_from() > call, failing the build. The same issue occurs in rfcomm in functions rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old. Change the type of len to size_t in both rfcomm_sock_getsockopt and rfcomm_sock_getsockopt_old and replace min_t() with min(). Cc: stable@vger.kernel.org Co-authored-by: Aleksei Vetrov <vvvvvv@google.com> Improves: 9bf4e919ccad ("Bluetooth: Fix type of len in {l2cap,sco}_sock_getsockopt_old()") Link: ClangBuiltLinux/linux#2007 Link: llvm/llvm-project#85647 Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: KanonifyX <153967762+KanonifyX@users.noreply.github.com>
After llvm/llvm-project@3589cac, I see the following error when building
ARCH=x86_64 allmodconfig
, which enablesCONFIG_KCSAN
(i.e,-fsanitize=thread
):which comes from
check_copy_size()
incopy_to_user()
. I also see the same error emitted innet/bluetooth/l2cap_sock.c
. If I disable CONFIG_KCSAN, there is no error. The parent of 3589cacfa8da89b9b5051e4dba659caa575e6b3f does not show this error and GCC does not show an error either, so I am not sure the kernel code is at fault here but I could be missing something obvious.I tried adding
0 &&
to theif
statements withcopy_to_user()
innet/bluetooth/sco.c
to see if it was one particular statement causing an issue but applying it to eitherif (copy_to_user(optval, (char *)&opts, len))
orif (copy_to_user(optval, (char *)&cinfo, len))
prevents the error from appearing, which seems rather strange to me.I am still working on teasing out a small reproducer. If this seems like an non-Linux kernel specific issue, I am happy to file a report upstream.
cc @dtcxzyw @nikic
The text was updated successfully, but these errors were encountered: