For the side channel crowd:

I wrote about how side channels in serialization can theoretically allow breaking ASLR - with a theoretical worst-case example of how a single round trip of deserializing attacker-controlled data, serializing the result again, and sending the re-serialized data to an attacker could leak an entire pointer:
"Pointer leaks through pointer-keyed data structures"
https://googleprojectzero.blogspot.com/2025/09/pointer-leaks-through-pointer-keyed.html

I found a Linux kernel security bug (in AF_UNIX) and decided to write a kernel exploit for it that can go straight from "attacker can run arbitrary native code in a seccomp-sandboxed Chrome renderer" to kernel compromise:
https://googleprojectzero.blogspot.com/2025/08/from-chrome-renderer-code-exec-to-kernel.html

This post includes fun things like:

• a nice semi-arbitrary read primitive combined with an annoying write primitive
• slowing down usercopy without FUSE or userfaultfd
• CONFIG_RANDOMIZE_KSTACK_OFFSET as an exploitation aid
• a rarely-used kernel feature that Chrome doesn't need but is reachable in the Chrome sandbox
• sched_getcpu() usable inside Chrome renderers despite getcpu being blocked by seccomp (thanks to vDSO)

While most vendors ship timely patches for vulnerabilities reported by Project Zero, they don’t always reach users. Today, we’re announcing Reporting Transparency, a new policy to encourage downstream fixes

https://googleprojectzero.blogspot.com/2025/07/reporting-transparency.html

Thrilled to announce my new Project Zero blog post is LIVE! 🎉 I detail my knowledge-driven fuzzing process to find sandbox escape vulnerabilities in CoreAudio on MacOS.

I'll talk about this and the exploitation process next week
@offensive_con

https://googleprojectzero.blogspot.com/2025/05/breaking-sound-barrier-part-i-fuzzing.html