exploits.club Weekly Newsletter 86 - KSMBD 0Clicks, Apple Ends Memory Corruption, Mini-Kernels in Zig, And More

Write a weekly newsletter, they said. It will be fun, they said....Annnnnnyway π
In Case You Missed It...
- OrangeCon 2025 Videos Online - Hours of new content...go check it out!
- DistrictCon CFP Still Open - Get em in by the end of the month!
Resources And Write-Ups From This Week:
- Eternal-Tux: Crafting a Linux Kernel KSMBD 0-Click RCE Exploit from N-Days - There is just something about 0-click RCEs that gets the adrenaline flowing. And it seems like Will from @cor_ctf agrees. As an exercise, he spent some time this summer looking at building a stable exploit for ksmbd N-Days. The post starts with how he chose what bugs to target, picking out a nice slub overflow and a leak. After a quick RCA on these bugs, the post then moves into a crash course on ksmbd and an overview of some previous research on the topic from Thalium. Because of updates to the subsystem, much of this previous research proved to no longer be viable when it comes to exploit strategy, and so the post outlines the new and improved strategy. From there, it is pure exploit dev walking through the exploit code and explaining each key detail.
- Hacking Randomized Linux Kernel Images at the DEF CON 33 Car Hacking Village - This year at DEFCON, Red Balloon Security brought 3 CTF challenges to Car Hacking Village. In their newest blog post, the team discusses these challenges, walking through the intended solution for each. The first was a firmware reversing challenge that involved bruteforcing a repeating key XOR ciphertext. The second challenge was a pretty straightforward stack overflow. And then we get to the third challenge which turns up the difficulty dial by quite a bit. For this one, all syscalls are randomized. The challenge requires a ROP chain to call mprotect but we don't know the corresponding syscall number. As such, a bit of brute force is required to pull of a successful exploit.
- Memory Integrity Enforcement: A complete vision for memory safety in Apple devices - Apple is once again trying to take the fun out of vuln research. The team released a post last week detailing Memory Integrity Enforcement (MIE), which they describe as "the culmination of an unprecedented design and engineering effort, spanning half a decade, that combines the unique strengths of Apple silicon hardware with our advanced operating system security to provide industry-first, always-on memory safety protection across our devices". First, the write-up tackles all the dedicated efforts Apple has made to improve memory safety over the years ranging from Swift to secure kernel memory allocators to PAC. The post then talks about MTE, some of the inherent weaknesses with ARM's approach, and Apple's revised spec, introduced as EMTE in 2022. The team then explains how this EMTE update, paired with secure memory allocators and tag confidentiality enforcement, has come together in a brand new memory safety effort. The rest of the post digs deeper into the specifics, benchmarking these mitigations against common bug classes and real in-the-wild exploit chains.
- Race Against Time in the Kernelβs Clockwork - Earlier this month, CVE-2025-38352 was released in the Android Security Bulletin and marked as possibly under limited, targeted exploitation. Well, that was all the permission our friend @streypaws needed in order to deep dive on the bug in question. The post starts with an overview of the POSIX CPU Timer Subsystem where the bug resides, providing readers with all the background knowledge needed to understand the root cause of the bug. From there, we move to patch analysis and RCA, taking a look at the diff, understanding the path to the vulnerable code, and understanding the race condition that allows for a safety check to be bypassed. Finally, the post goes into setting up a test env and triggering the bug.
- corCTF 2025 - corphone - If that last Android post had you craving more, then never fear - @u1f383 came through with some additional goodies. In this new post, they walk us through a corCTF 2025 Android LPE challenge. The core vulnerability is a race condition to UAF in a device driver. This manifests in a subtle way, where a lock is obtained, then briefly dropped, before being obtained again, leading to a small race where an entry could be freed during the time the lock is not being held. Next, we talk exploitation. Here is where you get some real, practical tips on Android exploitation, as the post walks through turning the initial primitive into a page UAF, hijacking the page table, bypassing SELinux, and getting root.
- Writing an operating system kernel from scratch - We have a confession...We are suckers for a good homebrew operating system. This week, @popovicu94 released a post about his "minimal proof of concept time-sharing operating system on RISC-V". Color us intrigued. The rest of the post walks through the design for this project: virtualization, threads, memory, permission models, I/O...the whole shebang. Not only that, but it's implemented in Zig, which just makes things more fun all the way around. High recommend checking this one out.
- Out-of-bound read in ANGLE CopyNativeVertexData from Compromised Renderer - A quick hitter ANGLE bug from @qriousec. The write-up opens with an explanation on how ANGLE works, and then a top-down view of the WebGL API, highlighting key components of the attack surface. The post then details some previous ANGLE bugs, and how Google tried to add checks to mitigate them. One thing they did not consider in these checks is the attack surface from a compromised renderer. As such, the team was able to identify an offset integer underflow which could be used to trigger an OOB read. They were able to escalate this to an arbitrary read, which let them leak the heap address of the GPU process.
Interesting Job Postings:
- Senior Cryptography Researcher @ NCC Group (Remote: US)
- Senior Security Firmware Engineer @ Sandisk (On-Site: Irvine, CA)
- Senior Reverse Engineer - Anti-Cheat @ Embark Studios (On-Site: Stockholm, Sweden)
- Vulnerability Researcher @ Two Six Technologies (On-Site: Arlington, VA)
- Product Security Engineer, Native @ Meta (On-Site: New York, NY)
Wrapping Up:
As always, thanks for stopping by. We here at the club are always trying to improve so if you have comments, questions, or suggestions, feel free to shoot us an email - info@exploits.club.
Follow us on X - we occasionally Tweet poor attempts at memes
Want to support us? Buy us a coffee βοΈ
Don't forget to check out https://bug.directory!

Feel free to join the exploits.club Discord server here π https://discord.gg/2dxN2Gtgpx
Same time next week? See you then π΄ββ οΈ
