netdev - Re: possible memory leak in ipc

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: <CANn89iJ606XRvmUhiODgXY5240ffBsak_6-rhZsnQhRyLFD4MA@mail.gmail.com>
Date:   Fri, 26 Aug 2016 08:41:19 -0700
From:   Eric Dumazet <edumazet@...gle.com>
To:     CAI Qian <caiqian@...hat.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Thomas Graf <tgraf@...g.ch>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: possible memory leak in ipc

On Fri, Aug 26, 2016 at 8:25 AM, CAI Qian <caiqian@...hat.com> wrote:
>
>
> ----- Original Message -----
>> From: "Linus Torvalds" <torvalds@...ux-foundation.org>
>> To: "CAI Qian" <caiqian@...hat.com>, "Thomas Graf" <tgraf@...g.ch>, "Herbert Xu" <herbert@...dor.apana.org.au>
>> Cc: "Eric Dumazet" <edumazet@...gle.com>, "Network Development" <netdev@...r.kernel.org>
>> Sent: Thursday, August 25, 2016 6:20:03 PM
>> Subject: Re: possible memory leak in ipc
>>
>> On Thu, Aug 25, 2016 at 1:17 PM, CAI Qian <caiqian@...hat.com> wrote:
>> > I am unsure if it is really a memleak (could be a security issue due to
>> > eventually OOM and DoS) or just a soft lockup with in kmemlock code with
>> > false alarm.
>>
>> Hmm. The reported leaks look like
>>
>> unreferenced object 0xffffc90004857000 (size 4608):
>>   comm "kworker/16:0", pid 110, jiffies 4294705908 (age 883.925s)
>>   hex dump (first 32 bytes):
>>     c0 05 3d 5e 08 88 ff ff ff ff ff ff 00 00 dc 6e  ..=^...........n
>>     ff ff ff ff ff ff ff ff 28 c7 46 83 ff ff ff ff  ........(.F.....
>>   backtrace:
>>     [<ffffffff817d95ba>] kmemleak_alloc+0x4a/0xa0
>>     [<ffffffff8123df4e>] __vmalloc_node_range+0x1de/0x2f0
>>     [<ffffffff8123e324>] vmalloc+0x54/0x60
>>     [<ffffffff81404934>] alloc_bucket_locks.isra.7+0xd4/0xf0
>>     [<ffffffff814049a8>] bucket_table_alloc+0x58/0x100
>>     [<ffffffff8140538e>] rht_deferred_worker+0x10e/0x890
>>     [<ffffffff810c30a8>] process_one_work+0x218/0x750
>>     [<ffffffff810c3705>] worker_thread+0x125/0x4a0
>>     [<ffffffff810ca8b1>] kthread+0x101/0x120
>>     [<ffffffff817e70af>] ret_from_fork+0x1f/0x40
>>     [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> which would indicate that it's a rhashtable resize event where we
>> perhaps haven't free'd the old hash table when we create a new one.
>>
>> The actually freeing of the old one is done RCU-deferred from
>> rhashtable_rehash_table(), but that itself is also deferred by a
>> worker thread (rht_deferred_worker).
>>
>> I'm not seeing anything wrong in the logic, but let's bring in Thomas
>> Graf and Herbert Xu.
>

There is a trivial bug in alloc_bucket_locks()
I will send a patch.

Thanks.