summaryrefslogtreecommitdiffstats
path: root/drivers/rtc/rtc-tps65910.c
diff options
context:
space:
mode:
authorJan Beulich <JBeulich@suse.com>2014-08-08 14:20:09 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2014-08-08 15:57:19 -0700
commit6e85bab6bc1019f9b87c53b32da3ad7791e7ddf9 (patch)
tree7f83156bdd6fa857286d224a3443dc5f481cbd74 /drivers/rtc/rtc-tps65910.c
parent3710f597aca5af4f605cda9793a8b2f0a42bc29a (diff)
downloadtalos-obmc-linux-6e85bab6bc1019f9b87c53b32da3ad7791e7ddf9.tar.gz
talos-obmc-linux-6e85bab6bc1019f9b87c53b32da3ad7791e7ddf9.zip
drivers/rtc/rtc-efi.c: check for invalid data coming back from UEFI
In particular seeing zero in eft->month is problematic, as it results in -1 (converted to unsigned int, i.e. yielding 0xffffffff) getting passed to rtc_year_days(), where the value gets used as an array index (normally resulting in a crash). This was observed with the driver enabled on x86 on some Fujitsu system (with possibly not up to date firmware, but anyway). Perhaps efi_read_alarm() should not fail if neither enabled nor pending are set, but the returned time is invalid? Signed-off-by: Jan Beulich <jbeulich@suse.com> Reported-by: Raymund Will <rw@suse.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Jingoo Han <jg1.han@samsung.com> Acked-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/rtc/rtc-tps65910.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud