linux-kernel - Re: Clang and UBSAN: member access within null pointer of type

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] [day] [month] [year] [list]

Date:   Thu, 7 May 2020 14:53:43 -0400
From:   Qian Cai <cai@....pw>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     Nathan Chancellor <natechancellor@...il.com>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Will Deacon <will@...nel.org>
Subject: Re: Clang and UBSAN: member access within null pointer of type



> On May 7, 2020, at 2:30 PM, Nick Desaulniers <ndesaulniers@...gle.com> wrote:
> 
> On Thu, May 7, 2020 at 6:42 AM Qian Cai <cai@....pw> wrote:
>> 
>> Running a Clang (9.0.1) build kernel with UBSAN generated a few warnings during boot,
> 
> Very cool, these reports are so nice! They hand you everything on a
> silver platter.  Thanks for testing/sending!  Let's take a look.
> 
>> 
>> [    0.000000] UBSAN: null-ptr-deref in drivers/acpi/acpica/tbfadt.c:459:37
>> [    0.000000] member access within null pointer of type 'struct acpi_table_fadt'
>> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc4-next-20200507 #2
>> [    0.000000] Call trace:
>> [    0.000000]  dump_backtrace+0x0/0x22c
>> [    0.000000]  show_stack+0x28/0x34
>> [    0.000000]  dump_stack+0x104/0x194
>> [    0.000000]  handle_null_ptr_deref+0xdc/0x10c
>> [    0.000000]  __ubsan_handle_type_mismatch_v1+0x64/0x78
>> [    0.000000]  acpi_tb_create_local_fadt+0x104/0x6ec
> 
> ok so acpi_tb_create_local_fadt() dereferenced a `null pointer of type
> 'struct acpi_table_fadt'` in null-ptr-deref in
> drivers/acpi/acpica/tbfadt.c:459.
> 
> That line number doesn't line up with linux-next; which tree was this?
> That will probably help track these down faster.

It is linux-next indeed as in the signature.

next-20200507

# ./scripts/faddr2line vmlinux acpi_tb_create_local_fadt+0x104/0x6ec
acpi_tb_create_local_fadt+0x104/0x6ec:
acpi_tb_convert_fadt at drivers/acpi/acpica/tbfadt.c:459
(inlined by) acpi_tb_create_local_fadt at drivers/acpi/acpica/tbfadt.c:388

This line,

        if (acpi_gbl_FADT.header.length <= ACPI_FADT_V2_SIZE) {

acpi_gbl_FADT was defined in,

.//include/acpi/acpixf.h:266:ACPI_GLOBAL(struct acpi_table_fadt, acpi_gbl_FADT);

#ifdef DEFINE_ACPI_GLOBALS
#define ACPI_GLOBAL(type,name) \
	extern type name; \
	type name



#define ACPI_INIT_GLOBAL(type,name,value) \
	type name=value



#else
#ifndef ACPI_GLOBAL
#define ACPI_GLOBAL(type,name) \
	extern type name
#endif



#ifndef ACPI_INIT_GLOBAL
#define ACPI_INIT_GLOBAL(type,name,value) \
	extern type name
#endif
#endif

I looks like DEFINE_ACPI_GLOBALS should be set in drivers/acpi/acpica/utglobal.c.