]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
affs: don't write overlarge OFS data block size fields
authorSimon Tatham <anakin@pobox.com>
Thu, 20 Feb 2025 08:14:44 +0000 (08:14 +0000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 10 Apr 2025 12:33:38 +0000 (14:33 +0200)
commit6387243bfec9213efc9d97a16a54b55d7a85bc1e
treeafbbb0981a5aae24ceeea8c318827b04043906a7
parent395041688ba13e5a2b3049915abfde3bbc519c73
affs: don't write overlarge OFS data block size fields

[ Upstream commit 011ea742a25a77bac3d995f457886a67d178c6f0 ]

If a data sector on an OFS floppy contains a value > 0x1e8 (the
largest amount of data that fits in the sector after its header), then
an Amiga reading the file can return corrupt data, by taking the
overlarge size at its word and reading past the end of the buffer it
read the disk sector into!

The cause: when affs_write_end_ofs() writes data to an OFS filesystem,
the new size field for a data block was computed by adding the amount
of data currently being written (into the block) to the existing value
of the size field. This is correct if you're extending the file at the
end, but if you seek backwards in the file and overwrite _existing_
data, it can lead to the size field being larger than the maximum
legal value.

This commit changes the calculation so that it sets the size field to
the max of its previous size and the position within the block that we
just wrote up to.

Signed-off-by: Simon Tatham <anakin@pobox.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fs/affs/file.c