aboutsummaryrefslogtreecommitdiffstats
path: root/arch/s390/include/asm/pnet.h
diff options
context:
space:
mode:
authorMichal Kazior <michal@plume.com>2019-02-11 10:29:27 +0100
committerJacek Anaszewski <jacek.anaszewski@gmail.com>2019-02-14 22:03:44 +0100
commit5ddb0869bfc1bca6cfc592c74c64a026f936638c (patch)
treead600e28f853eb1ea69f3e4c8d2c5ee693897e18 /arch/s390/include/asm/pnet.h
parentleds: trigger: timer: Add initialization from Device Tree (diff)
downloadlinux-dev-5ddb0869bfc1bca6cfc592c74c64a026f936638c.tar.xz
linux-dev-5ddb0869bfc1bca6cfc592c74c64a026f936638c.zip
leds: lp55xx: fix null deref on firmware load failure
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 <michal@plume.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Diffstat (limited to 'arch/s390/include/asm/pnet.h')
0 files changed, 0 insertions, 0 deletions