sashiko

t 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.