linux-stable.git/drivers/leds, branch linux-5.0.y

leds: trigger: netdev: use memcpy in device_name_store

2019-05-04T07:21:23+00:00

[ Upstream commit 909346433064b8d840dc82af26161926b8d37558 ]

If userspace doesn't end the input with a newline (which can easily
happen if the write happens from a C program that does write(fd,
iface, strlen(iface))), we may end up including garbage from a
previous, longer value in the device_name. For example

# cat device_name

# printf 'eth12' > device_name
# cat device_name
eth12
# printf 'eth3' > device_name
# cat device_name
eth32

I highly doubt anybody is relying on this behaviour, so switch to
simply copying the bytes (we've already checked that size is <
IFNAMSIZ) and unconditionally zero-terminate it; of course, we also
still have to strip a trailing newline.

This is also preparation for future patches.

Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger")
Signed-off-by: Rasmus Villemoes 
Acked-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski 
Signed-off-by: Sasha Levin (Microsoft)

leds: pca9532: fix a potential NULL pointer dereference

2019-05-04T07:21:23+00:00

[ Upstream commit 0aab8e4df4702b31314a27ec4b0631dfad0fae0a ]

In case of_match_device cannot find a match, return -EINVAL to avoid
NULL pointer dereference.

Fixes: fa4191a609f2 ("leds: pca9532: Add device tree support")
Signed-off-by: Kangjie Lu 
Signed-off-by: Jacek Anaszewski 
Signed-off-by: Sasha Levin (Microsoft)

leds: trigger: netdev: fix refcnt leak on interface rename

2019-05-04T07:21:19+00:00

[ Upstream commit 4cb6560514fa19d556954b88128f3846fee66a03 ]

Renaming a netdev-trigger-tracked interface was resulting in an
unbalanced dev_hold().

Example:
> iw phy phy0 interface add foo type __ap
> echo netdev > trigger
> echo foo > device_name
> ip link set foo name bar
> iw dev bar del
[  237.355366] unregister_netdevice: waiting for bar to become free. Usage count = 1
[  247.435362] unregister_netdevice: waiting for bar to become free. Usage count = 1
[  257.545366] unregister_netdevice: waiting for bar to become free. Usage count = 1

Above problem was caused by trigger checking a dev->name which obviously
changes after renaming an interface. It meant missing all further events
including the NETDEV_UNREGISTER which is required for calling dev_put().

This change fixes that by:
1) Comparing device struct *address* for notification-filtering purposes
2) Dropping unneeded NETDEV_CHANGENAME code (no behavior change)

Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger")
Signed-off-by: Rafał Miłecki 
Acked-by: Pavel Machek 
Signed-off-by: Jacek Anaszewski 
Signed-off-by: Sasha Levin (Microsoft)

leds: lp55xx: fix null deref on firmware load failure

2019-04-05T20:34:37+00:00

[ Upstream commit 5ddb0869bfc1bca6cfc592c74c64a026f936638c ]

I've stumbled upon a kernel crash and the logs
pointed me towards the lp5562 driver:

> <4>[306013.841294] lp5562 0-0030: Direct firmware load for lp5562 failed with error -2
> <4>[306013.894990] lp5562 0-0030: Falling back to user helper
> ...
> <3>[306073.924886] lp5562 0-0030: firmware request failed
> <1>[306073.939456] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> <4>[306074.251011] PC is at _raw_spin_lock+0x1c/0x58
> <4>[306074.255539] LR is at release_firmware+0x6c/0x138
> ...

After taking a look I noticed firmware_release()
could be called with either NULL or a dangling
pointer.

Fixes: 10c06d178df11 ("leds-lp55xx: support firmware interface")
Signed-off-by: Michal Kazior 
Signed-off-by: Jacek Anaszewski 
Signed-off-by: Sasha Levin

leds: lp5523: fix a missing check of return value of lp55xx_read

2019-01-17T21:27:39+00:00

When lp55xx_read() fails, "status" is an uninitialized variable and thus
may contain random value; using it leads to undefined behaviors.

The fix inserts a check for the return value of lp55xx_read: if it
fails, returns with its error code.

Signed-off-by: Kangjie Lu 
Signed-off-by: Jacek Anaszewski

Merge tag 'leds-for-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds

2018-12-25T22:52:50+00:00

Pull LED updates from Jacek Anaszewski:
 "There are several few-liners, where most of them are fixes and
  improvments. One thing standing out is ground preparation for
  inititializing trigger parameters via Device Tree.

  We introduce LED_INIT_DEFAULT_TRIGGER flag for that purpose and set it
  when default trigger is matched. It indicates that trigger should
  parse DT properties to retrieve the initialization data when set as
  default one"

* tag 'leds-for-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds:
  led: triggers: Initialize LED_INIT_DEFAULT_TRIGGER if trigger is brought after class
  led: triggers: Add LED_INIT_DEFAULT_TRIGGER flag
  led: triggers: Break the for loop after default trigger is found
  leds: pwm: Use OF variant of LED registering function
  leds: pwm: Simplify with resource-managed devm_led_classdev_register()
  leds: gpio: Drop unneeded manual of_node assignment
  leds: 88pm860x: Use of_node_name_eq for node name comparisons
  leds: powernv: add of_node_put()

led: triggers: Initialize LED_INIT_DEFAULT_TRIGGER if trigger is brought after class

2018-12-10T20:31:55+00:00

Trigger driver can be initialized after the LED class device driver.  In
such case led_trigger_set_default() won't be called and flag
LED_INIT_DEFAULT_TRIGGER should be set from led_trigger_register().

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Jacek Anaszewski

led: triggers: Add LED_INIT_DEFAULT_TRIGGER flag

2018-12-10T20:31:55+00:00

Add the flag LED_INIT_DEFAULT_TRIGGER for indicating that trigger
being set is a default trigger for the LED class device, and
thus it should be initialized with settings provided in the fwnode.

Set the flag in the led_trigger_set_default(). It is expected to be
cleared in the activate() op of a trigger after trigger fwnode
initialization data is parsed and applied. This should happen only
once after LED class device registration, to allow leaving triggers
in the idle state on re-apply and let the users apply their own
settings without interference from the default ones.

Signed-off-by: Jacek Anaszewski 
Acked-by: Pavel Machek 
Signed-off-by: Krzysztof Kozlowski

led: triggers: Break the for loop after default trigger is found

2018-12-10T20:10:42+00:00

It is of no avail to continue iterating through registered
triggers in the led_trigger_set_default() after the trigger to set
has been found. Add "break" statement to fix this omission.

Signed-off-by: Jacek Anaszewski 
Acked-by: Pavel Machek 
Signed-off-by: Krzysztof Kozlowski

leds: pwm: Use OF variant of LED registering function

2018-12-08T17:59:47+00:00

The PWM leds can be instantiated from Device Tree so pass the
respective device node to LED core.  This provides the LED system with
proper device node and exposes it through uevent.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Jacek Anaszewski