[PATCH 0/3] objtool: Fix undefined behaviour reported by UBSan on a defconfig build

[Leizhen Zhang <lzsx618@gmail.com>]

An x86_64 defconfig build of v7.4-rc2 with objtool built with
-fsanitize=address,undefined (GCC 12) gives two UBSan reports from
objtool, both on the normal vmlinux.o pass, no unusual input involved:

  arch/x86/orc.c:11:18: runtime error: member access within null pointer of type 'struct cfi_state'
  special.c:84:18: runtime error: load of misaligned address ... for type 'unsigned int', which requires 4 byte alignment

1/3 fixes the first one: init_orc_entry() takes &cfi->regs[CFI_BP]
before its own "if (!cfi)" check.  2/3 is the same pattern in the
LoongArch copy of the function; I compile-tested objtool for LoongArch
but have no LoongArch object to run it on.  3/3 fixes the second one:
the feature word of a 14-byte packed struct alt_instr is read through
an 'unsigned int *', so every odd-numbered entry is misaligned.

Testing: I relinked vmlinux.o without objtool and ran the old and the
new objtool binary on two copies of it, with the arguments Kbuild uses.
The old one prints both reports, the new one prints none, and the two
resulting vmlinux.o files are byte-identical.  A full rebuild with the
patched objtool is also clean for objtool.

None of this is a security issue: objtool only processes objects from
the build itself.

The two reports were found with UBSan, and the analysis and fixes were
prepared with the help of an AI coding assistant; I reviewed and tested
the result.

Leizhen Zhang (3):
  objtool/x86: Move the cfi->regs access after the NULL check
  objtool/LoongArch: Move the cfi->regs access after the NULL check
  objtool: Fix misaligned load of the alternative feature word

 tools/objtool/arch/loongarch/orc.c | 6 ++++--
 tools/objtool/arch/x86/orc.c       | 4 +++-
 tools/objtool/special.c            | 4 ++--
 3 files changed, 9 insertions(+), 5 deletions(-)


base-commit: 7475ea8b58616b33c04afb976cf0fbaad9dd63fb
-- 
2.34.1