Bug#646429: linux-image-2.6.39-bpo.2-686-pae: CPU lockup on bogus values in alarmclock
Package: linux-2.6
Version: 2.6.39-3~bpo60+1
Severity: normal
Tags: patch
*** Please type your report below this line ***
On a kernel upgrade on an ML350-G6, I got the following kernel error:
[ 7.934275] input: AT Translated Set 2 keyboard as
/devices/platform/i8042/serio0/input/input0
[ 74.314403] BUG: soft lockup - CPU#1 stuck for 61s! [swapper:1]
[ 74.347143] Modules linked in:
[ 74.362226] Modules linked in:
[ 74.377593]
[ 74.386567] Pid: 1, comm: swapper Tainted: G W
2.6.39-bpo.2-686-pae #1 HP ProLiant ML350 G6
[ 74.430973] EIP: 0060:[<c11f8e0c>] EFLAGS: 00000246 CPU: 1
[ 74.462417] EIP is at is_leap_year+0x24/0x2d
[ 74.485874] EAX: 004cd64f EBX: 00000190 ECX: 780edc9f EDX: 0000012f
[ 74.521801] ESI: 0000001f EDI: 00000003 EBP: f5b0cc00 ESP: f585be34
[ 74.557730] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 74.588674] Process swapper (pid: 1, ti=f585a000 task=f5859900
task.ti=f585a000)
[ 74.632074] Stack:
[ 74.637621] 00000004 c11f8e27 f585bed0 00000022 c11f8f7a f585becc
00000000 c11fa0ef
[ 74.672621] f585be64 f585be88 f585bed0 f5b0cd74 0000003a 0000000a
0000000a 00000012
[ 74.695438] 00000009 0000006f 00000000 00000000 00000000 0000003a
0000000a 0000000a
[ 74.726187] Call Trace:
[ 74.739904] [<c11f8e27>] ? rtc_month_days+0x12/0x2c
[ 74.768326] [<c11f8f7a>] ? rtc_valid_tm+0x26/0x45
[ 74.794273] [<c11fa0ef>] ? __rtc_read_alarm+0x1df/0x200
[ 74.819230] [<c11f9313>] ? rtc_device_register+0x196/0x267
[ 74.851234] [<c11fb6df>] ? cmos_do_probe+0x116/0x326
[ 74.880106] [<c11b06b6>] ? pnp_device_probe+0x79/0x96
[ 74.910540] [<c11e8ea9>] ? driver_probe_device+0x8c/0x110
[ 74.937018] [<c11e8f6d>] ? __driver_attach+0x40/0x5b
[ 74.961949] [<c11e8705>] ? bus_for_each_dev+0x37/0x5f
[ 74.991395] [<c11e8d5f>] ? driver_attach+0x11/0x13
[ 75.014842] [<c11e8f2d>] ? driver_probe_device+0x110/0x110
[ 75.043326] [<c11e8a80>] ? bus_add_driver+0x87/0x1bb
[ 75.071736] [<c11550f4>] ? kset_find_obj_hinted+0x43/0x7d
[ 75.104169] [<c144c2a2>] ? rtc_sysfs_init+0x8/0x8
[ 75.126702] [<c11e93ac>] ? driver_register+0x7a/0xd9
[ 75.152575] [<c144c2a2>] ? rtc_sysfs_init+0x8/0x8
[ 75.175534] [<c144c2ad>] ? cmos_init+0xb/0x5a
[ 75.202004] [<c1003068>] ? do_one_initcall+0x68/0x10f
[ 75.226450] [<c1420271>] ? kernel_init+0xb8/0x12f
[ 75.253500] [<c14201b9>] ? parse_early_options+0x18/0x18
[ 75.284824] [<c12b7c3e>] ? kernel_thread_helper+0x6/0x10
[ 75.311271] Code: ff 5a 5b 5e 5f c3 90 a8 03 89 c1 53 75 12 31 d2
bb 64 00 00 00 f7 f3 b8 01 00 00 00 85 d2 75 12 31 d2 bb 90 01 00 00
89 c8 f7 f3
[ 75.333012] Call Trace:
[ 75.334143] [<c11f8e27>] ? rtc_month_days+0x12/0x2c
[ 75.355696] [<c11f8f7a>] ? rtc_valid_tm+0x26/0x45
[ 75.383129] [<c11fa0ef>] ? __rtc_read_alarm+0x1df/0x200
[ 75.407087] [<c11f9313>] ? rtc_device_register+0x196/0x267
[ 75.439018] [<c11fb6df>] ? cmos_do_probe+0x116/0x326
[ 75.466985] [<c11b06b6>] ? pnp_device_probe+0x79/0x96
[ 75.496914] [<c11e8ea9>] ? driver_probe_device+0x8c/0x110
[ 75.523859] [<c11e8f6d>] ? __driver_attach+0x40/0x5b
[ 75.552812] [<c11e8705>] ? bus_for_each_dev+0x37/0x5f
[ 75.582743] [<c11e8d5f>] ? driver_attach+0x11/0x13
[ 75.610170] [<c11e8f2d>] ? driver_probe_device+0x110/0x110
[ 75.636651] [<c11e8a80>] ? bus_add_driver+0x87/0x1bb
[ 75.665599] [<c11550f4>] ? kset_find_obj_hinted+0x43/0x7d
[ 75.697586] [<c144c2a2>] ? rtc_sysfs_init+0x8/0x8
[ 75.720487] [<c11e93ac>] ? driver_register+0x7a/0xd9
[ 75.749417] [<c144c2a2>] ? rtc_sysfs_init+0x8/0x8
[ 75.776371] [<c144c2ad>] ? cmos_init+0xb/0x5a
[ 75.799312] [<c1003068>] ? do_one_initcall+0x68/0x10f
[ 75.829771] [<c1420271>] ? kernel_init+0xb8/0x12f
[ 75.851644] [<c14201b9>] ? parse_early_options+0x18/0x18
[ 75.882168] [<c12b7c3e>] ? kernel_thread_helper+0x6/0x10
The problem turned out to be illegal data in the mdays field of the alarm
timer. The value was 2E (bcd) or 34 (decimal). The value was accepted by
the code in rtc-cmos.c - which checks for 'value <= 0x31'. While this check
is misleading, the biggest problem looks to be in drivers/rtc/interface.c
where an attempt is made to guess the year. This loop is endless when one
of the date/time values is out of range.
The following patch fixes this:
--- a/drivers/rtc/interface.c 2011-10-24 10:02:52.000000000 +0200
+++ b/drivers/rtc/interface.c 2011-10-24 10:05:21.000000000 +0200
@@ -283,9 +283,14 @@
/* Year rollover ... easy except for leap years! */
case year:
dev_dbg(&rtc->dev, "alarm rollover: %s\n", "year");
- do {
- alarm->time.tm_year++;
- } while (rtc_valid_tm(&alarm->time) != 0);
+ if (rtc_valid_tm(&now)) {
+ do {
+ alarm->time.tm_year++;
+ } while (rtc_valid_tm(&alarm->time) != 0
+ &&
alarm->time.tm_year < (now.tm_year + 10));
+ }
+ if (rtc_valid_tm(&alarm->time) != 0)
+ return -EINVAL;
break;
default:
-- Package-specific info:
** Version:
Linux version 2.6.39-bpo.2-686-pae (Debian 2.6.39-3~bpo60+1)
(norbert@tretkowski.de) (gcc version 4.4.5 (Debian 4.4.5-8) ) #1 SMP
Thu Aug 4 11:02:22 UTC 2011
Reply to: