aboutsummaryrefslogtreecommitdiffstats
path: root/fs/no-block.c
diff options
context:
space:
mode:
authorDave Chinner <dchinner@redhat.com>2010-08-24 11:42:30 +1000
committerDave Chinner <david@fromorbit.com>2010-08-24 11:42:30 +1000
commit4536f2ad8b330453d7ebec0746c4374eadd649b1 (patch)
tree55e4804119f4629279b1848b2a35eaf297b1d5bc /fs/no-block.c
parent5b3eed756cd37255cad1181bd86bfd0977e97953 (diff)
downloadkernel_samsung_crespo-4536f2ad8b330453d7ebec0746c4374eadd649b1.zip
kernel_samsung_crespo-4536f2ad8b330453d7ebec0746c4374eadd649b1.tar.gz
kernel_samsung_crespo-4536f2ad8b330453d7ebec0746c4374eadd649b1.tar.bz2
xfs: fix untrusted inode number lookup
Commit 7124fe0a5b619d65b739477b3b55a20bf805b06d ("xfs: validate untrusted inode numbers during lookup") changes the inode lookup code to do btree lookups for untrusted inode numbers. This change made an invalid assumption about the alignment of inodes and hence incorrectly calculated the first inode in the cluster. As a result, some inode numbers were being incorrectly considered invalid when they were actually valid. The issue was not picked up by the xfstests suite because it always runs fsr and dump (the two utilities that utilise the bulkstat interface) on cache hot inodes and hence the lookup code in the cold cache path was not sufficiently exercised to uncover this intermittent problem. Fix the issue by relaxing the btree lookup criteria and then checking if the record returned contains the inode number we are lookup for. If it we get an incorrect record, then the inode number is invalid. Cc: <stable@kernel.org> Signed-off-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de>
Diffstat (limited to 'fs/no-block.c')
0 files changed, 0 insertions, 0 deletions