Dear Andrey, dear Nick, dear Greg, dear Sasha,
Compiling the kernel with UBSAN enabled and with gcc-8 and later fails when:
commit 1e1b6d63d634 ("lib/string.c: implement stpcpy") is applied, and commit bac7a1fff792 ("lib/ubsan: remove returns-nonnull-attribute checks") is not applied.
To reproduce, run:
tuxmake -r docker -a arm64 -t gcc-13 -k allnoconfig --kconfig-add CONFIG_UBSAN=y
It then fails with:
aarch64-linux-gnu-ld: lib/string.o: in function `stpcpy': string.c:(.text+0x694): undefined reference to `__ubsan_handle_nonnull_return_v1' string.c:(.text+0x694): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `__ubsan_handle_nonnull_return_v1'
Below you find a complete list of architectures, compiler versions and kernel versions that I have tested with.
As commit bac7a1fff792 ("lib/ubsan: remove returns-nonnull-attribute checks") is included in v4.16, and commit 1e1b6d63d634 ("lib/string.c: implement stpcpy") is included in v5.9, this is not an issue that can happen on any mainline release or the stable releases v4.19.y and later.
In the v4.14.y branch, however, commit 1e1b6d63d634 ("lib/string.c: implement stpcpy") was included with v4.14.200 as commit b6d38137c19f and commit bac7a1fff792 ("lib/ubsan: remove returns-nonnull-attribute checks") from mainline was not included yet. Hence, this reported failure with UBSAN can be observed on v4.14.y with recent gcc versions.
Greg, once checked and confirmed by Andrey or Nick, could you please include commit bac7a1fff792 ("lib/ubsan: remove returns-nonnull-attribute checks") into the linux-4.14.y branch?
The commit applies directly, without any change, on v4.14.200 to v4.14.325.
With that, future versions of v4.14.y will have a working UBSAN with the recent gcc compiler versions.
Note: For any users, intending to run UBSAN on versions 4.14.200 to v4.14.325, e.g., for bisecting UBSAN-detected kernel bugs on the linux-4.14.y branch, they would simply need to apply commit bac7a1fff792 on those release versions.
Appendix of my full testing record:
For arm64 and x86-64 architecture, I tested this whole matrix of combinations of building v4.14.200, i.e., the first version that failed with the reported build failure and v4.14.325, i.e., the latest v4.14 release version at the time of writing.
On v4.14.200 and on v4.14.325:
x86_64: gcc-7: unsupported configuration (according to tuxmake) gcc-8: affected and resolved by cherry-picking bac7a1fff792 gcc-9: affected and resolved by cherry-picking bac7a1fff792 gcc-10: affected and resolved by cherry-picking bac7a1fff792 gcc-11: v4.14.200 fails with an unrelated build error on this compiler and arch v4.14.325 affected and resolved by cherry-picking bac7a1fff792 gcc-12: v4.14.200 fails with an unrelated build error on this compiler and arch v4.14.325 affected and resolved by cherry-picking bac7a1fff792 gcc-13: v4.14.200 fails with an unrelated build error on this compiler and arch v4.14.325 affected and resolved by cherry-picking bac7a1fff792 clang-9: unsupported configuration (according to tuxmake) clang-10: not affected, builds with and without cherry-picking bac7a1fff792 clang-17: not affected, builds with and without cherry-picking bac7a1fff792
arm64: gcc-7: unsupported configuration (according to tuxmake) gcc-8: affected and resolved by cherry-picking bac7a1fff792 gcc-9: affected and resolved by cherry-picking bac7a1fff792 gcc-10: affected and resolved by cherry-picking bac7a1fff792 gcc-11: affected and resolved by cherry-picking bac7a1fff792 gcc-12: affected and resolved by cherry-picking bac7a1fff792 gcc-13: affected and resolved by cherry-picking bac7a1fff792 clang-9: unsupported configuration (according to tuxmake) clang-10: not affected, builds with and without cherry-picking bac7a1fff792 clang-17: not affected, builds with and without cherry-picking bac7a1fff792
Best regards,
Lukas