linux-kernel - Re: gigaset: memory leak in gigaset

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: <CACT4Y+aXo83LjyOjVG2ihyR94kex-z+=Of+x8o4i+0q8964-1g@mail.gmail.com>
Date:	Thu, 4 Feb 2016 14:15:14 +0100
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Karsten Keil <isdn@...ux-pingi.de>,
	"David S. Miller" <davem@...emloft.net>,
	gigaset307x-common@...ts.sourceforge.net,
	netdev <netdev@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: gigaset: memory leak in gigaset_initcshw

On Thu, Feb 4, 2016 at 2:09 PM, Paul Bolle <pebolle@...cali.nl> wrote:
> On do, 2016-02-04 at 11:40 +0100, Dmitry Vyukov wrote:
>> Forgot to mention that you need to run it in a parallel loop, sorry.
>
> I see.
>
>> This one should do:
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include <pthread.h>
>> #include <stdint.h>
>> #include <stdlib.h>
>> #include <string.h>
>> #include <sys/syscall.h>
>> #include <unistd.h>
>> #include <sys/types.h>
>> #include <sys/wait.h>
>>
>> void work()
>> {
>>   long r[7];
>>   memset(r, -1, sizeof(r));
>>   r[0] = syscall(SYS_mmap, 0x20000000ul, 0x10000ul, 0x3ul, 0x32ul,
>>                  0xfffffffffffffffful, 0x0ul);
>>   r[2] = syscall(SYS_open, "/dev/ptmx", 0x8002ul, 0x0ul, 0, 0, 0);
>>   *(uint32_t*)0x20002b1e = (uint32_t)0x10;
>>   r[4] = syscall(SYS_ioctl, r[2], 0x5423ul, 0x20002b1eul, 0, 0, 0);
>>   *(uint32_t*)0x20009000 = (uint32_t)0x7;
>>   r[6] = syscall(SYS_ioctl, r[2], 0x5423ul, 0x20009000ul, 0, 0, 0);
>> }
>>
>> int main() {
>>   int running, status;
>
> (gcc complained about "running" being used uninitialized, though a few
> mock runs suggest it got initialized to 0 anyhow. I initialized
> "running" to 0 explicitly for the real runs.)
>
>>   for (;;) {
>>     while (running < 32) {
>>       if (fork() == 0) {
>>         work();
>>         exit(0);
>>       }
>>       running++;
>>     }
>>     if (wait(&status) > 0)
>>       running--;
>>   }
>> }
>
> (Note to self: this hammers my laptop with about 2.000 runs per second.
> After some time systemd's logging appears to have trouble handling the
> output this reproducer generates, so maybe messages end up getting
> dropped.)
>
>> While running it, sample/proc/slabinfo with:
>>
>> # cat /proc/slabinfo | egrep "^kmalloc-2048"
>>
>> It constantly grows.
>
> I don't really know how /proc/slabinfo should be interpreted, sorry. But
> the interesting fields appear to be "<active_objs>" and "<num_objs>".
> "<num_objs>" seems to be stable here (during the runs of a few minutes
> that I dare to inflict on my laptop). "<active_objs>" is more volatile.
> But I also saw it going down while the reproducer was running.
>
> What are you seeing here?

I see that active_objs is slowly, constantly growing.

I've attached my config file, please try with it. You mentioned that
"16 is N_GIGASET_M101, while 7 is N_6PACK", probably one of these ttys
is not enabled in your config, and so the reproducer is not doing
anything useful.

Download attachment ".config" of type "application/octet-stream" (139021 bytes)