ROP链触发内核Panic：GDB调试状态与崩溃日志存在矛盾

问题场景 #

在x64 Linux内核漏洞利用CTF中，构造ROP链尝试执行commit_creds(prepare_kernel_cred(0))，但出现调试器（pwndbg）显示状态与内核panic日志严重不符的问题：

• 调试流程中，执行pop rdi后RDI被设为0x3039，通过ret跳转到prepare_kernel_cred的第一条指令push rbp处暂停；
• 执行ni单步后立即触发panic，日志存在两个矛盾点：
  • RBP寄存器值为0x3039，但此时尚未执行mov rbp, rdi指令；
  • 崩溃发生在get_task_cred+0x1/0x40，而非预期的push rbp执行后的位置。

补充背景：

• 已验证prepare_kernel_cred地址与/proc/kallsyms完全一致；
• 尝试添加额外ret调整栈对齐，问题未解决；
• 当前内核版本支持prepare_kernel_cred(NULL)调用。

疑问解答 #

1. 为何GDB显示暂停在prepare_kernel_cred的push rbp，单步后却在get_task_cred中崩溃？ #

核心原因是调试器暂停时机与实际指令执行的差异，结合内核函数调用的栈帧行为分析：

• 当ret指令跳转到prepare_kernel_cred的push rbp时，调试器会在指令执行前暂停——此时你看到的是待执行的指令，而非已执行的状态。
• 执行ni后，push rbp会被执行，随后prepare_kernel_cred内部会立即调用get_task_cred（传入你设置的RDI值0x3039）。由于0x3039并非合法的task_struct指针，get_task_cred尝试访问该地址内存时触发页错误，直接导致panic。
• 调试器的回溯信息依赖栈帧完整性，非法指针访问会破坏栈结构，导致panic日志中的崩溃位置看似跳变，实际是栈损坏后的错误回溯。

另外需注意x64内核调用的16字节栈对齐要求：即使添加了额外ret，如果ROP链构造过程中栈的整体偏移出错（比如多/少弹出寄存器），进入prepare_kernel_cred时rsp未对齐，会导致后续函数调用的栈操作出现不可预期的错误，间接引发栈损坏。

2. 为何panic日志中RBP值等于RDI的0x3039，无对应可见执行指令？ #

panic日志中的寄存器值是崩溃瞬间的状态，而非调试暂停时的状态：

• 当get_task_cred访问非法指针0x3039时触发页错误，此时栈已被破坏——get_task_cred的函数开头会执行push rbp; mov rbp, rsp，如果此时rsp指向非法内存区域，push rbp操作会覆盖错误的内存位置，甚至直接篡改RBP的值。
• 另一种可能是，非法指针导致的内存访问错误直接破坏了内核栈中的RBP值，使得panic时捕获的RBP恰好等于传入的0x3039，这是栈损坏后的随机结果，而非由显式的mov rbp, rdi指令执行导致。

建议排查方向 #

• 验证ROP链的栈操作序列：检查所有pop/ret指令是否正确，确保跳转到prepare_kernel_cred时，栈中仅保留后续ROP链的返回地址，无多余数据；
• 替换测试参数：将0x3039换回合法的0（NULL），确认是否仍出现相同问题——若问题消失，说明非法参数导致的内存访问错误是核心原因；
• 检查栈对齐：在跳转到prepare_kernel_cred前，通过info registers rsp确认rsp是否为16字节的倍数，若未对齐，需调整ROP链的指令数量（比如添加额外的pop rbx等无副作用指令）来修正对齐。

内容的提问来源于stack exchange，提问作者Curio