Integer truncation in fs/xfs/libxfs/xfs_da_btree.c

Integer truncation in fs/xfs/libxfs/xfs_da_btree.c

[Kristian]

Hello,

there is an integer truncation in

fs/xfs/libxfs/xfs_da_btree.c +2081

/* account for newly allocated blocks in reserved blocks total */
args->total -= dp->i_d.di_nblocks - nblks;

with the types: uint32 -= uint64 - uint64

On a hardened kernel with grsecurity enabled, this leads to a fault.

https://forums.grsecurity.net/viewtopic.php?f=3&t=4346&sid=3200600c0faaab4bf8779a95c549a737

Is this intentional and safe?

Regards

Kristian

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: Integer truncation in fs/xfs/libxfs/xfs_da_btree.c

[Dave Chinner]

On Sun, Dec 20, 2015 at 01:36:22PM +0100, Kristian wrote:
> Hello,
> 
> there is an integer truncation in
> 
> fs/xfs/libxfs/xfs_da_btree.c +2081
> 
> /* account for newly allocated blocks in reserved blocks total */
> args->total -= dp->i_d.di_nblocks - nblks;
> 
> with the types: uint32 -= uint64 - uint64
> 
> On a hardened kernel with grsecurity enabled, this leads to a fault.
> 
> https://forums.grsecurity.net/viewtopic.php?f=3&t=4346&sid=3200600c0faaab4bf8779a95c549a737
> 
> Is this intentional and safe?

Yes and yes. We can be, at most, asking for 128 blocks to be
allocated in this function, so that  "uint64 - uint64" will
typically have a value of 1 or 2. the worst case is about 130 in the
most extreme, never-used-but-still-possible filesystem
configuration.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs