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
