# Linux Kernel Module Cheat

#### 17.6.2. Kernel oops

On oops, the shell still lives after.

However we:

- leave the normal control flow, and `oops after` never gets printed: an interrupt is serviced

- cannot `rmmod oops` afterwards

It is possible to make `oops` lead to panics always with:

    echo 1 > /proc/sys/kernel/panic_on_oops
    insmod oops.ko

An oops stack trace looks like:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    IP: myinit+0x18/0x30 [oops]
    PGD dccf067 P4D dccf067 PUD dcc1067 PMD 0
    Oops: 0002 [#1] SMP NOPTI
    Modules linked in: oops(O+)
    CPU: 0 PID: 53 Comm: insmod Tainted: G           O     4.16.0 #6
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.0-0-g63451fca13-prebuilt.qemu-project.org 04/01/2014
    RIP: 0010:myinit+0x18/0x30 [oops]
    RSP: 0018:ffffc900000d3cb0 EFLAGS: 00000282
    RAX: 000000000000000b RBX: ffffffffc0000000 RCX: ffffffff81e3e3a8
    RDX: 0000000000000001 RSI: 0000000000000086 RDI: ffffffffc0001033
    RBP: ffffc900000d3e30 R08: 69796d2073706f6f R09: 000000000000013b
    R10: ffffea0000373280 R11: ffffffff822d8b2d R12: 0000000000000000
    R13: ffffffffc0002050 R14: ffffffffc0002000 R15: ffff88000dc934c8
    FS:  00007ffff7ff66a0(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 000000000dcd2000 CR4: 00000000000006f0
    Call Trace:
     do_one_initcall+0x3e/0x170
     do_init_module+0x5b/0x210
     load_module+0x2035/0x29d0
     ? SyS_finit_module+0xa8/0xb0
     SyS_finit_module+0xa8/0xb0
     do_syscall_64+0x6f/0x310
     ? trace_hardirqs_off_thunk+0x1a/0x32
     entry_SYSCALL_64_after_hwframe+0x42/0xb7
    RIP: 0033:0x7ffff7b36206
    RSP: 002b:00007fffffffeb78 EFLAGS: 00000206 ORIG_RAX: 0000000000000139
    RAX: ffffffffffffffda RBX: 000000000000005c RCX: 00007ffff7b36206
    RDX: 0000000000000000 RSI: 000000000069e010 RDI: 0000000000000003
    RBP: 000000000069e010 R08: 00007ffff7ddd320 R09: 0000000000000000
    R10: 00007ffff7ddd320 R11: 0000000000000206 R12: 0000000000000003
    R13: 00007fffffffef4b R14: 0000000000000000 R15: 0000000000000000
    Code: <c7> 04 25 00 00 00 00 00 00 00 00 e8 b2 33 09 c1 31 c0 c3 0f 1f 44
    RIP: myinit+0x18/0x30 [oops] RSP: ffffc900000d3cb0
    CR2: 0000000000000000
    ---[ end trace 3cdb4e9d9842b503 ]---

To find the line that oopsed, look at the `RIP` register:

    RIP: 0010:myinit+0x18/0x30 [oops]

and then on GDB:

    ./run-gdb

run

    info line *(myinit+0x18)

which gives us the correct line:

    Line 7 of "/root/linux-kernel-module-cheat/out/kernel_modules/x86_64/kernel_modules/panic.c" starts at address 0xbf00001c <myinit+28> and ends at 0xbf00002c <myexit>.

This-did not work on `arm` due to GDB step debug kernel module insmodded by init on ARM so we need to either:

- GDB module_init

- Kernel module stack trace to source line post-mortem method