> (Some have already landed.)

Do you have links to some of these?

Accepted by maintainers so far:

In mainline:

ext4, xattr cache: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

ocfs2, cluster accounting: 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: https://lore.kernel.org/all/20260923153220.777907-1-matthias...

A hang in a fix Jan had just written, which he is folding into it: https://lore.kernel.org/all/20260923153134.771632-1-matthias...

A bug Jan fixed himself after my report: 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: 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. 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. 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. https://lore.kernel.org/all/20260922153931.1976405-1-matthia...

Sashiko was reviewing ext4 patches against a tree from 2020: https://github.com/sashiko-dev/sashiko/issues/559, fix in https://github.com/sashiko-dev/sashiko/pull/560, plus a one-line MAINTAINERS patch naming the ext4 branch, which Jan acked: 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.