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+a-MEdAj4Dr7tqD6EEuD4KsrhOqyk+-m+Uq9+aao9rmfg@mail.gmail.com>
Date:	Mon, 22 Feb 2016 10:53:36 +0100
From:	Dmitry Vyukov <dvyukov@...gle.com>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Hurley <peter@...leysoftware.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	J Freyensee <james_p_freyensee@...ux.intel.com>,
	Alexander Potapenko <glider@...gle.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	syzkaller <syzkaller@...glegroups.com>
Subject: Re: tty: memory leak in tty_register_driver

On Thu, Feb 18, 2016 at 11:45 PM, Paul Bolle <pebolle@...cali.nl> wrote:
> Dmitry,
>
> On ma, 2016-02-15 at 11:42 +0100, Dmitry Vyukov wrote:
>> When I am running the following program in a parallel loop, kmemleak
>> starts reporting memory leaks of objects allocated in
>> tty_register_driver during boot.
>
> Because these tty drivers are built in?
>
>>  These leaks start popping up
>> chaotically and as you can see they originate in different drivers
>> (synclinkmp_init, isdn_init, chr_dev_init, sysfs_init).
>>
>> On commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95 (4.5-rc3).
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include <sys/types.h>
>> #include <sys/stat.h>
>> #include <fcntl.h>
>> #include <sys/ioctl.h>
>
> If you (or syzkaller) add
>         #include <linux/tty.h>
>
> here...
>
>> int main()
>> {
>>   int fd, val;
>>
>>   fd = open("/dev/ptmx", O_RDWR);
>>   val = 21;
>
> you can use
>         val = N_GSM0710;
>
> here. That is probably much clearer for the readers of this report. (No
> one bothers to remember these values. No one sane, at least.)
>
>>   ioctl(fd, TIOCSETD, &val);
>>   return 0;
>> }
>
> Fascinating issue. Makes zero sense to me. sysfs_init? Anyhow, since the
> people actually familiar with this code have stayed silent until now, I
> have some obvious questions:
> - does this only trigger with line discipline N_GSM0710?
> - is this a new issue or do older trees also trigger it (in other
>   words: have you tried bisecting this)?

I can say that it does not happen with 1, 2, 3, 4 and 7. So there are
chances that it is N_GSM0710-specific. 5 and 6 trigger lots of leaks,
but they are different. I did not try to bisect it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ