[Bug 216156] [bisected] kmemleak: Not scanning unknown object at 0xc00000007f000000

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=216156

Erhard F. (erhard_f@mailbox.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|kmemleak: Not scanning      |[bisected] kmemleak: Not
                   |unknown object at           |scanning unknown object at
                   |0xc00000007f000000          |0xc00000007f000000

--- Comment #10 from Erhard F. (erhard_f@mailbox.org) ---
Finally had some time to bisect this issue.

 # git bisect bad
23c2d497de21f25898fbea70aeb292ab8acc8c94 is the first bad commit
commit 23c2d497de21f25898fbea70aeb292ab8acc8c94
Author: Patrick Wang <patrick.wang.shcn@gmail.com>
Date:   Thu Apr 14 19:14:04 2022 -0700

    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
      Unable to handle kernel paging request at virtual address
ff5fffffffe00000
      Oops [#1]
      Modules linked in:
      CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33
      Hardware name: riscv-virtio,qemu (DT)
      epc : scan_block+0x74/0x15c
       ra : scan_block+0x72/0x15c
      epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30
       gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200
       t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90
       s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000
       a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001
       a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005
       s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90
       s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0
       s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000
       s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f
       t5 : 0000000000000001 t6 : 0000000000000000
      status: 0000000000000100 badaddr: ff5fffffffe00000 cause:
000000000000000d
        scan_gray_list+0x12e/0x1a6
        kmemleak_scan+0x2aa/0x57e
        kmemleak_write+0x32a/0x40c
        full_proxy_write+0x56/0x82
        vfs_write+0xa6/0x2a6
        ksys_write+0x6c/0xe2
        sys_write+0x22/0x2a
        ret_from_syscall+0x0/0x2

    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>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

 mm/kmemleak.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)


And indeed if I revert 23c2d497de21f25898fbea70aeb292ab8acc8c94 (on top of 5.19
as mm/kmemleak.c differs too much in later kernels) the "kmemleak: Not scanning
unknown object at 0xc00000007f000000" is gone.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.