On Mon, Jan 10, 2011 at 01:10:16PM -0700, [email protected] wrote:
> From: Dave Chinner <[email protected]>
>
> Upstream commit: 4536f2ad8b330453d7ebec0746c4374eadd649b1
>
> 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: <[email protected]>
> Signed-off-by: Dave Chinner <[email protected]>
> Reviewed-by: Christoph Hellwig <[email protected]>
> [dannf: Backported to 2.6.32.y]
This still doesn't apply to the .32-longterm tree, care to try again?
patching file fs/xfs/xfs_ialloc.c
Hunk #1 FAILED at 1220.
Hunk #2 FAILED at 1236.
Hunk #3 FAILED at 1255.
3 out of 3 hunks FAILED -- saving rejects to file
fs/xfs/xfs_ialloc.c.rej
thanks,
greg k-h
_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable
