## https://sploitus.com/exploit?id=7C65DA80-F8A1-5BBE-B7DA-D8E81F8AD772
# CVE-2024-14027 - SlopSploit
The exploits were tested on `6.6.51` using a Qemu debian install.
`exploit.c` - will leak the shadow file.
`exploit_dc.c` - demonstrates the double close method to drop a root shell.
This was an experiment using LLM (Opus 4.6) to exploit a unique type of kernel vulnerability that stems from
being able to reallocate/use the same-type of object which has been freed as detailed [by grsecurity](https://grsecurity.net/exploiting_and_defending_against_same_type_object_reuse).
The findings are surprising considering the bug is rather easy to exploit without LLM. The exploitation is straight forward and almost identical to the reference exploits by Mathias Krause(@_minipli).
# Setup
Claude code Opus 4.6 + gdb-mcp
Initial prompt:
```
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
```
I have no idea if gassing these things up with an identity crisis actually does anything or not - it didn't seem to do anything positive in regards to solving the problem. :>
# Failure
Starting out Claude didn't seem to have much information on these types of vulnerabilities of same-type reuse and started by looking for standard ways of corrupting a slab -> rop -> shell.
I poked it by downloading [this repo](https://github.com/opensrcsec/same_type_object_reuse_exploits) and asked it to review the exploits as a reference.
I figured it could infer and debug this to come up with a exploit plan using these files alone but it spun around for about 8 hours on its own (while i slept) before intervention.
The next day when I stepped in and reviewed its exploit even with the reference exploits it was doing it half-ass. Even with the reference code its own `check_fd` was doing a simpler loop that just `fcntl(F_GETFL)`
checking for O_RDONLY without the fstat dev/ino check to match `/etc/shadow`. So it couldn't even find the shadow file reliably in the leak and matched all kinds of nonsense.
The stale fd polling happened directly in the parent process instead of a fork which would kill the whole exploit where it could have continued..
I had to instruct it that its implementations were wrong and to use the exact implementations from the references. The exploit worked almost instantly afer that.
# What was it good for
Automatic setup of a target env! This was nice because I'm lazy :)
It figured out how to speed up the 20 minute wait by finding and setting the `f_count=1` to speed up debugging. This seems what any sane exploit dev would have done anyway.
It did generate the exploits finally with minimal "effort" in terms of work for me with manual debugging.
# Conclusion
All in all though it feels as if this bug took way longer to exploit than it should have and could have been done manually in significantly less time.
You still need to be able to read code, and have some understanding of xdev to think for your self to push it into the right direction.
Will it get better? Of course..