Skip to content

Commit ba54d85

Browse files
suryasaimadhuKAGA-KOKO
authored andcommitted
x86/fault: Dump user opcode bytes on fatal faults
Sometimes it is useful to see which user opcode bytes RIP points to when a fault happens: be it to rule out RIP corruption, to dump info early during boot, when doing core dumps is impossible due to not having a writable filesystem yet. Sometimes it is useful if debugging an issue and one doesn't have access to the executable which caused the fault in order to disassemble it. That last aspect might have some security implications so show_unhandled_signals could be revisited for that or a new config option added. Signed-off-by: Borislav Petkov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Andy Lutomirski <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
1 parent e8b6f98 commit ba54d85

File tree

1 file changed

+5
-2
lines changed

1 file changed

+5
-2
lines changed

arch/x86/mm/fault.c

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -828,20 +828,23 @@ static inline void
828828
show_signal_msg(struct pt_regs *regs, unsigned long error_code,
829829
unsigned long address, struct task_struct *tsk)
830830
{
831+
const char *loglvl = task_pid_nr(tsk) > 1 ? KERN_INFO : KERN_EMERG;
832+
831833
if (!unhandled_signal(tsk, SIGSEGV))
832834
return;
833835

834836
if (!printk_ratelimit())
835837
return;
836838

837839
printk("%s%s[%d]: segfault at %lx ip %px sp %px error %lx",
838-
task_pid_nr(tsk) > 1 ? KERN_INFO : KERN_EMERG,
839-
tsk->comm, task_pid_nr(tsk), address,
840+
loglvl, tsk->comm, task_pid_nr(tsk), address,
840841
(void *)regs->ip, (void *)regs->sp, error_code);
841842

842843
print_vma_addr(KERN_CONT " in ", regs->ip);
843844

844845
printk(KERN_CONT "\n");
846+
847+
show_opcodes((u8 *)regs->ip, loglvl);
845848
}
846849

847850
static void

0 commit comments

Comments
 (0)