Messages in this thread | | | Date | Sat, 11 Mar 2017 18:09:03 +0200 (EET) | From | Meelis Roos <> | Subject | Re: UBSAN: Undefined behaviour in kernel/time/tick-sched.c:600:9 |
| |
> > Cc'ing KASAN folks > > > >> (Retry with fixed address ox 86 list) > >> > >> This HP Netserver LT6000R, quad P3 Xeon. Trying > >> 4.11.0-rc1-00088-gec3b93a, I got the following UBSAN warning that was > >> not there in 4.10: > >> > >> [ 14.820437] ================================================================================ > >> [ 14.820534] UBSAN: Undefined behaviour in kernel/time/tick-sched.c:600:9 > >> [ 14.820594] signed integer overflow: > >> [ 14.820645] 11567464533 + 3985952 cannot be represented in type 'long long int' > > > > This does not make any sense: > > > > 11567464533 + 3985952 = 0x2b1798055 + 0x3cd220 = 0x2b1b65275 > > > > which definitely fits into a 'long long int' aka 64 bit > > > Is there a reproducer? Or can you print the values right in > tick-sched.c with pr_err?
No, it's not reproducible at will - subsequent reboots did not cause it, only the KASAN warning from drivers/acpi/acpica/dsutils.c:640 and arch/x86/events/intel/p6.c:115:29 are there as usual.
gcc version 6.2.0 20160927 (Debian 6.2.0-5)
> > The code in ubsan.c looks more complex than I would expect from that > code. There is probably some potential for truncation: > > static s_max get_signed_val(struct type_descriptor *type, unsigned long val) > { > if (is_inline_int(type)) { > unsigned extra_bits = sizeof(s_max)*8 - type_bit_width(type); > return ((s_max)val) << extra_bits >> extra_bits; > } > if (type_bit_width(type) == 64) > return *(s64 *)val; > return *(s_max *)val; > } > > > > >> [ 14.820722] CPU: 3 PID: 135 Comm: startpar Not tainted 4.11.0-rc1-00088-gec3b93a #61 > >> [ 14.820793] Hardware name: Hewlett Packard HP NetServer/HP System Board, BIOS 4.06.46 PW 06/25/2003 > >> [ 14.820863] Call Trace: > >> [ 14.820950] ? dump_stack+0x45/0x6e > >> [ 14.821022] ? ubsan_epilogue+0xb/0x40 > >> [ 14.821081] ? handle_overflow+0xb6/0xe0 > >> [ 14.821146] ? smp_trace_apic_timer_interrupt+0x85/0x100 > >> [ 14.821208] ? __ubsan_handle_add_overflow+0xf/0x20 > >> [ 14.821281] ? get_cpu_idle_time_us+0x204/0x2b0 > >> [ 14.821350] ? get_idle_time+0x57/0xb0 > >> [ 14.821405] ? show_stat+0x217/0x10c0 > >> [ 14.821463] ? seq_open+0x33/0xb0 > >> [ 14.821519] ? __d_alloc+0x149/0x2c0 > >> [ 14.821574] ? get_iowait_time+0xb0/0xb0 > >> [ 14.821628] ? single_open+0x4d/0xb0 > >> [ 14.821685] ? single_open_size+0x37/0xc0 > >> [ 14.821748] ? path_openat+0x7d5/0x1bd0 > >> [ 14.821804] ? seq_read+0xca/0x6f0 > >> [ 14.821872] ? _copy_to_user+0x5e/0x90 > >> [ 14.821937] ? cp_new_stat64+0x108/0x130 > >> [ 14.821991] ? __seq_open_private+0x80/0x80 > >> [ 14.822062] ? proc_reg_read+0x7c/0x120 > >> [ 14.822117] ? proc_reg_write+0x120/0x120 > >> [ 14.822172] ? __vfs_read+0x3e/0x240 > >> [ 14.822228] ? vfs_read+0x92/0x1b0 > >> [ 14.822282] ? SyS_read+0x45/0xa0 > >> [ 14.822338] ? do_fast_syscall_32+0xb9/0x220 > >> [ 14.822395] ? entry_SYSENTER_32+0x47/0x71 > >> [ 14.822447] > >> ================================================================================ >
-- Meelis Roos (mroos@ut.ee) http://www.cs.ut.ee/~mroos/
| |