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]
Date:   Fri, 16 Sep 2016 08:09:49 +0200
From:   Pavel Machek <pavel@....cz>
To:     Jacek Anaszewski <j.anaszewski@...sung.com>
Cc:     David Lechner <david@...hnology.com>,
        Richard Purdie <rpurdie@...ys.net>,
        linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org,
        Marcel Holtmann <marcel@...tmann.org>
Subject: Re: [PATCH v3] leds: Introduce userspace leds driver

On Thu 2016-09-15 16:54:35, Jacek Anaszewski wrote:
> Hi Pavel,
> 
> On 09/15/2016 03:35 PM, Pavel Machek wrote:
> >Hi!
> >
> >>>>+	if (copy_from_user(&udev->user_dev, buffer,
> >>>>+			   sizeof(struct uleds_user_dev))) {
> >>>>+		ret = -EFAULT;
> >>>>+		goto out;
> >>>>+	}
> >>>>+
> >>>>+	if (!udev->user_dev.name[0]) {
> >>>>+		ret = -EINVAL;
> >>>>+		goto out;
> >>>>+	}
> >>>>+
> >>>>+	ret = led_classdev_register(NULL, &udev->led_cdev);
> >>>>+	if (ret < 0)
> >>>>+		goto out;
> >>
> >>No sanity checking on the name -> probably a security hole. Do not
> >>push this upstream before this is fixed.
> >
> >And actually... is it possible to have more then one userspace LED
> >with this interface? I do have RGB LED connect on /dev/ttyUSB0, and I
> >guess userspace driver would be appropriate, but it needs 3
> >channels...
> 
> Each new successful write to /dev/uleds creates a new LED class device.
> 
> See Documentation/leds/uleds.txt.

Umm. No, only one write is permitted to /dev/uleds according to the
code. In the email thread, it says:

# With this patch, you can create multiple LEDs. You just have to open a
# file handle to /dev/uleds for each LED that you want to create. Also,
# the LED device is automatically destroyed when the file handle is
# closed. I think this is nice because if the program that created it
# crashes, then it is automatically cleaned up.

...which should be actually ok. Sorry for the noise.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Powered by blists - more mailing lists