linux-kernel - Re: [PATCH v2] module: check if memory leak by module.

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: <CAJWu+ooKE0yC5t-nk4SyPphn3vjRVeZxMzdEwCrQSjhP=mryKQ@mail.gmail.com>
Date:   Fri, 31 Mar 2017 10:05:29 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Vaneet Narang <v.narang@...sung.com>,
        Miroslav Benes <mbenes@...e.cz>,
        Maninder Singh <maninder1.s@...sung.com>,
        "jeyu@...hat.com" <jeyu@...hat.com>,
        "rusty@...tcorp.com.au" <rusty@...tcorp.com.au>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "chris@...is-wilson.co.uk" <chris@...is-wilson.co.uk>,
        "aryabinin@...tuozzo.com" <aryabinin@...tuozzo.com>,
        "joonas.lahtinen@...ux.intel.com" <joonas.lahtinen@...ux.intel.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "pavel@....cz" <pavel@....cz>,
        "jinb.park7@...il.com" <jinb.park7@...il.com>,
        "anisse@...ier.eu" <anisse@...ier.eu>,
        "rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
        "zijun_hu@....com" <zijun_hu@....com>,
        "mingo@...nel.org" <mingo@...nel.org>,
        "mawilcox@...rosoft.com" <mawilcox@...rosoft.com>,
        "thgarnie@...gle.com" <thgarnie@...gle.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        PANKAJ MISHRA <pankaj.m@...sung.com>,
        Ajeet Kumar Yadav <ajeet.y@...sung.com>,
        이학봉 <hakbong5.lee@...sung.com>,
        AMIT SAHRAWAT <a.sahrawat@...sung.com>,
        랄릿 <lalit.mohan@...sung.com>,
        CPGS <cpgs@...sung.com>
Subject: Re: [PATCH v2] module: check if memory leak by module.

On Fri, Mar 31, 2017 at 1:00 AM, Michal Hocko <mhocko@...nel.org> wrote:
> On Thu 30-03-17 23:49:52, Joel Fernandes wrote:
>> Hi Michal,
>>
>> On Wed, Mar 29, 2017 at 3:43 AM, Michal Hocko <mhocko@...nel.org> wrote:
>> > On Wed 29-03-17 09:23:32, Vaneet Narang wrote:
>> >> Hi,
>> >>
>> >> >> Hmm, how can you track _all_ vmalloc allocations done on behalf of the
>> >> >> module? It is quite some time since I've checked kernel/module.c but
>> >> >> from my vague understading your check is basically only about statically
>> >> >> vmalloced areas by module loader. Is that correct? If yes then is this
>> >> >> actually useful? Were there any bugs in the loader code recently? What
>> >> >> led you to prepare this patch? All this should be part of the changelog!
>> >>
>> >> First of all there is no issue in kernel/module.c. This patch add functionality
>> >> to detect scenario where some kernel module does some memory allocation but gets
>> >> unloaded without doing vfree. For example
>> >> static int kernel_init(void)
>> >> {
>> >>         char * ptr = vmalloc(400 * 1024);
>> >>         return 0;
>> >> }
>> >
>> > How can you track that allocation back to the module? Does this patch
>> > actually works at all? Also why would be vmalloc more important than
>> > kmalloc allocations?
>>
>> Doesn't the patch use caller's (in this case, the module is the
>> caller) text address for tracking this? vma->vm->caller should track
>> the caller doing the allocation?
>
> Not really. First of all it will be vmalloc() to be tracked in the above
> the example because vmalloc is not inlined. And secondly even if the

vmalloc is not inlined, but __built_in_address(0) will return the
*return address* of vmalloc:

>From https://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Return-Address.html :
"The level argument is number of frames to scan up the call stack. A
value of 0 yields the return address of the current function"

> caller of the vmalloc was tracked then it would be hopelessly
> insufficient because you would get coverage of the _direct_ module usage
> of vmalloc rather than anything that the module triggered and that is
> outside of the module. Which means any library function etc...

Yes true, but I think the check is for direct allocations, done by the
module, not indirect ones... it may not be a catch-all issues type of
deal but is still IMO a good check since we already have
va->vm->caller available.

Thanks,
Joel