2024-06-13 16:21:21

by Waiman Long

Subject: [PATCH] arm64/efi: Fix kmemleak false positive in arm64_efi_rt_init()

The kmemleak code sometimes complains about the following leak:

unreferenced object 0xffff8000102e0000 (size 32768):
  comm "swapper/0", pid 1, jiffies 4294937323 (age 71.240s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<00000000db9a88a3>] __vmalloc_node_range+0x324/0x450
    [<00000000ff8903a4>] __vmalloc_node+0x90/0xd0
    [<000000001a06634f>] arm64_efi_rt_init+0x64/0xdc
    [<0000000007826a8d>] do_one_initcall+0x178/0xac0
    [<0000000054a87017>] do_initcalls+0x190/0x1d0
    [<00000000308092d0>] kernel_init_freeable+0x2c0/0x2f0
    [<000000003e7b99e0>] kernel_init+0x28/0x14c
    [<000000002246af5b>] ret_from_fork+0x10/0x20

The memory object in this case is for efi_rt_stack_top and is allocated
in an initcall. So this is certainly a false positive. Mark the object
as not a leak to quash it.

Signed-off-by: Waiman Long <[email protected]>
---
arch/arm64/kernel/efi.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 4a92096db34e..712718aed5dd 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -9,6 +9,7 @@

#include <linux/efi.h>
#include <linux/init.h>
+#include <linux/kmemleak.h>
#include <linux/screen_info.h>
#include <linux/vmalloc.h>

@@ -213,6 +214,7 @@ l: if (!p) {
return -ENOMEM;
}

+ kmemleak_not_leak(p);
efi_rt_stack_top = p + THREAD_SIZE;
return 0;
}
--
2.39.3

2024-06-13 16:26:09

by Ard Biesheuvel

Subject: Re: [PATCH] arm64/efi: Fix kmemleak false positive in arm64_efi_rt_init()

On Thu, 13 Jun 2024 at 18:21, Waiman Long <[email protected]> wrote:
>
> The kmemleak code sometimes complains about the following leak:
>
> unreferenced object 0xffff8000102e0000 (size 32768):
> comm "swapper/0", pid 1, jiffies 4294937323 (age 71.240s)
> hex dump (first 32 bytes):
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<00000000db9a88a3>] __vmalloc_node_range+0x324/0x450
> [<00000000ff8903a4>] __vmalloc_node+0x90/0xd0
> [<000000001a06634f>] arm64_efi_rt_init+0x64/0xdc
> [<0000000007826a8d>] do_one_initcall+0x178/0xac0
> [<0000000054a87017>] do_initcalls+0x190/0x1d0
> [<00000000308092d0>] kernel_init_freeable+0x2c0/0x2f0
> [<000000003e7b99e0>] kernel_init+0x28/0x14c
> [<000000002246af5b>] ret_from_fork+0x10/0x20
>
> The memory object in this case is for efi_rt_stack_top and is allocated
> in an initcall. So this is certainly a false positive. Mark the object
> as not a leak to quash it.
>
> Signed-off-by: Waiman Long <[email protected]>

Acked-by: Ard Biesheuvel <[email protected]>

I'll take this as a fix via the EFI tree.

Thanks,

> ---
> arch/arm64/kernel/efi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 4a92096db34e..712718aed5dd 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -9,6 +9,7 @@
>
> #include <linux/efi.h>
> #include <linux/init.h>
> +#include <linux/kmemleak.h>
> #include <linux/screen_info.h>
> #include <linux/vmalloc.h>
>
> @@ -213,6 +214,7 @@ l: if (!p) {
> return -ENOMEM;
> }
>
> + kmemleak_not_leak(p);
> efi_rt_stack_top = p + THREAD_SIZE;
> return 0;
> }
> --
> 2.39.3
>
>

2024-06-13 17:19:51

by Catalin Marinas

Subject: Re: [PATCH] arm64/efi: Fix kmemleak false positive in arm64_efi_rt_init()

On Thu, Jun 13, 2024 at 12:20:31PM -0400, Waiman Long wrote:
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 4a92096db34e..712718aed5dd 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -9,6 +9,7 @@
>
> #include <linux/efi.h>
> #include <linux/init.h>
> +#include <linux/kmemleak.h>
> #include <linux/screen_info.h>
> #include <linux/vmalloc.h>
>
> @@ -213,6 +214,7 @@ l: if (!p) {
> return -ENOMEM;
> }
>
> + kmemleak_not_leak(p);
> efi_rt_stack_top = p + THREAD_SIZE;

It looks like a false positive and the reason is that we only store
p + THREAD_SIZE in efi_rt_stack_top, not the actual allocated pointer.

--
Catalin