linux-kernel - Re: arm64/acpi: NULL dereference reports from UBSAN at boot

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200521173738.GA29590@e121166-lin.cambridge.arm.com>
Date:   Thu, 21 May 2020 18:37:38 +0100
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Will Deacon <will@...nel.org>
Cc:     guohanjun@...wei.com, rjw@...ysocki.net,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        mark.rutland@....com
Subject: Re: arm64/acpi: NULL dereference reports from UBSAN at boot

On Thu, May 21, 2020 at 11:09:53AM +0100, Will Deacon wrote:
> Hi folks,
> 
> I just tried booting the arm64 for-kernelci branch under QEMU (version
> 4.2.50 (v4.2.0-779-g4354edb6dcc7)) with UBSAN enabled, and I see a
> couple of NULL pointer dereferences reported at boot. I think they're
> both GIC related (log below). I don't see a panic with UBSAN disabled,
> so something's fishy here.

May I ask you the QEMU command line please - just to make sure I can
replicate it.

> Please can you take a look when you get a chance? I haven't had time to see
> if this is a regression or not, but I don't think it's particularly serious
> as I have all sorts of horrible stuff enabled in my .config, since I'm
> trying to chase down another bug:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/plain/arch/arm64/configs/fuzzing.config?h=fuzzing/arm64-kernelci-20200519&id=c149cf6a51aa4f72d53fc681c6661094e93ef660
> 
> (on top of defconfig)
> 
> CONFIG_FAIL_PAGE_ALLOC may be to blame.

Not sure about that, they are both quite cryptic, I wonder if UBSAN
is not tricked by the ACPI_OFFSET macro - need to debug it further
to understand what's going on here.

Thanks,
Lorenzo

> Cheers,
> 
> Will
> 
> --->8
> 
> [    0.000000][    T0] ================================================================================
> [    0.000000][    T0] UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
> [    0.000000][    T0] member access within null pointer of type 'struct acpi_table_fadt'
> [    0.000000][    T0] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc6-00124-g96bc42ff0a82 #1
> [    0.000000][    T0] Call trace:
> [    0.000000][    T0]  dump_backtrace+0x0/0x384
> [    0.000000][    T0]  show_stack+0x28/0x38
> [    0.000000][    T0]  dump_stack+0xec/0x174
> [    0.000000][    T0]  handle_null_ptr_deref+0x134/0x174
> [    0.000000][    T0]  __ubsan_handle_type_mismatch_v1+0x84/0xa4
> [    0.000000][    T0]  acpi_tb_create_local_fadt+0x1d4/0x1418
> [    0.000000][    T0]  acpi_tb_parse_fadt+0x108/0x4b8
> [    0.000000][    T0]  acpi_tb_parse_root_table+0x380/0x578
> [    0.000000][    T0]  acpi_initialize_tables+0x140/0x194
> [    0.000000][    T0]  acpi_table_init+0x90/0xcc
> [    0.000000][    T0]  acpi_boot_table_init+0xfc/0x1c8
> [    0.000000][    T0]  setup_arch+0x2b4/0x3ec
> [    0.000000][    T0]  start_kernel+0x98/0x6f4
> [    0.000000][    T0] ================================================================================
> 
> [    0.000000][    T0] ================================================================================
> [    0.000000][    T0] UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6
> [    0.000000][    T0] member access within null pointer of type 'struct acpi_madt_generic_interrupt'
> [    0.000000][    T0] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc6-00124-g96bc42ff0a82 #1
> [    0.000000][    T0] Call trace:
> [    0.000000][    T0]  dump_backtrace+0x0/0x384
> [    0.000000][    T0]  show_stack+0x28/0x38
> [    0.000000][    T0]  dump_stack+0xec/0x174
> [    0.000000][    T0]  handle_null_ptr_deref+0x134/0x174
> [    0.000000][    T0]  __ubsan_handle_type_mismatch_v1+0x84/0xa4
> [    0.000000][    T0]  acpi_parse_gic_cpu_interface+0x60/0xe8
> [    0.000000][    T0]  acpi_parse_entries_array+0x288/0x498
> [    0.000000][    T0]  acpi_table_parse_entries_array+0x178/0x1b4
> [    0.000000][    T0]  acpi_table_parse_madt+0xa4/0x110
> [    0.000000][    T0]  acpi_parse_and_init_cpus+0x38/0x100
> [    0.000000][    T0]  smp_init_cpus+0x74/0x258
> [    0.000000][    T0]  setup_arch+0x350/0x3ec
> [    0.000000][    T0]  start_kernel+0x98/0x6f4
> [    0.000000][    T0] ================================================================================