linux-ext4 - UBSAN: Undefined behaviour in fs/ext4/readpage.c:129:13

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <0b232355-4d26-3a81-0917-35533be0251a@molgen.mpg.de>
Date:   Fri, 20 Jul 2018 09:26:20 +0200
From:   Paul Menzel <pmenzel+linux-ext4@...gen.mpg.de>
To:     Theodore Ts'o <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>
Cc:     linux-ext4@...r.kernel.org, Ivan Bulatovic <combuster@...hlinux.us>
Subject: UBSAN: Undefined behaviour in fs/ext4/readpage.c:129:13

Dear Linux folks,


Enabling the undefined behavior sanitizer and building GNU/Linux 
4.18-rc5+ (with some unrelated commits) with GCC 8.1.0 from Debian 
Sid/unstable, the warning below is shown.

> [    0.629629] ================================================================================
> [    0.629765] UBSAN: Undefined behaviour in fs/ext4/readpage.c:129:13
> [    0.629814] member access within null pointer of type 'struct page'
> [    0.629867] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc5-00316-g4864b68cedf2 #104
> [    0.629869] Hardware name: ASROCK E350M1/E350M1, BIOS TIMELESS 01/01/1970
> [    0.629872] Call Trace:
> [    0.629886]  dump_stack+0x55/0x89
> [    0.629892]  ubsan_epilogue+0xb/0x33
> [    0.629897]  handle_null_ptr_deref+0x7f/0x90
> [    0.629901]  __ubsan_handle_type_mismatch_v1+0x55/0x60
> [    0.629907]  ext4_mpage_readpages+0xe9a/0xf4a
> [    0.629914]  ? find_get_entry+0x3c/0x230
> [    0.629919]  ? __alloc_pages_nodemask+0x10d/0x1710
> [    0.629925]  ext4_readpages+0x50/0xa0
> [    0.629928]  ? ext4_bmap+0x240/0x240
> [    0.629932]  read_pages+0x5f/0x230
> [    0.629936]  __do_page_cache_readahead+0x1cb/0x260
> [    0.629941]  ? __radix_tree_lookup+0x36/0xe0
> [    0.629945]  ondemand_readahead+0x1be/0x330
> [    0.629949]  page_cache_sync_readahead+0x4f/0x90
> [    0.629953]  generic_file_read_iter+0x624/0x1270
> [    0.629960]  ? ext4_xattr_security_set+0x30/0x30
> [    0.629964]  ext4_file_read_iter+0x86/0x200
> [    0.629969]  __vfs_read+0x192/0x2c0
> [    0.629974]  vfs_read+0x8e/0x210
> [    0.629978]  kernel_read+0x6d/0x100
> [    0.629982]  prepare_binprm+0x231/0x3e0
> [    0.629986]  __do_execve_file+0x607/0xee0
> [    0.629991]  ? kmem_cache_alloc+0x184/0x3e0
> [    0.629995]  do_execve+0x2c/0x30
> [    0.629999]  run_init_process+0x31/0x36
> [    0.630004]  ? rest_init+0x29/0xf6
> [    0.630007]  kernel_init+0xd8/0x152
> [    0.630009]  ? rest_init+0xf6/0xf6
> [    0.630012]  ret_from_fork+0x1c/0x38
> [    0.630016] ================================================================================

Bug report #199635 [1] already exists for the issue, but I assume you 
prefer to use the mailing list.


Kind regards,

Paul


[1]: https://bugzilla.kernel.org/show_bug.cgi?id=199635