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] [thread-next>] [day] [month] [year] [list]
Message-ID: <f60e2a4f-2eb8-1097-60b5-eee998478068@redhat.com>
Date:   Tue, 15 Jun 2021 10:12:06 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Rustam Kovhaev <rkovhaev@...il.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        dvyukov@...gle.com, gregkh@...uxfoundation.org
Subject: Re: kmemleak memory scanning

On 14.06.21 22:31, Rustam Kovhaev wrote:
> hello Catalin, Andrew!
> 
> while troubleshooting a false positive syzbot kmemleak report i have
> noticed an interesting behavior in kmemleak and i wonder whether it is
> behavior by design and should be documented, or maybe something to
> improve.

Hi,

See below regarding documentation.

> apologies if some of the questions do not make sense, i am still going
> through kmemleak code..
> 
> a) kmemleak scans struct page (kmemleak.c:1462), but it does not scan
> the actual contents (page_address(page)) of the page.
> if we allocate an object with kmalloc(), then allocate page with
> alloc_page(), and if we put kmalloc pointer somewhere inside that page,
> kmemleak will report kmalloc pointer as a false positive.
> should we improve kmemleak and make it scan page contents?
> or will this bring too many false negatives?

I looked into this a while ago to see which parts of the kernel end up 
reading random physical page content and was happy to see that kmemleak 
does *not* scan random physical memory :)

We have to be very careful when reading random physical page content, 
especially in virt environments this is really undesired, or when 
dealing with memory holes, memory with problematic semantics like gart 
memory ...

The doc (Documentation/dev-tools/kmemleak.rst) states "Page allocations 
and ioremap are not tracked.", which includes the alloc_page() example 
you gave I think.

-- 
Thanks,

David / dhildenb

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ