kernel/lib/Kconfig.ubsan, branch linux-6.12.y

ubsan: integer-overflow: depend on BROKEN to keep this out of CI

2025-07-10T14:05:01Z

[ Upstream commit d6a0e0bfecccdcecb08defe75a137c7262352102 ] Depending on !COMPILE_TEST isn't sufficient to keep this feature out of CI because we can't stop it from being included in randconfig builds. This feature is still highly experimental, and is developed in lock-step with Clang's Overflow Behavior Types[1]. Depend on BROKEN to keep it from being enabled by anyone not expecting it. Link: https://discourse.llvm.org/t/rfc-v2-clang-introduce-overflowbehaviortypes-for-wrapping-and-non-wrapping-arithmetic/86507 [1] Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202505281024.f42beaa7-lkp@intel.com Fixes: 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer") Acked-by: Eric Biggers Link: https://lore.kernel.org/r/20250528182616.work.296-kees@kernel.org Reviewed-by: Nathan Chancellor Acked-by: Marco Elver Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

lib/Kconfig.ubsan: Remove 'default UBSAN' from UBSAN_INTEGER_WRAP

2025-05-02T05:58:58Z

commit cdc2e1d9d929d7f7009b3a5edca52388a2b0891f upstream. CONFIG_UBSAN_INTEGER_WRAP is 'default UBSAN', which is problematic for a couple of reasons. The first is that this sanitizer is under active development on the compiler side to come up with a solution that is maintainable on the compiler side and usable on the kernel side. As a result of this, there are many warnings when the sanitizer is enabled that have no clear path to resolution yet but users may see them and report them in the meantime. The second is that this option was renamed from CONFIG_UBSAN_SIGNED_WRAP, meaning that if a configuration has CONFIG_UBSAN=y but CONFIG_UBSAN_SIGNED_WRAP=n and it is upgraded via olddefconfig (common in non-interactive scenarios such as CI), CONFIG_UBSAN_INTEGER_WRAP will be silently enabled again. Remove 'default UBSAN' from CONFIG_UBSAN_INTEGER_WRAP until it is ready for regular usage and testing from a broader community than the folks actively working on the feature. Cc: stable@vger.kernel.org Fixes: 557f8c582a9b ("ubsan: Reintroduce signed overflow sanitizer") Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250414-drop-default-ubsan-integer-wrap-v1-1-392522551d6b@kernel.org Signed-off-by: Kees Cook [nathan: Fix conflict due to lack of rename from ed2b548f1017 in stable] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

x86/traps: Enable UBSAN traps on x86

2024-08-06T11:42:40Z

Currently ARM64 extracts which specific sanitizer has caused a trap via encoded data in the trap instruction. Clang on x86 currently encodes the same data in the UD1 instruction but x86 handle_bug() and is_valid_bugaddr() currently only look at UD2. Bring x86 to parity with ARM64, similar to commit 25b84002afb9 ("arm64: Support Clang UBSAN trap codes for better reporting"). See the llvm links for information about the code generation. Enable the reporting of UBSAN sanitizer details on x86 compiled with clang when CONFIG_UBSAN_TRAP=y by analysing UD1 and retrieving the type immediate which is encoded by the compiler after the UD1. [ tglx: Simplified it by moving the printk() into handle_bug() ] Signed-off-by: Gatlin Newhouse Signed-off-by: Thomas Gleixner Acked-by: Peter Zijlstra (Intel) Cc: Kees Cook Link: https://lore.kernel.org/all/20240724000206.451425-1-gatlin.newhouse@gmail.com Link: https://github.com/llvm/llvm-project/commit/c5978f42ec8e9#diff-bb68d7cd885f41cfc35843998b0f9f534adb60b415f647109e597ce448e92d9f Link: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86InstrSystem.td#L27

ubsan: Restore dependency on ARCH_HAS_UBSAN

2024-05-18T20:46:10Z

While removing CONFIG_UBSAN_SANITIZE_ALL, ARCH_HAS_UBSAN wasn't correctly depended on. Restore this, as we do not want to attempt UBSAN builds unless it's actually been tested on a given architecture. Reported-by: Masahiro Yamada Closes: https://lore.kernel.org/all/20240514095427.541201-1-masahiroy@kernel.org Fixes: 918327e9b7ff ("ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL") Link: https://lore.kernel.org/r/20240514233747.work.441-kees@kernel.org Signed-off-by: Kees Cook

ubsan: Disable signed integer overflow sanitizer on GCC < 8

2024-03-18T18:24:14Z

For opting functions out of sanitizer coverage, the "no_sanitize" attribute is used, but in GCC this wasn't introduced until GCC 8. Disable the sanitizer unless we're not using GCC, or it is GCC version 8 or higher. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202403110643.27JXEVCI-lkp@intel.com/ Reviewed-by: Marco Elver Signed-off-by: Kees Cook

ubsan: Reintroduce signed overflow sanitizer

2024-02-21T04:44:49Z

In order to mitigate unexpected signed wrap-around[1], bring back the signed integer overflow sanitizer. It was removed in commit 6aaa31aeb9cf ("ubsan: remove overflow checks") because it was effectively a no-op when combined with -fno-strict-overflow (which correctly changes signed overflow from being "undefined" to being explicitly "wrap around"). Compilers are adjusting their sanitizers to trap wrap-around and to detecting common code patterns that should not be instrumented (e.g. "var + offset < var"). Prepare for this and explicitly rename the option from "OVERFLOW" to "WRAP" to more accurately describe the behavior. To annotate intentional wrap-around arithmetic, the helpers wrapping_add/sub/mul_wrap() can be used for individual statements. At the function level, the __signed_wrap attribute can be used to mark an entire function as expecting its signed arithmetic to wrap around. For a single object file the Makefile can use "UBSAN_SIGNED_WRAP_target.o := n" to mark it as wrapping, and for an entire directory, "UBSAN_SIGNED_WRAP := n" can be used. Additionally keep these disabled under CONFIG_COMPILE_TEST for now. Link: https://github.com/KSPP/linux/issues/26 [1] Cc: Miguel Ojeda Cc: Nathan Chancellor Cc: Peter Zijlstra Cc: Hao Luo Reviewed-by: Marco Elver Reviewed-by: Justin Stitt Signed-off-by: Kees Cook

ubsan: Remove CONFIG_UBSAN_SANITIZE_ALL

2024-02-06T10:21:38Z

For simplicity in splitting out UBSan options into separate rules, remove CONFIG_UBSAN_SANITIZE_ALL, effectively defaulting to "y", which is how it is generally used anyway. (There are no ":= y" cases beyond where a specific file is enabled when a top-level ":= n" is in effect.) Cc: Andrey Konovalov Cc: Marco Elver Cc: linux-doc@vger.kernel.org Cc: linux-kbuild@vger.kernel.org Signed-off-by: Kees Cook

ubsan: Clarify Kconfig text for CONFIG_UBSAN_TRAP

2023-07-17T23:05:19Z

Make it clearer in the one-line description and the verbose description text that CONFIG_UBSAN_TRAP as currently implemented involves a tradeoff of much less helpful oops messages in exchange for a smaller kernel image. (With the additional effect of turning UBSAN warnings into crashes, which may or may not be desired.) Signed-off-by: Jann Horn Link: https://lore.kernel.org/r/20230705215128.486054-1-jannh@google.com Signed-off-by: Kees Cook

ubsan: remove cc-option test for UBSAN_TRAP

2023-05-17T19:01:54Z

-fsanitize-undefined-trap-on-error has been supported since GCC 5.1 and Clang 3.2. The minimum supported version of these according to Documentation/process/changes.rst is 5.1 and 11.0.0 respectively. Drop this cc-option check. Signed-off-by: Nick Desaulniers Reviewed-by: Nathan Chancellor Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20230407215406.768464-1-ndesaulniers@google.com

ubsan: Tighten UBSAN_BOUNDS on GCC

2023-05-16T20:57:14Z

The use of -fsanitize=bounds on GCC will ignore some trailing arrays, leaving a gap in coverage. Switch to using -fsanitize=bounds-strict to match Clang's stricter behavior. Cc: Marco Elver Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: Nicolas Schier Cc: Tom Rix Cc: Josh Poimboeuf Cc: Miroslav Benes Cc: linux-kbuild@vger.kernel.org Cc: llvm@lists.linux.dev Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20230405022356.gonna.338-kees@kernel.org