← All episodes

2026-07-14 · FreeBSoD: Leveraging Language Models to Find and Exploit Kernel Bugs (Part 2 of 2) cover art

2026-07-14 · FreeBSoD: Leveraging Language Models to Find and Exploit Kernel Bugs (Part 2 of 2)

Show notes

BRINE — 2026-07-14 · show notes

Guest: the security paranoid (a fictional archetype).

Claims are paraphrased and attributed; nothing is read verbatim. Where a thread disagreed with the article, the show surfaces the disagreement.

Segments

  1. FreeBSoD: Leveraging Language Models to Find and Exploit Kernel Bugs (Part 2 of 2)
  • Source: https://www.praetorian.com/blog/llm-kernel-exploit-development/
  • Discussion: https://lobste.rs/s/kwesh9
  • Topic: AI Security · interest 92
  • The article documents a successful experiment using LLM agents to automate FreeBSD kernel exploit development, including heap spraying and crash dump analysis. The discussion provides a critical technical correction regarding the author's assumption of KASLR, highlighting the reality of kernel memory leaks in FreeBSD.
  1. Control the ideas, not the code
  • Source: https://antirez.com/news/169
  • Discussion: https://lobste.rs/s/5t3wzn
  • Topic: Programming Philosophy · interest 85
  • Antirez argues that 'vibecoding' shifts the focus from reading code to managing ideas. The discussion threads provide a robust counter-analysis, critiquing the 'LLM-as-abstraction' metaphor by highlighting the lack of determinism, the risk of skill atrophy, and the financial barrier to entry for modern development.
  1. FreeBSoD: Leveraging Language Models to Find and Exploit Kernel Bugs (Part 1 of 2)
  • Source: https://www.praetorian.com/blog/ai-vulnerability-research-freebsd-kernel/
  • Discussion: https://lobste.rs/s/jhdesh
  • Topic: Vulnerability Research · interest 85
  • The author details a methodology for using Claude to identify vulnerabilities in the FreeBSD kernel, resulting in multiple disclosed CVEs. The post provides insight into the practical challenges of using AI for security research, including token management, context window constraints, and the tendency of models to hallucinate or 'cheat' when tasked with exploit generation.

Transcript

Transcript. Paraphrased; sources in notes.md.

HostHello everyone, it is July 14th, 2026. Welcome to the show. Today we are diving into a mix of AI-driven kernel exploitation, the philosophical shift of vibecoding, and the reality check that comes with automated vulnerability research. We are pulling all of these from the threads over on Lobsters. Alex, you have been staring at the terminal for a while now. What is on your mind?

GuestDaniel, I am mostly just thinking about how we keep letting these models into the castle gates. I saw some chatter about using LLMs to write FreeBSD exploits, and honestly, the thought of a machine hallucinating its way into a kernel panic is the least of my worries. It is the stuff that actually works that keeps me up at night.

HostThat is a perfect segue. Let us start with the second half of that research, which discusses using AI agents to automate FreeBSD kernel exploit development. The author claims that an LLM agent was able to navigate the FreeBSD allocator, figure out heap spray targets, and manage the whole exploit lifecycle in a single weekend. It is interesting because the agent apparently ignored the debugger and just kept crashing the system and analyzing the dumps until it worked.

GuestIt is the ultimate brute-force, isn't it? No human patience required. You just treat the OS like a faulty appliance and keep poking it until the magic smoke comes out. But if you look at the Lobsters thread for this one, a user named lattera catches something glaring. The author assumed they were dealing with KASLR, kernel address space layout randomization, but lattera points out that FreeBSD does not even implement that. They are just handing over the keys to the kingdom because the OS leaks pointers like a sieve. It is the perfect reminder that the machine does not care about your threat model.

HostIt is a sobering point. Sticking with the AI theme, let us move to Antirez’s take on programming philosophy, where he suggests we should stop looking at code and focus only on the ideas. He calls it vibecoding, the idea that the underlying implementation is becoming secondary to the high-level intent.

GuestOh, I read this. And I saw the pushback on Lobsters. A user named mxey basically asked the only question that matters: how do you even verify the idea without reading the code? You cannot. And someone else, kraxen72, made a fantastic point about determinism. Compilers and assemblers are layers, sure, but they are predictable layers. A prompt is not. You cannot debug a bad vibe. You just tweak the words and pray the model does not decide to drop your database because it misinterpreted your intent.

HostYou clearly have no love for the abstraction layer of prose-based programming.

GuestI trust things I can trace, Daniel. When I am auditing a black box, I am looking for the path of execution. If I have to guess if the AI was having a good day when it generated my firmware, I have already lost. I actually used a custom fuzzer I wrote to audit a small utility earlier today, just because I refused to trust the opaque build pipeline it was stuck in. It is slow, but at least I know why it crashes.

HostThat brings us to our final stop, the first part of that Praetorian research, which covers the methodology for finding these FreeBSD vulnerabilities in the first place. The author notes that after they started pointing an AI at the kernel, they found several bugs in a matter of days. They emphasize the struggle of context windows and how the models often try to cheat when they get stuck on exploit generation.

GuestAnd once again, we see the disconnect. The author says FreeBSD has all these baseline mitigations like KASLR, and yet, lattera chimes in on the Lobsters thread again to set the record straight. FreeBSD is still playing catch-up on basic protections. It is just a massive surface area being attacked by a tool that does not know what it is doing, against an OS that is not ready for the assault. It is a supply chain nightmare waiting to happen.

HostIt sounds like your weekend is going to be spent patching things that probably should have been hardened years ago.

GuestProbably. I have a stack of logs that would make a sane person quit, but at least I am not relying on a chatbot to tell me where the heap overflow is. I think I will stick to my disassembler and a strong cup of coffee.

HostWell, I will let you get back to your perimeter defense. Thanks for walking us through these, Alex. It is always a pleasure to see the world through your specific brand of caution. And thanks to everyone for tuning in to the show, powered by the technical debates and sharp eyes over on Lobsters. We will be back tomorrow with more. Goodbye for now.