Data-only attacks are somewhat low-hanging fruit. Classical static analysis could already find them before AI got this strong, and LLMs make identification even easier. But the real threat is risk buried in business logic, especially abuse of normal business logic. Take e-commerce refund abuse. Bug hunters would not even call it a risk, yet fraud rings have arbitraged millions off this kind of logic. And because the logic is legitimate business logic, it is very hard to detect.
'Classic' non-AI fuzzers like AFL are still insanely useful and powerful, as are static analysis tools.
LLMs make all of these much, much easier to use. The other night, before I went to bed I told Kimi to go and fuzz filesystem code in the latest Linux kernel. I woke up to 26 crashes with reproducers and fixes. I'm still busy reviewing and upstreaming them. (Some have already landed.)
Taken into Jan Kara's filesystem tree this week, all isofs:
An out-of-bounds read in the multi-extent directory walk: <a href="https://lore.kernel.org/all/20260923153220.777907-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260923153220.777907-1-matthias...
A hang in a fix Jan had just written, which he is folding into it: <a href="https://lore.kernel.org/all/20260923153134.771632-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260923153134.771632-1-matthias...
A bug Jan fixed himself after my report: <a href="https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git/commit/?h=for_next&id=3c01d92636835" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-f...
Sashiko, the LLM patch reviewer that now comments on kernel mailing lists, merged a fix of mine: <a href="https://github.com/sashiko-dev/sashiko/pull/556" rel="nofollow">https://github.com/sashiko-dev/sashiko/pull/556 (a patch that contained one of its prompt placeholders as text had it replaced).
Not accepted yet, but I think interesting:
libata, reviewed by the maintainer but not applied yet: a faulty ATAPI device could make the kernel write past its sense buffer. <a href="https://lore.kernel.org/all/20260922182655.2423663-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260922182655.2423663-1-matthia...
e2fsck, the repair tool, could deadlock on some corrupt images and hang forever. Reviewed by Darrick Wong. <a href="https://lore.kernel.org/all/20260922110435.1528332-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260922110435.1528332-1-matthia...
ntfs: a crafted image makes mount hang forever, because the mount waits on a lock its own read already holds. One of the maintainers asked for a wider fix, which I am testing. <a href="https://lore.kernel.org/all/20260922153931.1976405-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260922153931.1976405-1-matthia...
Sashiko was reviewing ext4 patches against a tree from 2020: <a href="https://github.com/sashiko-dev/sashiko/issues/559" rel="nofollow">https://github.com/sashiko-dev/sashiko/issues/559, fix in <a href="https://github.com/sashiko-dev/sashiko/pull/560" rel="nofollow">https://github.com/sashiko-dev/sashiko/pull/560, plus a one-line MAINTAINERS patch naming the ext4 branch, which Jan acked: <a href="https://lore.kernel.org/all/20260923101749.3505886-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260923101749.3505886-1-matthia...
Not posted yet, still being reviewed on my side:
ntfs: writing to a compressed file on a volume whose free space is fragmented silently overwrote clusters belonging to other files. write() reported success; the damage only showed after a remount.
ntfs: reads of a damaged file could return zeros for data that is on disk, and writes to it could be dropped.
Sashiko: on its Claude, Vertex and Gemini backends, a connection that drops mid-response is treated as a permanent error rather than retried.
The rest, mostly more ntfs, are still in review or on my desk. Not all of these came from that first night; the ext4 and ocfs2 ones are older.
I also have a lot of bcachefs contributions, but that's because I'm actively using that filesystem on my desktop; instead of a pure fuzzing run.
mgaldys4 · · focus · HN ↗
eru · · focus · HN ↗
'Classic' non-AI fuzzers like AFL are still insanely useful and powerful, as are static analysis tools.
LLMs make all of these much, much easier to use. The other night, before I went to bed I told Kimi to go and fuzz filesystem code in the latest Linux kernel. I woke up to 26 crashes with reproducers and fixes. I'm still busy reviewing and upstreaming them. (Some have already landed.)
wavemode · · focus · HN ↗
Do you have links to some of these?
eru · · focus · HN ↗
In mainline:
ext4, xattr cache: <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54b6bd40898de" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
ocfs2, cluster accounting: <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=621c2bcb87548" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Taken into Jan Kara's filesystem tree this week, all isofs:
An out-of-bounds read in the multi-extent directory walk: <a href="https://lore.kernel.org/all/20260923153220.777907-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260923153220.777907-1-matthias...
A hang in a fix Jan had just written, which he is folding into it: <a href="https://lore.kernel.org/all/20260923153134.771632-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260923153134.771632-1-matthias...
A bug Jan fixed himself after my report: <a href="https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git/commit/?h=for_next&id=3c01d92636835" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-f...
Sashiko, the LLM patch reviewer that now comments on kernel mailing lists, merged a fix of mine: <a href="https://github.com/sashiko-dev/sashiko/pull/556" rel="nofollow">https://github.com/sashiko-dev/sashiko/pull/556 (a patch that contained one of its prompt placeholders as text had it replaced).
Not accepted yet, but I think interesting:
libata, reviewed by the maintainer but not applied yet: a faulty ATAPI device could make the kernel write past its sense buffer. <a href="https://lore.kernel.org/all/20260922182655.2423663-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260922182655.2423663-1-matthia...
e2fsck, the repair tool, could deadlock on some corrupt images and hang forever. Reviewed by Darrick Wong. <a href="https://lore.kernel.org/all/20260922110435.1528332-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260922110435.1528332-1-matthia...
ntfs: a crafted image makes mount hang forever, because the mount waits on a lock its own read already holds. One of the maintainers asked for a wider fix, which I am testing. <a href="https://lore.kernel.org/all/20260922153931.1976405-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260922153931.1976405-1-matthia...
Sashiko was reviewing ext4 patches against a tree from 2020: <a href="https://github.com/sashiko-dev/sashiko/issues/559" rel="nofollow">https://github.com/sashiko-dev/sashiko/issues/559, fix in <a href="https://github.com/sashiko-dev/sashiko/pull/560" rel="nofollow">https://github.com/sashiko-dev/sashiko/pull/560, plus a one-line MAINTAINERS patch naming the ext4 branch, which Jan acked: <a href="https://lore.kernel.org/all/20260923101749.3505886-1-matthias.goergens@gmail.com/" rel="nofollow">https://lore.kernel.org/all/20260923101749.3505886-1-matthia...
Not posted yet, still being reviewed on my side:
ntfs: writing to a compressed file on a volume whose free space is fragmented silently overwrote clusters belonging to other files. write() reported success; the damage only showed after a remount.
ntfs: reads of a damaged file could return zeros for data that is on disk, and writes to it could be dropped.
Sashiko: on its Claude, Vertex and Gemini backends, a connection that drops mid-response is treated as a permanent error rather than retried.
The rest, mostly more ntfs, are still in review or on my desk. Not all of these came from that first night; the ext4 and ocfs2 ones are older.
I also have a lot of bcachefs contributions, but that's because I'm actively using that filesystem on my desktop; instead of a pure fuzzing run.