Re: [PATCH v2 1/2] adfs: reject disc records smaller than one filesystem block

[Samuel Moelius]

On Mon, Jun 29, 2026 at 7:34 AM Russell King <linux@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, Jun 29, 2026 at 07:07:57AM -0400, Samuel Moelius wrote:
> > On Sun, Jun 28, 2026 at 7:17 PM Russell King <linux@xxxxxxxxxxxxxxx> wrote:
> > >
> > > On Sun, Jun 28, 2026 at 10:01:25PM +0000, Samuel Moelius wrote:
> > > > ADFS uses the on-disk disc size to report statfs block counts.  The disc
> > > > record validator checks the sector size, id length, high disc-size bits,
> > > > map zone count, and reserved bytes, but it accepts a declared disc size
> > > > smaller than one filesystem block.
> > > >
> > > > A crafted one-zone image with log2secsize 9 and disc_size 1 can pass map
> > > > checksum validation and mount.  A subsequent statfs then reports zero
> > > > f_blocks from adfs_map_statfs(), and adfs_statfs() divides by that zero
> > > > while deriving f_ffree.
> > >
> > > I think this is still too low.
> > >
> > > 1. The disc map is nzones sectors long, and can not be in the same
> > > sector as the boot block. The disc record can not share with the map.
> > > This means the minimum is 1 + nzones sectors to fit just the map in.
> > >
> > > 2. If the disc record was found at 0xc00 rather than 0, then that
> > > will add sectors to the minimum size.
> > >
> > > 3. The root directory is also necessary, which is 2048 bytes for an
> > > E/F format (format_version=0) or root_size for an F+ format.
> > >
> > > So, if we're really trying to avoid mounting something that isn't a
> > > proper image, then just checking that the disc size is at least one
> > > sector isn't sufficient.
> >
> > I understand your points, but the intent of this patch was simply to
> > eliminate a divide-by-zero. Is it sufficient for that purpose?
>
> While it is, you are also introducing selftests that rely on your
> behaviour, where you merge the disc record with the map for both
> of your test cases. This should also be rejected, because the bytes
> in the disc record will be interpreted as the disc map.
>
> Have you checked what happens if you attempt to access such a bad
> image, or are you purely focussed on what an AI bot told you was
> a problem, rather than looking at the bigger picture?

I have not attempted to access the bad image. And to be clear, the
selftest was an attempt to address Kees Cook's request here:
https://lore.kernel.org/all/202606101323.0DFB06B054@keescook/

> Can you create a tools/testing/selftests/ script that will generate a
> good and bad image and attempt to mount both, validating the filesystem
> checking logic you're adding here?

Would another approach be better?