[HN Gopher] I used o3 to find a remote zeroday in the Linux SMB ...
       ___________________________________________________________________
        
       I used o3 to find a remote zeroday in the Linux SMB implementation
        
       Author : zielmicha
       Score  : 265 points
       Date   : 2025-05-24 14:25 UTC (8 hours ago)
        
 (HTM) web link (sean.heelan.io)
 (TXT) w3m dump (sean.heelan.io)
        
       | zison wrote:
       | Very interesting. Is the bug it found exploitable in practice?
       | Could this have been found by syzkaller?
        
         | mdaniel wrote:
         | I case anyone else didn't recognize that word:
         | https://github.com/google/syzkaller
        
       | zielmicha wrote:
       | (To be clear, I'm not the author of the post, the title just
       | starts with "How I")
        
       | mdaniel wrote:
       | Noteable:
       | 
       | > o3 finds the kerberos authentication vulnerability in 8 of the
       | 100 runs
       | 
       | And I'd guess this only became a blog post because the author
       | already knew about the vuln and was just curious to see if the
       | intern could spot it too, given a curated subset of the codebase
        
         | moyix wrote:
         | He did do exactly what you say - except right after that, while
         | reviewing the outputs, he found that it had also discovered a
         | _different_ 0day.
        
           | PunchyHamster wrote:
           | Now the question is whether spending same time to analyze
           | that bit of code instead of throwing automated intern at it
           | would be time spent better
        
             | lyu07282 wrote:
             | The time they didn't spend reading the 13k LOCs themselves
             | would've been time spent better.
             | 
             | What?
        
       | Retr0id wrote:
       | The article cites a signal to noise ratio of ~1:50. The author is
       | clearly deeply familiar with this codebase and is thus well-
       | positioned to triage the signal from the noise. Automating _this_
       | part will be where the real wins are, so I 'll be watching this
       | closely.
        
         | tough wrote:
         | I was thinking about this the other day, wouldn't it be
         | feasible to make fine-tune or something like that into every
         | git change, mailist, etc, the linux kernel has ever hard?
         | 
         | Wouldn't such an LLM be the closer -synth- version of a person
         | who has worked on a codebase for years, learnt all its quirks
         | etc.
         | 
         | There's so much you can fit on a high context, some codebases
         | are already 200k Tokens just for the code as is, so idk
        
           | sodality2 wrote:
           | I'd be willing to bet the sum of all code submitted via
           | patches, ideas discussed via lists, etc doesn't come close to
           | the true amount of knowledge collected by the average kernel
           | developer's tinkering, experimenting, etc that never leaves
           | their computer. I also wonder if that would lead to
           | overfitting: the same bugs being perpetuated because they
           | were in the training data.
        
         | andix wrote:
         | 1:50 is a great detection ratio for finding a needle in a
         | haystack.
        
           | epolanski wrote:
           | I don't think the author agrees as he points out the bugs
           | weren't _that_ difficult to find.
        
         | quentinp wrote:
         | Exactly. Many AI users can't triage effectively, as a result
         | open source projects get a lot of spam now:
         | https://arstechnica.com/gadgets/2025/05/open-source-project-...
        
         | ianbutler wrote:
         | We've been working on a system that increases signal to noise
         | dramatically for finding bugs, we've at the same time been
         | thoroughly benchmarking the entire popular software agents
         | space for this
         | 
         | We've found a wide range of results and we have a conference
         | talk coming up soon where we'll be releasing everything
         | publicly so stay tuned for that itll be pretty illuminating on
         | the state of the space
         | 
         | Edit: confusing wording
        
           | sebmellen wrote:
           | Interesting. This is for Bismuth? I saw your pilot program
           | link -- what does that involve?
        
             | ianbutler wrote:
             | Yup! So we have multiple businesses working with us and for
             | pilots its deploying the tool, providing feedback (we're
             | connected over slack with all our partners for a direct
             | line to us), and making sure the uses fit expectations for
             | your business and working towards long term partnership.
             | 
             | We have several deployments in other peoples clouds right
             | now as well as usage of our own cloud version, so we're
             | flexible here.
        
         | manmal wrote:
         | If the LLM wrote a harness and proof of concept tests for its
         | leads, then it might increase S/N dramatically. It's just quite
         | expensive to do all that right now.
        
           | threeseed wrote:
           | Except that in my experience half the time it will modify the
           | implementation in order to make the tests pass.
           | 
           | And it will do this no matter how many prompts you try or you
           | forcefully you ask it.
        
             | moyix wrote:
             | With security vulnerabilities, you don't give the agent the
             | ability to modify the potentially vulnerable software,
             | naturally. Instead you make them do what an attacker would
             | have to do: come up with an input that, when sent to the
             | unmodified program, triggers the vulnerability.
             | 
             | How do you know if it triggered the vulnerability? Luckily
             | for low-level memory safety issues like the ones Sean (and
             | o3) found we have very good oracles for detecting memory
             | safety, like KASAN, so you can basically just let the agent
             | throw inputs at ksmbd until you see something that looks
             | kind of like this: https://groups.google.com/g/syzkaller/c/
             | TzmTYZVXk_Q/m/Tzh7SN...
        
       | Hilift wrote:
       | Does the vulnerability exist in other implementations of SMB?
        
         | p_ing wrote:
         | Implementations of SMB (Windows, Samba, macOS, ksmbd) are going
         | to be different (macOS has a terrible implementation, even
         | though AFP is being deprecated). At this level, it's doubtful
         | that the code is shared among all implementations.
        
       | logifail wrote:
       | My understanding is that ksmbd is a kernel-space SMB server
       | "developed as a lightweight, high-performance alternative" to the
       | traditional (user-space) Samba server...
       | 
       | Q1: Who is using ksmbd in production?
       | 
       | Q2: Why?
        
         | pixl97 wrote:
         | I would assume for the reason of being lightweight and high
         | performance?
        
           | foobar10000 wrote:
           | Smb over 25gbit networks - user space samba is much worse
           | there.
        
             | Henchman21 wrote:
             | This is interesting to me! I regularly deploy 25G network
             | connections, but I don't think we'd run SMB over that. I am
             | super curious the industry and use case if you're willing
             | to share!
        
               | hackernudes wrote:
               | "SMB Direct" is RDMA based and ksmbd supports it. Samba
               | does not. Disclaimer: I have not used it but was looking
               | it up just yesterday.
        
               | Henchman21 wrote:
               | Appreciated, thank you.
        
         | donnachangstein wrote:
         | 1. People that were using the in-kernel SMB server in Solaris
         | or Windows.
         | 
         | 2. Samba performance sucks (by comparison) which is why people
         | still regularly deploy Windows for file sharing in 2025.
         | 
         | Anybody know if this supports native Windows-style ACLs for
         | file permissions? That is the last remaining reason to still
         | run Solaris but I think it relies on ZFS to do so.
         | 
         | Samba's reliance on Unix UID/GID and the syncing as part of its
         | security model is still stuck in the 1970s unfortunately.
         | 
         | The caveat is the in-kernel SMB server has been the source of
         | at least one holy-shit-this-is-bad zero-day remote root hole in
         | Windows (not sure about Solaris) so there are tradeoffs.
        
           | raverbashing wrote:
           | > Samba's reliance on Unix UID/GID and the syncing as part of
           | its security model is still stuck in the 1970s unfortunately.
           | 
           | Sigh. This is why we can't have nice things
           | 
           | Like yeah having smb in kernel is faster but honestly it's
           | not _fundamentally_ faster. But it seems the will to make
           | samba better isn 't there
        
         | AshamedCaptain wrote:
         | Licensing. Samba is GPLv3, Linux is only GPLv2.
        
         | noname120 wrote:
         | The same reason people use kmod-trelay instead of relayd I
         | guess
        
       | iandanforth wrote:
       | The most interesting and significant bit of this article for me
       | was that the author ran this search for vulnerabilities 100 times
       | for each of the models. That's significantly more computation
       | than I've historically been willing to expend on most of the
       | problems that I try with large language models, but maybe I
       | should let the models go brrrrr!
        
         | roncesvalles wrote:
         | A lot of money is all you need~
        
           | bbarnett wrote:
           | A lot of burned coal, is what.
           | 
           | The "don't blame the victim" trope is valid in many contexts.
           | This one application might be "hackers are attacking vital
           | infrastructure, so we need to fund vulnerabilities first".
           | And hackers use AI now, likely hacked into and for free, to
           | discover vulnerabilities. So we must use AI!
           | 
           | Therefore, the hackers are contributing to global warming.
           | We, dear reader, are innocent.
        
             | Balooga wrote:
             | Between $3k and $30k to solve a single ARC-AGI problem [1].
             | Not sure if "100 runs" makes this comparable.
             | 
             | [1] https://techcrunch.com/2025/04/02/openais-o3-model-
             | might-be-...
        
             | sdoering wrote:
             | So basically running a microwave for about 800 seconds, or
             | a bit more than 13 minutes per model?
             | 
             | Oh my god - the world is gonna end. Too bad, we panicked
             | because of exaggerated energy consumption numbers for using
             | an LLM when doing individual work.
             | 
             | Yes - when a lot of people do a lot of prompting, these 0ne
             | tenth of a second to 8 seconds of running the microwave per
             | prompt adds up. But I strongly suggest, that we could all
             | drop our energy consumption significantly using other
             | means, instead of blaming the blog post's author about his
             | energy consumption.
             | 
             | The "lot of burned coal" is probably not that much in this
             | blog post's case given that 1 kWh is about 0.12 kg coal
             | equivalent (and yes, I know that we need to burn more than
             | that for 1kWh. Still not that much, compared to quite a few
             | other human activities.
             | 
             | If you want to read up on it, James O'Donnell and Casey
             | Crownhart try to pull together a detailed account of AI
             | energy usage for MIT Technology Review.[1] I found that
             | quite enlightening.
             | 
             | [1]:
             | https://www.technologyreview.com/2025/05/20/1116327/ai-
             | energ...
        
             | wongarsu wrote:
             | How much longer would OP have needed to find the same
             | vulnerability without LLM help? Then multiply that by the
             | energy used to produce 2000kcal/day of food as well as the
             | electricity for running their computer.
             | 
             | Usually LLMs come out far ahead in those types of
             | calculations. Compared to humans they are quite energy
             | efficient
        
         | JFingleton wrote:
         | Zero days can go for $$$, or you can go down the bug bounty
         | route and also get $$. The cost of the LLM would be a drop in
         | the bucket.
         | 
         | When the cost of inference gets near zero, I have no idea what
         | the world of cyber security will look like, but it's going to
         | be a very different space from today.
        
       | mezyt wrote:
       | Meanwhile, as a maintainer, I've been reviewing more than a dozen
       | false positives slop CVEs in my library and not a single one
       | found an actual issue. This article's is probably going to make
       | my situation worse.
        
         | SamuelAdams wrote:
         | Maybe, but the author is an experienced vulnerability analyst.
         | Obviously if you get a lot of people who have no experience
         | with this you may get a lot of sloppy, false reports.
         | 
         | But this poster actually understands the AI output and is able
         | to find real issues (in this case, use-after-free). From the
         | article:
         | 
         | > Before I get into the technical details, the main takeaway
         | from this post is this: with o3 LLMs have made a leap forward
         | in their ability to reason about code, and if you work in
         | vulnerability research you should start paying close attention.
         | If you're an expert-level vulnerability researcher or exploit
         | developer the machines aren't about to replace you. In fact, it
         | is quite the opposite: they are now at a stage where they can
         | make you significantly more efficient and effective.
        
         | baq wrote:
         | probably not. o3 is not free to use.
        
       | jobswithgptcom wrote:
       | Wow, interesting. I been hacking a tool called
       | https://diffwithgpt.com with a similar angle but indexing git
       | changelogs with qwen to have it raise risks for backward compat
       | issues, risks including security when upgrading k8s etc.
        
       | empath75 wrote:
       | Given the value of finding zero days, pretty much every
       | intelligence agency in the world is going to be pouring money
       | into this if it can reliably find them with just a few hundred
       | api calls. Especially if you can fine tune a model with lots of
       | examples, which I don't think open ai, etc are going to do with
       | any public api.
        
         | treebeard901 wrote:
         | Yeah, the amount of engineering they have around controlling
         | (censoring) the output, along with the terms of service,
         | creates an incentive to still look for any possible bugs, but
         | not allow it in the output.
         | 
         | Certainly for Govt agencies and others this will not be a
         | factor. It is just for everyone else. This will cause people to
         | use other models and agents without these restrictions.
         | 
         | It is safe to assume that a large number of vulnerabilities
         | exist in important software all over the place. Now they can be
         | found. This is going to set off arms race game theory applied
         | to computer security and hacking. Probably sooner than
         | expected...
        
       | akomtu wrote:
       | This made me think that the near future will be LLMs trained
       | specifically on Linux or another large project. The source code
       | is a small part of the dataset fed to LLMs. The more interesting
       | is runtime data flow, similar to what we observe in a debugger.
       | Looking at the codebase alone is like trying to understand a
       | waterfall by looking at equations that describe the water flow.
        
         | baq wrote:
         | it needs to be trained on on enough TLA+ traces, too.
        
       | KTibow wrote:
       | > With o3 you get something that feels like a human-written bug
       | report, condensed to just present the findings, whereas with
       | Sonnet 3.7 you get something like a stream of thought, or a work
       | log.
       | 
       | This is likely because the author didn't give Claude a scratchpad
       | or space to think, essentially forcing it to mix its thoughts
       | with its report. I'd be interested to see if using the official
       | thinking mechanism gives it enough space to get differing
       | results.
        
         | gizmodo59 wrote:
         | Having tried both I'd say o3 is in a league of it's own
         | compared to 3.7 or even Gemini 2.5 pro. The benchmarks may show
         | not a lot of gain but that matters a lot when the task is very
         | complex. What's surprising is that they announced it last
         | November and only now it's released a month back now? (I'm
         | guessing lots of safety took time but no idea). Can't wait for
         | o4!
        
         | iamdanieljohns wrote:
         | Could you provide some links to relevant work/research on using
         | a "scratchpad" that you liked?
        
           | KTibow wrote:
           | I'm not much of an ML engineer but I can point you to the
           | original chain of thought paper [0] and Anthropic's docs on
           | how to enable their official thinking scratchpad [1].
           | 
           | [0] https://arxiv.org/pdf/2201.11903
           | 
           | [1] https://docs.anthropic.com/en/docs/build-with-
           | claude/extende...
        
       | nxobject wrote:
       | A small thing, but I found the author's project-organization
       | practices useful - creating individual .prompt files for system
       | prompt, background information, and auxiliary instructions [1],
       | and then running it through `llm`.
       | 
       | It reveals how good LLM use, like any other engineering tool,
       | requires good engineering thinking - methodical, and oriented
       | around thoughtful specifications that balance design constraints
       | - for best results.
       | 
       | [1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899
        
         | kweingar wrote:
         | How do we benchmark these different methodologies?
         | 
         | It all seems like vibes-based incantations. "You are an expert
         | at finding vulnerabilities." "Please report only real
         | vulnerabilities, not any false positives." Organizing things
         | with made-up HTML tags because the models seem to like that for
         | some reason. Where does engineering come into it?
        
           | nindalf wrote:
           | The author is up front about the limitations of their prompt.
           | They say
           | 
           | > In fact my entire system prompt is speculative in that I
           | haven't ran a sufficient number of evaluations to determine
           | if it helps or hinders, so consider it equivalent to me
           | saying a prayer, rather than anything resembling science or
           | engineering. Once I have ran those evaluations I'll let you
           | know.
        
           | p0w3n3d wrote:
           | Listen to a video made by Karpathy about LLM, he explains why
           | made up html tags work. It's to help the tokenizer
        
           | mrlongroots wrote:
           | I think there's two aspects around LLM usage:
           | 
           | 1. Having workflows to be able to provide meaningful context
           | quickly. Very helpful.
           | 
           | 2. Arbitrary incantations.
           | 
           | I think No. 2 may provide some random amounts of value with
           | one model and not the other, but as a practitioner you
           | shouldn't need to worry about it long-term. Patterns models
           | pay attention to will change over time, especially as they
           | become more capable. No. 1 is where the value is at.
           | 
           | As my example as a systems grad student, I find it a lot more
           | useful to maintain a project wiki with LLMs in the picture.
           | It makes coordinating with human collaborators easier too,
           | and I just copy paste the entire wiki before beginning a
           | conversation. Any time I have a back-and-forth with an LLM
           | about some design discussions that I want archived, I ask
           | them to emit markdown which I then copy paste into the wiki.
           | It's not perfectly organized but it keeps the key bits there
           | and makes generating papers etc. that much easier.
        
           | kristopolous wrote:
           | I usually like fear, shame and guilt based prompting: "You
           | are a frightened and nervous engineer that is very weary
           | about doing incorrect things so you tread cautiously and
           | carefully, making sure everything is coherent and
           | justifiable. You enjoy going over your previous work and
           | checking it repeatedly for accuracy, especially after
           | discovering new information. You are self-effacing and
           | responsible and feel no shame in correcting yourself. Only
           | after you've come up with a thorough plan ... "
           | 
           | I use these prompts everywhere. I get significantly better
           | results mostly because it encourages backtracking and if I
           | were to guess, enforces a higher confidence threshold before
           | acting.
           | 
           | The expert engineering ones usually end up creating mountains
           | of slop, refactoring things, and touching a bunch of code it
           | has no business messing with.
           | 
           | I also have used lazy prompts: "You are positively allergic
           | to rewriting anything that already exists. You have multiple
           | mcps at your disposal to look for existing solutions and
           | thoroughly read their documentation, bug reports, and git
           | history. You really strongly prefer finding appropriate
           | libraries instead of maintaining your own code"
        
             | hollerith wrote:
             | Should be "wary".
        
               | kristopolous wrote:
               | oh interesting, I somehow survived 42 years and didn't
               | know there were 2 words there. I'll check my prompts and
               | give it a go. Thanks.
        
             | gundmc wrote:
             | I find this use of "Catholic" pretty offensive and
             | distasteful.
        
               | kristopolous wrote:
               | yeah I removed it. I grew up catholic, went to catholic
               | school, was an altar boy, and spent decades in the church
               | but whatever, people reading it don't know that.
        
         | threeseed wrote:
         | It's amusing to me how people keep trying to apply engineering
         | principles to an inherently unstable and unpredictable system
         | in order to get a feeling of control.
         | 
         | Those prompts should be renamed as hints. Because that's all
         | they are. Every LLM today ignores prompts if they conflict with
         | its sole overarching goal: to give you an answer no matter
         | whether it's true or not.
        
           | roywiggins wrote:
           | Engineering principles are probably the best we've got when
           | it comes to trying to work with a poorly understood system?
           | That doesn't mean they'll _work_ necessarily, but...
        
           | iknowstuff wrote:
           | Are you using 2023 LLMs? o3 and Gemini 2.5 Pro will gladly
           | say no or declare uncertainty in my experience
        
           | jcims wrote:
           | >people keep trying to apply engineering principles to an
           | inherently unstable and unpredictable system in order to get
           | a feeling of control.
           | 
           | What's the alternative?
        
         | epolanski wrote:
         | The famous engineering practice of vibing as the author himself
         | said:
         | 
         | > I have no idea if this helps, but I'd like it to help, so
         | here we are. In fact my entire system prompt is speculative in
         | that I haven't ran a sufficient number of evaluations to
         | determine if it helps or hinders, so consider it equivalent to
         | me saying a prayer, rather than anything resembling science or
         | engineering
        
       | dehrmann wrote:
       | Are there better tools for finding this? It feels like the sort
       | of thing static analysis should reliably find, but it's in the
       | Linux kernel, so you'd think either coding standards or tooling
       | around these sorts of C bugs would be mature.
        
         | grg0 wrote:
         | Not the expert in the area, but "classic static analysis" (for
         | lack of a better term) and concurrency bugs doesn't really
         | check. There are specific modeling tools for concurrency, and
         | they are an entirely different beast than static analysis that
         | requires notation and language support to describe what threads
         | access what data when. Concurrency bugs in static analysis
         | probably requires a level of context and understanding that an
         | LLM can easily churn through.
        
         | yellow_lead wrote:
         | Some static analysis tools can detect use after free or memory
         | leaks. But since this one requires reasoning about multiple
         | threads, I think it would've been unlikely to be found by
         | static analysis.
        
       | firesteelrain wrote:
       | I really hope this is legit and not what keeps happening to curl
       | 
       | [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-
       | stands-f...
        
       | ape4 wrote:
       | Seems we need something like kernel modules but with memory
       | protection
        
       | martinald wrote:
       | I think this is the biggest alignment problem with LLMs in the
       | short term imo. It is getting scarily good at this.
       | 
       | I recently found a pretty serious security vulnerability in an
       | open source very niche server I sometimes use. This took
       | virtually no effort using LLMs. I'm worried that there is a huge
       | long tail of software out there which wasn't worth finding
       | vulnerabilities in for nefarious means manually but if it was
       | automated could lead to really serious problems.
        
         | tekacs wrote:
         | The (obvious) flipside of this coin is that it allows us to run
         | this adversarially against our own codebases, catching bugs
         | that could otherwise have been found by a researcher, but that
         | we can instead patch proactively.\
         | 
         | I wouldn't (personally) call it an alignment issue, as such.
        
         | Legend2440 wrote:
         | If attackers can automatically scan code for vulnerabilities,
         | so can defenders. You could make it part of your commit
         | approval process or scan every build or something.
        
       | dboreham wrote:
       | I feel like our jobs are reasonably secure for a while because
       | the LLM didn't immediately say "SMB implemented in the kernel,
       | are you f-ing joking!?"
        
       | simonw wrote:
       | There's a beautiful little snippet here that perfectly captures
       | how most of my prompt development sessions go:
       | 
       | > _I tried to strongly guide it to not report false positives,
       | and to favour not reporting any bugs over reporting false
       | positives. I have no idea if this helps, but I'd like it to help,
       | so here we are. In fact my entire system prompt is speculative in
       | that I haven't ran a sufficient number of evaluations to
       | determine if it helps or hinders, so consider it equivalent to me
       | saying a prayer, rather than anything resembling science or
       | engineering. Once I have ran those evaluations I'll let you
       | know._
        
       | davidgerard wrote:
       | This is just fuzzing with extra power consumption?
        
       | fsckboy wrote:
       | > _It is interesting by virtue of being part of the remote attack
       | surface of the Linux kernel._
       | 
       | ...if your linux kernel has ksmbd built into it; that 's a much
       | smaller interest group
        
       ___________________________________________________________________
       (page generated 2025-05-24 23:00 UTC)