From: Andrew Morton <akpm@linux-foundation.org>
To: stable@vger.kernel.org,catalin.marinas@arm.com,patrick.wang.shcn@gmail.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org
Subject: [patch 14/14] mm: kmemleak: take a full lowmem check in kmemleak_*_phys()
Date: Thu, 14 Apr 2022 19:14:04 -0700 [thread overview]
Message-ID: <20220415021405.5EBADC385A7@smtp.kernel.org> (raw)
In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org>
From: Patrick Wang <patrick.wang.shcn@gmail.com>
Subject: mm: kmemleak: take a full lowmem check in kmemleak_*_phys()
The kmemleak_*_phys() apis do not check the address for lowmem's min
boundary, while the caller may pass an address below lowmem, which will
trigger an oops:
# echo scan > /sys/kernel/debug/kmemleak
[ 54.888353] Unable to handle kernel paging request at virtual address ff5fffffffe00000
[ 54.888932] Oops [#1]
[ 54.889102] Modules linked in:
[ 54.889326] CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33
[ 54.889620] Hardware name: riscv-virtio,qemu (DT)
[ 54.889901] epc : scan_block+0x74/0x15c
[ 54.890215] ra : scan_block+0x72/0x15c
[ 54.890390] epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30
[ 54.890607] gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200
[ 54.890835] t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90
[ 54.891024] s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000
[ 54.891201] a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001
[ 54.891377] a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005
[ 54.891552] s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90
[ 54.891727] s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0
[ 54.891903] s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000
[ 54.892078] s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f
[ 54.892271] t5 : 0000000000000001 t6 : 0000000000000000
[ 54.892408] status: 0000000000000100 badaddr: ff5fffffffe00000 cause: 000000000000000d
[ 54.892643] [<ffffffff801e5a1c>] scan_gray_list+0x12e/0x1a6
[ 54.892824] [<ffffffff801e5d3e>] kmemleak_scan+0x2aa/0x57e
[ 54.892961] [<ffffffff801e633c>] kmemleak_write+0x32a/0x40c
[ 54.893096] [<ffffffff803915ac>] full_proxy_write+0x56/0x82
[ 54.893235] [<ffffffff801ef456>] vfs_write+0xa6/0x2a6
[ 54.893362] [<ffffffff801ef880>] ksys_write+0x6c/0xe2
[ 54.893487] [<ffffffff801ef918>] sys_write+0x22/0x2a
[ 54.893609] [<ffffffff8000397c>] ret_from_syscall+0x0/0x2
[ 54.894183] ---[ end trace 0000000000000000 ]---
The callers may not quite know the actual address they pass(e.g. from
devicetree). So the kmemleak_*_phys() apis should guarantee the
address they finally use is in lowmem range, so check the address for
lowmem's min boundary.
Link: https://lkml.kernel.org/r/20220413122925.33856-1-patrick.wang.shcn@gmail.com
Signed-off-by: Patrick Wang <patrick.wang.shcn@gmail.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/kmemleak.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/mm/kmemleak.c~mm-kmemleak-take-a-full-lowmem-check-in-kmemleak__phys
+++ a/mm/kmemleak.c
@@ -1132,7 +1132,7 @@ EXPORT_SYMBOL(kmemleak_no_scan);
void __ref kmemleak_alloc_phys(phys_addr_t phys, size_t size, int min_count,
gfp_t gfp)
{
- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
kmemleak_alloc(__va(phys), size, min_count, gfp);
}
EXPORT_SYMBOL(kmemleak_alloc_phys);
@@ -1146,7 +1146,7 @@ EXPORT_SYMBOL(kmemleak_alloc_phys);
*/
void __ref kmemleak_free_part_phys(phys_addr_t phys, size_t size)
{
- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
kmemleak_free_part(__va(phys), size);
}
EXPORT_SYMBOL(kmemleak_free_part_phys);
@@ -1158,7 +1158,7 @@ EXPORT_SYMBOL(kmemleak_free_part_phys);
*/
void __ref kmemleak_not_leak_phys(phys_addr_t phys)
{
- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
kmemleak_not_leak(__va(phys));
}
EXPORT_SYMBOL(kmemleak_not_leak_phys);
@@ -1170,7 +1170,7 @@ EXPORT_SYMBOL(kmemleak_not_leak_phys);
*/
void __ref kmemleak_ignore_phys(phys_addr_t phys)
{
- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
kmemleak_ignore(__va(phys));
}
EXPORT_SYMBOL(kmemleak_ignore_phys);
_
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: stable@vger.kernel.org, catalin.marinas@arm.com,
patrick.wang.shcn@gmail.com, akpm@linux-foundation.org,
patches@lists.linux.dev, linux-mm@kvack.org,
mm-commits@vger.kernel.org, torvalds@linux-foundation.org,
akpm@linux-foundation.org
Subject: [patch 14/14] mm: kmemleak: take a full lowmem check in kmemleak_*_phys()
Date: Thu, 14 Apr 2022 19:14:04 -0700 [thread overview]
Message-ID: <20220415021405.5EBADC385A7@smtp.kernel.org> (raw)
In-Reply-To: <20220414191240.9f86d15a3e3afd848a9839a6@linux-foundation.org>
From: Patrick Wang <patrick.wang.shcn@gmail.com>
Subject: mm: kmemleak: take a full lowmem check in kmemleak_*_phys()
The kmemleak_*_phys() apis do not check the address for lowmem's min
boundary, while the caller may pass an address below lowmem, which will
trigger an oops:
# echo scan > /sys/kernel/debug/kmemleak
[ 54.888353] Unable to handle kernel paging request at virtual address ff5fffffffe00000
[ 54.888932] Oops [#1]
[ 54.889102] Modules linked in:
[ 54.889326] CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33
[ 54.889620] Hardware name: riscv-virtio,qemu (DT)
[ 54.889901] epc : scan_block+0x74/0x15c
[ 54.890215] ra : scan_block+0x72/0x15c
[ 54.890390] epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30
[ 54.890607] gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200
[ 54.890835] t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90
[ 54.891024] s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000
[ 54.891201] a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001
[ 54.891377] a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005
[ 54.891552] s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90
[ 54.891727] s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0
[ 54.891903] s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000
[ 54.892078] s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f
[ 54.892271] t5 : 0000000000000001 t6 : 0000000000000000
[ 54.892408] status: 0000000000000100 badaddr: ff5fffffffe00000 cause: 000000000000000d
[ 54.892643] [<ffffffff801e5a1c>] scan_gray_list+0x12e/0x1a6
[ 54.892824] [<ffffffff801e5d3e>] kmemleak_scan+0x2aa/0x57e
[ 54.892961] [<ffffffff801e633c>] kmemleak_write+0x32a/0x40c
[ 54.893096] [<ffffffff803915ac>] full_proxy_write+0x56/0x82
[ 54.893235] [<ffffffff801ef456>] vfs_write+0xa6/0x2a6
[ 54.893362] [<ffffffff801ef880>] ksys_write+0x6c/0xe2
[ 54.893487] [<ffffffff801ef918>] sys_write+0x22/0x2a
[ 54.893609] [<ffffffff8000397c>] ret_from_syscall+0x0/0x2
[ 54.894183] ---[ end trace 0000000000000000 ]---
The callers may not quite know the actual address they pass(e.g. from
devicetree). So the kmemleak_*_phys() apis should guarantee the
address they finally use is in lowmem range, so check the address for
lowmem's min boundary.
Link: https://lkml.kernel.org/r/20220413122925.33856-1-patrick.wang.shcn@gmail.com
Signed-off-by: Patrick Wang <patrick.wang.shcn@gmail.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/kmemleak.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/mm/kmemleak.c~mm-kmemleak-take-a-full-lowmem-check-in-kmemleak__phys
+++ a/mm/kmemleak.c
@@ -1132,7 +1132,7 @@ EXPORT_SYMBOL(kmemleak_no_scan);
void __ref kmemleak_alloc_phys(phys_addr_t phys, size_t size, int min_count,
gfp_t gfp)
{
- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
kmemleak_alloc(__va(phys), size, min_count, gfp);
}
EXPORT_SYMBOL(kmemleak_alloc_phys);
@@ -1146,7 +1146,7 @@ EXPORT_SYMBOL(kmemleak_alloc_phys);
*/
void __ref kmemleak_free_part_phys(phys_addr_t phys, size_t size)
{
- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
kmemleak_free_part(__va(phys), size);
}
EXPORT_SYMBOL(kmemleak_free_part_phys);
@@ -1158,7 +1158,7 @@ EXPORT_SYMBOL(kmemleak_free_part_phys);
*/
void __ref kmemleak_not_leak_phys(phys_addr_t phys)
{
- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
kmemleak_not_leak(__va(phys));
}
EXPORT_SYMBOL(kmemleak_not_leak_phys);
@@ -1170,7 +1170,7 @@ EXPORT_SYMBOL(kmemleak_not_leak_phys);
*/
void __ref kmemleak_ignore_phys(phys_addr_t phys)
{
- if (!IS_ENABLED(CONFIG_HIGHMEM) || PHYS_PFN(phys) < max_low_pfn)
+ if (PHYS_PFN(phys) >= min_low_pfn && PHYS_PFN(phys) < max_low_pfn)
kmemleak_ignore(__va(phys));
}
EXPORT_SYMBOL(kmemleak_ignore_phys);
_
next prev parent reply other threads:[~2022-04-15 2:14 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-15 2:12 incoming Andrew Morton
2022-04-15 2:13 ` [patch 01/14] MAINTAINERS: Broadcom internal lists aren't maintainers Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 02/14] tmpfs: fix regressions from wider use of ZERO_PAGE Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 22:10 ` Linus Torvalds
2022-04-15 22:21 ` Matthew Wilcox
2022-04-15 22:41 ` Hugh Dickins
2022-04-16 6:36 ` Borislav Petkov
2022-04-16 14:07 ` Mark Hemment
2022-04-16 17:28 ` Borislav Petkov
2022-04-16 17:42 ` Linus Torvalds
2022-04-16 21:15 ` Borislav Petkov
2022-04-17 19:41 ` Borislav Petkov
2022-04-17 20:56 ` Linus Torvalds
2022-04-18 10:15 ` Borislav Petkov
2022-04-18 17:10 ` Linus Torvalds
2022-04-19 9:17 ` Borislav Petkov
2022-04-19 16:41 ` Linus Torvalds
2022-04-19 17:48 ` Borislav Petkov
2022-04-21 15:06 ` Borislav Petkov
2022-04-21 16:50 ` Linus Torvalds
2022-04-21 17:22 ` Linus Torvalds
2022-04-24 19:37 ` Borislav Petkov
2022-04-24 19:54 ` Linus Torvalds
2022-04-24 20:24 ` Linus Torvalds
2022-04-27 0:14 ` Borislav Petkov
2022-04-27 1:29 ` Linus Torvalds
2022-04-27 10:41 ` Borislav Petkov
2022-04-27 16:00 ` Linus Torvalds
2022-05-04 18:56 ` Borislav Petkov
2022-05-04 19:22 ` Linus Torvalds
2022-05-04 20:18 ` Borislav Petkov
2022-05-04 20:40 ` Linus Torvalds
2022-05-04 21:01 ` Borislav Petkov
2022-05-04 21:09 ` Linus Torvalds
2022-05-10 9:31 ` clear_user (was: [patch 02/14] tmpfs: fix regressions from wider use of ZERO_PAGE) Borislav Petkov
2022-05-10 17:17 ` Linus Torvalds
2022-05-10 17:28 ` Linus Torvalds
2022-05-10 18:10 ` Borislav Petkov
2022-05-10 18:57 ` Borislav Petkov
2022-05-24 12:32 ` [PATCH] x86/clear_user: Make it faster Borislav Petkov
2022-05-24 16:51 ` Linus Torvalds
2022-05-24 17:30 ` Borislav Petkov
2022-05-25 12:11 ` Mark Hemment
2022-05-27 11:28 ` Borislav Petkov
2022-05-27 11:10 ` Ingo Molnar
2022-06-22 14:21 ` Borislav Petkov
2022-06-22 15:06 ` Linus Torvalds
2022-06-22 20:14 ` Borislav Petkov
2022-06-22 21:07 ` Linus Torvalds
2022-06-23 9:41 ` Borislav Petkov
2022-07-05 17:01 ` [PATCH -final] " Borislav Petkov
2022-07-06 9:24 ` Alexey Dobriyan
2022-07-11 10:33 ` Borislav Petkov
2022-07-12 12:32 ` Alexey Dobriyan
2022-08-06 12:49 ` Borislav Petkov
2022-08-18 10:44 ` [tip: x86/cpu] " tip-bot2 for Borislav Petkov
2022-04-15 2:13 ` [patch 03/14] mm/secretmem: fix panic when growing a memfd_secret Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 04/14] irq_work: use kasan_record_aux_stack_noalloc() record callstack Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 05/14] kasan: fix hw tags enablement when KUNIT tests are disabled Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 06/14] mm, kfence: support kmem_dump_obj() for KFENCE objects Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 07/14] mm, page_alloc: fix build_zonerefs_node() Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 08/14] mm: fix unexpected zeroed page mapping with zram swap Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 09/14] mm: compaction: fix compiler warning when CONFIG_COMPACTION=n Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 10/14] hugetlb: do not demote poisoned hugetlb pages Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 11/14] revert "fs/binfmt_elf: fix PT_LOAD p_align values for loaders" Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:13 ` [patch 12/14] revert "fs/binfmt_elf: use PT_LOAD p_align values for static PIE" Andrew Morton
2022-04-15 2:13 ` Andrew Morton
2022-04-15 2:14 ` [patch 13/14] mm/vmalloc: fix spinning drain_vmap_work after reading from /proc/vmcore Andrew Morton
2022-04-15 2:14 ` Andrew Morton
2022-04-15 2:14 ` Andrew Morton [this message]
2022-04-15 2:14 ` [patch 14/14] mm: kmemleak: take a full lowmem check in kmemleak_*_phys() Andrew Morton
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=20220415021405.5EBADC385A7@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=linux-mm@kvack.org \
--cc=mm-commits@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=patrick.wang.shcn@gmail.com \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.