Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider: - [Critical] Hashing 0 bytes for `.LC` constants in `.rodata` sections due to `sh_entsize == 0`, leading to livepatch false negatives. - [High] Out-of-bounds read and false positives when referencing `.LC` constants with a non-zero relocation offset. - [Medium] The `.LC*` symbol check is bypassed for section-relative relocations. --
commit fbe33684e2b71a1fc6c9da77412adb627592aa7f Author: Josh Poimboeuf <[email protected]> objtool/klp: Fix checksums for constant pool references This commit fixes false positive changed functions in livepatching caused by changes to .LC* constant names. It does so by adding the underlying data to the checksum calculation instead of the symbol name. > diff --git a/tools/objtool/klp-checksum.c b/tools/objtool/klp-checksum.c > index b8e47f28997e9..359fd27616013 100644 > --- a/tools/objtool/klp-checksum.c > +++ b/tools/objtool/klp-checksum.c > @@ -129,6 +129,14 @@ static void checksum_update_insn(struct objtool_file > *file, struct symbol *func, > goto alts; > } > > + if (strstarts(sym->name, ".LC")) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [Severity: Medium] Will this bypass the check for section-relative relocations? If the compiler emits a section-relative relocation (where `reloc->sym` is a section symbol like `.rodata`) with an addend pointing to the `.LC` constant, this check will fail because the section name doesn't start with ".LC". The code then falls through, resolves the actual `.LC` symbol via find_symbol_containing(), and hashes its name instead of its data. Should this check be placed after is_sec_sym(sym) is processed? > + void *cst; > + > + cst = sym->sec->data->d_buf + sym->offset + offset; > + __checksum_update_insn(func, insn, cst, > sym->sec->sh.sh_entsize); ^^^^^^^^^^^^^^^^^^^^^^^ [Severity: Critical] Does this silently hash 0 bytes for non-mergeable sections like standard `.rodata`? Because standard sections like `.rodata` have an `sh_entsize` of 0, objtool now hashes 0 bytes for these constants. This completely excludes the constant from the checksum. If a vulnerable constant is fixed, the livepatch checksum will not change, and the fix will be silently omitted. [Severity: High] Can this cause an out-of-bounds read and false positives when referencing `.LC` constants with a non-zero relocation offset? If an `.LC` constant in a section with `sh_entsize > 0` (e.g., `.rodata.cst8`) is referenced via a relocation with a non-zero addend (`offset > 0`), the start pointer `cst` is shifted forward by `offset`, but the length parameter remains the full `sh_entsize`. By reading `offset` bytes past the end of the constant, objtool hashes adjacent, unrelated constants. This falsely binds the function's checksum to unrelated data, and if the constant is at the end of the section buffer, it can cause an out-of-bounds read past the allocated `d_buf` boundary. > + goto alts; > + } > + > if (is_sec_sym(sym)) { > sym = find_symbol_containing(reloc->sym->sec, offset); > if (!sym) -- Sashiko AI review ยท https://sashiko.dev/#/patchset/22a92df358195864e83fb4cd16181c5faa63c489.1787889249.git.jpoim...@kernel.org?part=1
