In the last years, I wrote up some of the advice I often found myself giving to other founders, and a general list of lessons I learnt doing two companies, zynamics and optimyze. The full article - still work-in-progress - is here:

https://thomasdullien.github.io/guides/entrepreneurship/

[$] KASAN for JIT-compiled BPF code

Alexis Lothoré has been working to add support for the kernel's memory-access checker, KASAN, to just-in-time-compiled BPF code. He spoke about that work at the 2026 Linux Storag [...]

https://lwn.net/Articles/1077740/ #LWN #Linux #kernel #BPF #LSFMMBPF

KASLD v0.3.0 released.

Unprivileged Linux #KASLR derandomization tool that gathers leaks & side-channels and fuses them through a constraint-solving engine into one sound answer for the kernel base — exact where a leak allows, smallest residual window otherwise.

https://github.com/bcoles/kasld

I filed this bug 90 days ago, about how Pixel has an out-of-tree kernel driver that wrongly uses set_page_dirty() instead of set_page_dirty_lock(), leading to UAF:
https://project-zero.issues.chromium.org/494546491

That bug (reachable from some limited contexts like google_camera_app) is currently still unfixed on Pixel.

This isn't the first time I've seen that exact mistake in out-of-tree code; see https://project-zero.issues.chromium.org/42450908 for another such case a few years ago. (Basically, filesystem-related code often already has the page locked and can use set_page_dirty(), but GUP users normally don't hold the page lock and need set_page_dirty_lock().)

This was a fun Linux kernel bug (though it only existed on >=6.10 and requires access to network namespaces): https://project-zero.issues.chromium.org/496923375

One of those rare bugs where, if you pass a kernel address in the right place, with the right setup, the kernel will just read from that kernel address as if it was userspace memory, and give you the data that was read.