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] [day] [month] [year] [list]
Date:	Fri, 28 Jun 2013 12:52:00 +0200
From:	David Herrmann <dh.herrmann@...il.com>
To:	michael.banken@...he.stud.uni-erlangen.de
Cc:	Benjamin Tissoires <benjamin.tissoires@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Henrik Rydberg <rydberg@...omail.se>,
	srinivas pandruvada <srinivas.pandruvada@...el.com>,
	erazor_de@...rs.sourceforge.net, Jiri Kosina <jkosina@...e.cz>,
	lorenz@...gers.com, linux-kernel@...informatik.uni-erlangen.de,
	"open list:HID CORE LAYER" <linux-input@...r.kernel.org>
Subject: Re: [PATCH] Added a check for NULL pointer in hid_add_device

Hi

On Wed, Jun 26, 2013 at 5:45 PM,
<michael.banken@...he.stud.uni-erlangen.de> wrote:
> Hi,
>
> The idea was to make the creation of an empty hid device while inside the
> kernel easier. This problem came up, when I was writing a kernel module
> driver for a usb temperature sensor. The sensors were supposed to be
> recognized in lm-sensors, which does not recognize usb devices. The
> solution in this case was to create an empty hid device to hook it up to
> sysfs.
> In some older implementations of this driver the solution to this problem
> was creating an empty hid device to hook it up to sysfs.
> These older implementations of the driver are not working anymore, unless
> built with the change I am suggesting, because in the current version
> their method of creating the hid device causes a NULL pointer dereference
> at the point where I added the check.

So you create an empty HID device to achieve what? I really cannot
follow, sorry. If you want lm_sensors to pick up your sensors, why not
patch lm_sensors to do so?

> The reason, why I believe this change to be completely harmless is that in
> the case where there actually is a NULL pointer the function would
> dereference it anyway immediately after the line where I added the check.
> The only problem that to my understanding could possibly arise is delaying
> the inevitable oops for a little while.

All other parts of the HID layer assume ll_driver to be NULL. It works
for you, because you avoid any ll_driver interaction so these parts of
the HID core that work with it will never get called. However, that's
not how it is supposed to work.

Could you describe why you cannot hook up your device as USB device
directly? Does lm_sensors only scan HID bus devices, not USB bus
devices or what is the exact reason?

> best regards,
> Michael

Cheers
David
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ