https://github.com/torvalds/linux
Revision 81a448d7b0668ae39c08e6f34a54cc7eafb844f1 authored by Darrick J. Wong on 26 July 2021, 23:43:17 UTC, committed by Darrick J. Wong on 29 July 2021, 16:27:29 UTC
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>
1 parent 9d11001
History
Tip revision: 81a448d7b0668ae39c08e6f34a54cc7eafb844f1 authored by Darrick J. Wong on 26 July 2021, 23:43:17 UTC
xfs: prevent spoofing of rtbitmap blocks when recovering buffers
Tip revision: 81a448d
File Mode Size
Documentation
LICENSES
arch
block
certs
crypto
drivers
fs
include
init
ipc
kernel
lib
mm
net
samples
scripts
security
sound
tools
usr
virt
.clang-format -rw-r--r-- 16.6 KB
.cocciconfig -rw-r--r-- 59 bytes
.get_maintainer.ignore -rw-r--r-- 71 bytes
.gitattributes -rw-r--r-- 62 bytes
.gitignore -rw-r--r-- 1.9 KB
.mailmap -rw-r--r-- 19.7 KB
COPYING -rw-r--r-- 496 bytes
CREDITS -rw-r--r-- 98.6 KB
Kbuild -rw-r--r-- 1.3 KB
Kconfig -rw-r--r-- 555 bytes
MAINTAINERS -rw-r--r-- 596.6 KB
Makefile -rw-r--r-- 63.5 KB
README -rw-r--r-- 727 bytes

README

back to top