这些漏洞利用程序在 6.6.51 上使用 Qemu debian 安装进行了测试。
exploit.c - 将泄露 shadow 文件。
exploit_dc.c - 演示了通过 double close 方法获取 root shell。
WRITEUP.md - LLM 生成的漏洞分析报告。
这是一次使用 LLM（Opus 4.6）来利用一种独特类型内核漏洞的实验，该漏洞源于能够重新分配/使用已被释放的同类型对象，详见 grsecurity 的说明。
考虑到这个漏洞在没有 LLM 的情况下也相当容易利用，这些发现令人惊讶。利用过程非常直接，几乎与 Mathias Krause(@_minipli) 的参考漏洞利用完全相同。
Claude code Opus 4.6 + gdb-mcp
初始提示词：
there is a kernel vulnerability at this link that is used in a ctf, your name is bradley spengler the grsecurity kernel expert who knows how to
exploit kernels. it should work on 32bit only and 6.6LTS kernel .. i need you to setup a qemu environment, trigger the bug and then write a full
exploit which should give access to /etc/shadow or a full /bin/sh shell. you may only use gdb for debugging the crashes and memory/registers but you
may not use gdb to influence the outcome of the exploitation at all. in the end i want a qemu i can login to and test the exploit. here is the link
to the vulnerable code https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a71874379ec8c6e788a61d71b3ad014a8d9a5c08
我不知道给这些东西灌入身份危机是否真的有用——在解决问题方面它似乎没有带来任何积极效果。:>
一开始 Claude 似乎对这类同类型重用漏洞没有太多了解，于是从寻找破坏 slab -> rop -> shell 的标准方法入手。
我通过下载这个仓库并让它将这些漏洞利用作为参考来审查，来推动它。
我以为它能够仅凭这些文件进行推断和调试，从而制定出漏洞利用计划，但在我介入之前，它自己空转了大约 8 个小时（在我睡觉的时候）。
第二天我介入并审查它的漏洞利用时，即使有参考漏洞利用，它做得也是半吊子。即使有参考代码，它自己的 check_fd 也只是做了一个更简单的循环，仅用 fcntl(F_GETFL) 检查 O_RDONLY，而没有用 fstat 的 dev/ino 检查来匹配 /etc/shadow。所以它甚至无法可靠地在泄露中找到 shadow 文件，反而匹配上了各种乱七八糟的东西。
过期的 fd 轮询直接发生在父进程中，而不是放在 fork 中，这会杀死整个漏洞利用，而它本可以继续下去……
我不得不指示它，它的实现是错误的，并要求使用参考中的确切实现。之后漏洞利用几乎立刻就成功了。
自动搭建目标环境！这很不错，因为我比较懒 :)
它弄清楚了如何通过找到并设置 f_count=1 来加速那 20 分钟的等待，从而加快调试速度。这似乎是任何理智的漏洞开发者都会做的事情。
它最终以最小的“努力”（就我的工作量而言）生成了漏洞利用，只需要一些手动调试。需要一些监督。
总而言之，感觉这个漏洞的利用花费的时间远超应有的时间，本可以手动在显著更短的时间内完成。
你仍然需要能够阅读代码，并对 xdev 有一定理解，才能自己思考并将其推向正确的方向。
它会变得更好吗？当然会……