UBSAN: shift-out-of-bounds in get_init_ra_size()

UBSAN: shift-out-of-bounds in get_init_ra_size()

[Johannes Thumshirn]

Hi Willy,

I've encountered a USBSN [1] splat when running xfstests (hit it with generic/091)
on the latest iteration of our btrfs-zoned patchset.

It doesn't look related to our patchset but it looks reproducible:

johannes@redsun60:linux(naohiro-v8)$ kasan_symbolize.py < ubsan.txt 
rapido1:/home/johannes/src/xfstests-dev# cat results/generic/091.dmesg
run fstests generic/091 at 2020-10-21 10:52:32
================================================================================
UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'long unsigned int'
CPU: 0 PID: 656 Comm: fsx Not tainted 5.9.0-rc7+ #821
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4-rebuilt.opensuse.org 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:77
 dump_stack+0x57/0x70 lib/dump_stack.c:118
 ubsan_epilogue+0x5/0x40 lib/ubsan.c:148
 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe9 lib/ubsan.c:395
 __roundup_pow_of_two ./include/linux/log2.h:57
 get_init_ra_size mm/readahead.c:318
 ondemand_readahead.cold+0x16/0x2c mm/readahead.c:530
 generic_file_buffered_read+0x3ac/0x840 mm/filemap.c:2199
 call_read_iter ./include/linux/fs.h:1876
 new_sync_read+0x102/0x180 fs/read_write.c:415
 vfs_read+0x11c/0x1a0 fs/read_write.c:481
 ksys_read+0x4f/0xc0 fs/read_write.c:615
 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9 arch/x86/entry/entry_64.S:118
RIP: 0033:0x7fe87fee992e
Code: 0f 1f 40 00 48 8b 15 a1 96 00 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb ba 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28
RSP: 002b:00007ffe01605278 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
RAX: ffffffffffffffda RBX: 000000000004f000 RCX: 00007fe87fee992e
RDX: 0000000000004000 RSI: 0000000001677000 RDI: 0000000000000003
RBP: 000000000004f000 R08: 0000000000004000 R09: 000000000004f000
R10: 0000000000053000 R11: 0000000000000246 R12: 0000000000004000
R13: 0000000000000000 R14: 000000000007a120 R15: 0000000000000000
================================================================================
BTRFS info (device nullb0): has skinny extents
BTRFS info (device nullb0): ZONED mode enabled, zone size 268435456 B
BTRFS info (device nullb0): enabling ssd optimizations

Is this a known splat?

Byte,
	Johannes

Re: UBSAN: shift-out-of-bounds in get_init_ra_size()

[David Sterba]

On Wed, Oct 21, 2020 at 10:57:02AM +0000, Johannes Thumshirn wrote:
> Hi Willy,
> 
> I've encountered a USBSN [1] splat when running xfstests (hit it with generic/091)
> on the latest iteration of our btrfs-zoned patchset.

This first showed up with btrfs' dio-iomap switch
(https://github.com/btrfs/fstests/issues/5) so it's not related to the
zoned patches.

Re: UBSAN: shift-out-of-bounds in get_init_ra_size()

[Johannes Thumshirn]

On 21/10/2020 13:16, David Sterba wrote:
> On Wed, Oct 21, 2020 at 10:57:02AM +0000, Johannes Thumshirn wrote:
>> Hi Willy,
>>
>> I've encountered a USBSN [1] splat when running xfstests (hit it with generic/091)
>> on the latest iteration of our btrfs-zoned patchset.
> 
> This first showed up with btrfs' dio-iomap switch
> (https://github.com/btrfs/fstests/issues/5) so it's not related to the
> zoned patches.
> 

Ah ok, but it seems to be btrfs specific then (not readahead). So no 
need to bother Willy then.

Thanks

Re: UBSAN: shift-out-of-bounds in get_init_ra_size()

[Matthew Wilcox]

On Wed, Oct 21, 2020 at 10:57:02AM +0000, Johannes Thumshirn wrote:
> Hi Willy,
> 
> I've encountered a USBSN [1] splat when running xfstests (hit it with generic/091)
> on the latest iteration of our btrfs-zoned patchset.
> 
> It doesn't look related to our patchset but it looks reproducible:

Seems pretty easy to understand ...

static unsigned long get_init_ra_size(unsigned long size, unsigned long max)
{
        unsigned long newsize = roundup_pow_of_two(size);

if you pass in a 'size' of 0:

unsigned long __roundup_pow_of_two(unsigned long n)
{
        return 1UL << fls_long(n - 1);
}

fls_long of ~0UL will return 64, and will produce the UBSAN splat.

Of course, this isn't the only value for which roundup_pow_of_two() will
produce an invalid result.  Anything with the top bit set will also produce
UB.  But it's the only one we care about, so just doing something like this:

-	unsigned long newsize = roundup_pow_of_two(size);
+	unsigned long newsize = size ? roundup_pow_of_two(size) : size;

would fix the ubsan splat.  Or maybe you should stop passing 0 to
get_init_ra_size()?  ;-)

Re: UBSAN: shift-out-of-bounds in get_init_ra_size()

[Johannes Thumshirn]

On 21/10/2020 13:23, Matthew Wilcox wrote:
> -	unsigned long newsize = roundup_pow_of_two(size);
> +	unsigned long newsize = size ? roundup_pow_of_two(size) : size;
> 
> would fix the ubsan splat.  Or maybe you should stop passing 0 to
> get_init_ra_size()?  ;-)

You're right. Let's do both ;-). Fix btrfs to stop passing in 0 and
get_init_ra_size() to not call roundup_pow_of_two() with 0.