From: Jeremy Linton <jeremy.linton@arm.com>
To: Nick Desaulniers <ndesaulniers@google.com>,
Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Thomas Gleixner <tglx@linutronix.de>,
Enrico Weigelt <info@metux.net>, Ard Biesheuvel <ardb@kernel.org>,
Allison Randal <allison@lohutok.net>
Subject: Re: [PATCH v2] arm64: acpi: fix UBSAN warning
Date: Tue, 9 Jun 2020 14:50:36 -0500 [thread overview]
Message-ID: <dfdbce19-74dd-40a6-b083-168406bc214e@arm.com> (raw)
In-Reply-To: <20200608203818.189423-1-ndesaulniers@google.com>
Hi,
On 6/8/20 3:38 PM, Nick Desaulniers wrote:
> Will reported a UBSAN warning:
>
> UBSAN: null-ptr-deref in arch/arm64/kernel/smp.c:596:6
> member access within null pointer of type 'struct acpi_madt_generic_interrupt'
> CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc6-00124-g96bc42ff0a82 #1
> Call trace:
> dump_backtrace+0x0/0x384
> show_stack+0x28/0x38
> dump_stack+0xec/0x174
> handle_null_ptr_deref+0x134/0x174
> __ubsan_handle_type_mismatch_v1+0x84/0xa4
> acpi_parse_gic_cpu_interface+0x60/0xe8
> acpi_parse_entries_array+0x288/0x498
> acpi_table_parse_entries_array+0x178/0x1b4
> acpi_table_parse_madt+0xa4/0x110
> acpi_parse_and_init_cpus+0x38/0x100
> smp_init_cpus+0x74/0x258
> setup_arch+0x350/0x3ec
> start_kernel+0x98/0x6f4
>
> This is from the use of the ACPI_OFFSET in
> arch/arm64/include/asm/acpi.h. Replace its use with offsetof from
> include/linux/stddef.h which should implement the same logic using
> __builtin_offsetof, so that UBSAN wont warn.
I looked at the longer thread about this, given that it appears to be a
false positive with respect to the macro, I tend to prefer Ard's
suggestion of just changing the offset value (1 should be sufficient
rather than 0) to avoid this kind of problem in the future.
But either way, this change looks fine too.
Reviewed-by: Jeremy Linton <jeremy.linton@arm.com>
Thanks,
>
> Link: https://lore.kernel.org/lkml/20200521100952.GA5360@willie-the-truck/
> Cc: stable@vger.kernel.org
> Reported-by: Will Deacon <will@kernel.org>
> Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> Changes V1 -> V2:
> * Just fix one of the two warnings, specific to arm64.
> * Put warning in commit message.
>
> arch/arm64/include/asm/acpi.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index b263e239cb59..a45366c3909b 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -12,6 +12,7 @@
> #include <linux/efi.h>
> #include <linux/memblock.h>
> #include <linux/psci.h>
> +#include <linux/stddef.h>
>
> #include <asm/cputype.h>
> #include <asm/io.h>
> @@ -31,14 +32,14 @@
> * is therefore used to delimit the MADT GICC structure minimum length
> * appropriately.
> */
> -#define ACPI_MADT_GICC_MIN_LENGTH ACPI_OFFSET( \
> +#define ACPI_MADT_GICC_MIN_LENGTH offsetof( \
> struct acpi_madt_generic_interrupt, efficiency_class)
>
> #define BAD_MADT_GICC_ENTRY(entry, end) \
> (!(entry) || (entry)->header.length < ACPI_MADT_GICC_MIN_LENGTH || \
> (unsigned long)(entry) + (entry)->header.length > (end))
>
> -#define ACPI_MADT_GICC_SPE (ACPI_OFFSET(struct acpi_madt_generic_interrupt, \
> +#define ACPI_MADT_GICC_SPE (offsetof(struct acpi_madt_generic_interrupt, \
> spe_interrupt) + sizeof(u16))
>
> /* Basic configuration for ACPI */
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-09 19:50 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-21 10:09 arm64/acpi: NULL dereference reports from UBSAN at boot Will Deacon
2020-05-21 17:37 ` Lorenzo Pieralisi
2020-05-26 20:21 ` Will Deacon
2020-05-27 13:41 ` Lorenzo Pieralisi
2020-06-01 7:05 ` Will Deacon
2020-06-01 21:51 ` Nick Desaulniers
2020-06-01 21:57 ` Ard Biesheuvel
2020-06-01 22:19 ` Nick Desaulniers
2020-06-01 22:28 ` Ard Biesheuvel
2020-06-01 23:18 ` [PATCH] ACPICA: fix UBSAN warning using __builtin_offsetof Nick Desaulniers
2020-06-01 23:37 ` Peter Collingbourne
2020-06-01 23:48 ` Nick Desaulniers
2020-06-02 0:02 ` Kaneda, Erik
2020-06-02 18:46 ` Nick Desaulniers
2020-06-08 14:51 ` Will Deacon
2020-06-08 20:29 ` Nick Desaulniers
2020-06-08 20:38 ` [PATCH v2] arm64: acpi: fix UBSAN warning Nick Desaulniers
2020-06-09 17:46 ` Lorenzo Pieralisi
2020-06-09 19:50 ` Jeremy Linton [this message]
2020-06-10 11:21 ` Will Deacon
2020-06-08 23:20 ` [PATCH] ACPICA: fix UBSAN warning using __builtin_offsetof Kaneda, Erik
2020-06-10 23:06 ` Kaneda, Erik
2020-06-10 23:29 ` Nick Desaulniers
2020-06-10 23:46 ` Jung-uk Kim
2020-06-11 16:45 ` [Devel] " Kaneda, Erik
2020-06-11 17:06 ` Nick Desaulniers
2020-06-16 21:39 ` Kaneda, Erik
2020-06-10 23:31 ` Jung-uk Kim
2020-05-22 8:07 ` arm64/acpi: NULL dereference reports from UBSAN at boot Hanjun Guo
2020-05-22 9:43 ` Hanjun Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dfdbce19-74dd-40a6-b083-168406bc214e@arm.com \
--to=jeremy.linton@arm.com \
--cc=allison@lohutok.net \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=info@metux.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=ndesaulniers@google.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox