On Thu, Nov 02, 2017 at 04:57:11PM -0500, Josh Poimboeuf wrote: > There have been some cases where external tooling (e.g., kpatch-build) > creates a corrupt relocation which targets the wrong address. This is a > silent failure which can corrupt memory in unexpected places. > > On x86, the bytes of data being overwritten by relocations are always > initialized to zero beforehand. Use that knowledge to add sanity checks > to detect such cases before they corrupt memory. > > Signed-off-by: Josh Poimboeuf <jpoimboe@xxxxxxxxxx> > --- > arch/x86/kernel/module.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c > index 62e7d70aadd5..a69b12617820 100644 > --- a/arch/x86/kernel/module.c > +++ b/arch/x86/kernel/module.c > @@ -172,19 +172,27 @@ int apply_relocate_add(Elf64_Shdr *sechdrs, > case R_X86_64_NONE: > break; > case R_X86_64_64: > + if (*(u64 *)loc != 0) > + goto nonzero; > *(u64 *)loc = val; > break; > case R_X86_64_32: > + if (*(u32 *)loc != 0) > + goto nonzero; > *(u32 *)loc = val; > if (val != *(u32 *)loc) > goto overflow; > break; > case R_X86_64_32S: > + if (*(s32 *)loc != 0) > + goto nonzero; > *(s32 *)loc = val; > if ((s64)val != *(s32 *)loc) > goto overflow; > break; > case R_X86_64_PC32: > + if (*(u64 *)loc != 0) > + goto nonzero; > val -= (u64)loc; > *(u32 *)loc = val; NACK - this last bit is obviously a bug, not sure how it passed my testing without module load failures... -- Josh -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
