先给结论内核 oops 看着三十几行其实只有四块 —— 标题、全局状态、寄存器、调用栈。定位凶手只需要两个寄存器RIP哪条指令和CR2哪个地址。通用寄存器不能当判据。下面是一次在 qemu 里真实制造出来的空指针崩溃日志原文照录。一、标题区这四行就定了性质BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Oops: Oops: 0002 [#1] PREEMPT SMP NOPTI第一行错在「解引用空指针」访问地址0。第二行supervisor write access——内核态、而且是写。第三行error_code(0x0002)的0x2位就是not-present page第四行的0002是同一件事。★ 是「写」很关键。若源码写的是int v *p;读这里会是0x0000。二、寄存器区两个容易读错的地方RIP: 0010:null_deref_init0x1c/0xff0 [null_deref] RAX: 0000000000000032 RBX: ... RCX: ... CR2: 0000000000000000①RIP带方括号 模块地址且要用函数内偏移。[null_deref]表示这条指令属于模块null_deref。模块的加载基址每次可能不同只有函数名偏移是稳定的内核已经帮你把基址减掉了。②RAX是0x32不是 0 —— 这是本集最反直觉的一点。很多人以为「空指针崩溃寄存器里总该有个 0」于是盯着RAX看。错。看反汇编就明白了2c: c7 04 25 00 00 00 00 ef be ad de movl $0xdeadbeef,0x0编译器编译期就知道那个指针是 NULL直接把地址 0 编进了指令连寄存器都没用。所以RAX是多少都跟这次崩溃无关。③ 可信的是CR2。它是 x86 专门记录「触发缺页的线性地址」的寄存器由 CPU 在投递缺页异常时填写不是软件算出来的。这里是0与标题区首行address: 0000000000000000互相印证。三、两步定位到源码行第一步objdump精确到指令在宿主机上不是 qemu 里objdump-drnull-deref/null_deref.ko|less函数入口是0x100x1c落在0x2c就是上面那条movl $0xdeadbeef,0x0。第二步faddr2line精确到行faddr2line null_deref.ko null_deref_init0x1c# → null_deref_init at .../null_deref.c:27⚠️坑一oops 里印的/0xff0别照抄。那个 size 取自kallsyms模块init函数会把整个 init 段尾都算进去所以虚高faddr2line自己读出来只有/0x33差了近两个数量级。喂faddr2line时只传funcoff去掉斜杠和 size否则被size mismatch拒解。⚠️坑二0x1c这个偏移会变。它由 gcc 版本与内核配置共同决定 —— 同一份源码重编内核后同一条 C 语句的偏移从0x1c变成了0x17。别背偏移背判据objdump -dr里null_deref_init:那段能找到movl $0xdeadbeef,0x0偏移是几都对faddr2line解出来的行号必须指向*p 0xDEADBEEF;。完整的四块结构拆解、40 行可复现模块、vmlinuxnokaslr解核心内核符号、以及两个速查表https://diyallai.com/blog/oops-reading