summaryrefslogtreecommitdiffstats
path: root/fs/exfat
diff options
context:
space:
mode:
authorDarrick J. Wong <djwong@kernel.org>2021-07-26 16:43:17 -0700
committerDarrick J. Wong <djwong@kernel.org>2021-07-29 09:27:29 -0700
commit81a448d7b0668ae39c08e6f34a54cc7eafb844f1 (patch)
treecb66bd3f94bd6aa8efd2453a174b2aa311a26d5e /fs/exfat
parent9d110014205cb1129fa570d8de83d486fa199354 (diff)
downloadlinux-stable-81a448d7b0668ae39c08e6f34a54cc7eafb844f1.tar.gz
linux-stable-81a448d7b0668ae39c08e6f34a54cc7eafb844f1.tar.bz2
linux-stable-81a448d7b0668ae39c08e6f34a54cc7eafb844f1.zip
xfs: prevent spoofing of rtbitmap blocks when recovering buffers
While reviewing the buffer item recovery code, the thought occurred to me: in V5 filesystems we use log sequence number (LSN) tracking to avoid replaying older metadata updates against newer log items. However, we use the magic number of the ondisk buffer to find the LSN of the ondisk metadata, which means that if an attacker can control the layout of the realtime device precisely enough that the start of an rt bitmap block matches the magic and UUID of some other kind of block, they can control the purported LSN of that spoofed block and thereby break log replay. Since realtime bitmap and summary blocks don't have headers at all, we have no way to tell if a block really should be replayed. The best we can do is replay unconditionally and hope for the best. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Diffstat (limited to 'fs/exfat')
0 files changed, 0 insertions, 0 deletions