Messages in this thread Patch in this message | | | Date | Wed, 16 Aug 2023 01:08:09 +0200 | From | Peter Zijlstra <> | Subject | [PATCH] x86/static_call: Fix __static_call_fixup() |
| |
Christian reported spurious module crashes after some of Song's module memory layout patches.
Turns out that if the very last instruction on the very last page of the module is a 'JMP __x86_return_thunk' then __static_call_fixup() will trip a fault and dies.
And while the module rework made this slightly more likely to happen, it's always been possible.
Fixes: ee88d363d156 ("x86,static_call: Use alternative RET encoding") Reported-by: Christian Bricart <christian@bricart.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> --- arch/x86/kernel/static_call.c | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c index b70670a98597..2e67512d7104 100644 --- a/arch/x86/kernel/static_call.c +++ b/arch/x86/kernel/static_call.c @@ -186,6 +186,16 @@ EXPORT_SYMBOL_GPL(arch_static_call_transform); */ bool __static_call_fixup(void *tramp, u8 op, void *dest) { + /* + * Not all .return_sites are a static_call trampoline (most are not). + * Check if the next 3 bytes are still kernel text, if not, then this + * definitely is not a trampoline and we need not worry further. + * + * This avoids the memcmp() below tripping over pagefaults etc.. + */ + if (!kernel_text_address(tramp+7)) + return false; + if (memcmp(tramp+5, tramp_ud, 3)) { /* Not a trampoline site, not our problem. */ return false;
| |