linux-kernel - Re: [PATCH] hidraw: correctly deallocate memory on device disconnect

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1707995.vN5QlUzrT9@al>
Date:	Tue, 20 Aug 2013 16:14:21 +0200
From:	Peter Wu <lekensteyn@...il.com>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Manoj Chourasia <mchourasia@...dia.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] hidraw: correctly deallocate memory on device disconnect

On Friday 09 August 2013 11:31:15 Jiri Kosina wrote:
> On Mon, 22 Jul 2013, Manoj Chourasia wrote:
> > This is mail is in regard to your commit for hidaw devices. We were
> > seeing kernel crashes while connect and disconnect a hidraw device and
> > we were hitting rb tree corruption in vmalloc and kernel was crashing
> > because of null pointer de-reference. Later we figure out that was
> > because the hid device disconnect is freeing memory which later got
> > access by hidraw_read and hid_write.
> 
> Now applied, thanks Manoj, thanks Peter.

I just noticed an issue with this patch, after playing with some receivers I 
saw 8 hidraw device nodes. Every USB receiver creates two hidraw nodes, one 
for the receiver and one for the paired device.

UPower seems to keep the file descriptor open which prevents the hidraw device 
from being removed. Shouldn't the implementation of hidraw be changed to 
separate open file descriptors from the actual HID devices? That should allow 
/dev/hidrawX devices to get removed whenever a HID device is gone.

Regards,
Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/