fsck_msdosfs: fix 32-bit overflow computing the LOST.DIR offset

reconnect() computed the byte offset of the LOST.DIR cluster in 32-bit
arithmetic and widened the result only on assignment:

	lfoff = (lfcl - CLUST_FIRST) * boot->ClusterSize
	    + boot->FirstCluster * boot->bpbBytesPerSec;

cl_t is u_int32_t and ClusterSize is u_int, so both products wrap modulo
2**32.  Once LOST.DIR's cluster lies past the 4 GiB mark, lfoff aliases
the offset exactly 4 GiB below it, which on such a volume is ordinary
file data.

That offset is used for both the read and the write: reconnect() reads a
cluster of file data, scans it in 32-byte steps for a leading SLOT_EMPTY
or SLOT_DELETED byte, which arbitrary data readily provides, stores the
new directory entry in that slot, and writes the cluster back to the
same wrong place.  Thirty-two bytes of an unrelated file are silently
replaced by a directory entry, and since that entry never reaches the
real LOST.DIR the chain stays lost, so the next run damages another
slot.

Cast to off_t before multiplying.  This was the only cluster-to-offset
conversion multiplying a cluster number by the cluster size; the others
in dir.c and fat.c compute a 32-bit sector number first and widen that,
which cannot overflow because the sector count is itself 32-bit.

The bug was observed in the field on a FAT32 stick where LOST.DIR had
been created after a multi-gigabyte file was copied onto it, corrupting
that file every time the volume was checked.

MFC after:	1 week
Pull Request:	https://github.com/freebsd/freebsd-src/pull/2347

0 files changed, 0 insertions, 0 deletions