diff mbox series

[kees:devel/overflow/sanitizers,overflow] 660787b56e: UBSAN:signed-integer-overflow_in_lib/test_memcat_p.c

Message ID 202401302219.db90a6d5-oliver.sang@intel.com (mailing list archive)
State New
Headers show
Series [kees:devel/overflow/sanitizers,overflow] 660787b56e: UBSAN:signed-integer-overflow_in_lib/test_memcat_p.c | expand

Commit Message

kernel test robot Jan. 30, 2024, 2:52 p.m. UTC 
Hello,

kernel test robot noticed "UBSAN:signed-integer-overflow_in_lib/test_memcat_p.c" on:

commit: 660787b56e6e97ddc34c7882cbe1228f4040ef74 ("overflow: Reintroduce signed and unsigned overflow sanitizers")
https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git devel/overflow/sanitizers

in testcase: boot

compiler: gcc-11
test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G

(please refer to attached dmesg/kmsg for entire log/backtrace)


we noticed this commit is reintroducing "signed and unsigned overflow
sanitizers", there is below config diff between parent and this commit in our
buildings:


while testing, we observed below different (and same part) between parent and
this commit:

ea804316c9db5148 660787b56e6e97ddc34c7882cbe
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
          6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_arch/x86/kernel/cpu/intel.c
          6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_arch/x86/kernel/cpu/topology.c
          6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_fs/namespace.c
          6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_fs/read_write.c
          6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_include/linux/rhashtable.h
          6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_include/net/tcp.h
           :6          100%           6:6     dmesg.UBSAN:signed-integer-overflow_in_lib/test_memcat_p.c


this looks like the commit uncovered issue. but since it's hard for us to back
port this commit to each commit while bisecting, we cannot capture the real
first bad commit. not sure if this report could help somebody to investigate
the real issue?



If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202401302219.db90a6d5-oliver.sang@intel.com


[   42.894536][    T1] ------------[ cut here ]------------
[   42.895474][    T1] UBSAN: signed-integer-overflow in lib/test_memcat_p.c:47:10
[   42.897128][    T1] 6570 * 725861 cannot be represented in type 'int'
[   42.898391][    T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1-00007-g660787b56e6e #1
[   42.899962][    T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[   42.901661][    T1] Call Trace:
[ 42.902009][ T1] dump_stack_lvl (??:?) 
[ 42.902009][ T1] dump_stack (??:?) 
[ 42.902009][ T1] handle_overflow (ubsan.c:?) 
[ 42.902009][ T1] ? kmemleak_alloc (??:?) 
[ 42.902009][ T1] ? kmalloc_trace (??:?) 
[ 42.902009][ T1] ? test_memcat_p_init (test_memcat_p.c:?) 
[ 42.902009][ T1] __ubsan_handle_mul_overflow (??:?) 
[ 42.902009][ T1] test_memcat_p_init (test_memcat_p.c:?) 
[ 42.902009][ T1] ? trace_hardirqs_on (??:?) 
[ 42.902009][ T1] ? _raw_spin_unlock_irqrestore (??:?) 
[ 42.902009][ T1] ? test_string_helpers_init (test_memcat_p.c:?) 
[ 42.902009][ T1] do_one_initcall (??:?) 
[ 42.902009][ T1] ? parameq (??:?) 
[ 42.902009][ T1] ? parse_args (??:?) 
[ 42.902009][ T1] do_initcalls (main.c:?) 
[ 42.902009][ T1] ? rdinit_setup (main.c:?) 
[ 42.902009][ T1] kernel_init_freeable (main.c:?) 
[ 42.902009][ T1] ? rest_init (main.c:?) 
[ 42.902009][ T1] kernel_init (main.c:?) 
[ 42.902009][ T1] ? schedule_tail (??:?) 
[ 42.902009][ T1] ret_from_fork (??:?) 
[ 42.902009][ T1] ? rest_init (main.c:?) 
[ 42.902009][ T1] ret_from_fork_asm (??:?) 
[ 42.902009][ T1] entry_INT80_32 (??:?) 
[   42.924183][    T1] ---[ end trace ]---
[   42.925743][    T1] test_memcat_p: test passed


The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240130/202401302219.db90a6d5-oliver.sang@intel.com

Comments

Kees Cook Jan. 31, 2024, 12:23 a.m. UTC | #1 
On Tue, Jan 30, 2024 at 10:52:56PM +0800, kernel test robot wrote:
> 
> 
> Hello,
> 
> kernel test robot noticed "UBSAN:signed-integer-overflow_in_lib/test_memcat_p.c" on:
> 
> commit: 660787b56e6e97ddc34c7882cbe1228f4040ef74 ("overflow: Reintroduce signed and unsigned overflow sanitizers")
> https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git devel/overflow/sanitizers
> 
> in testcase: boot
> 
> compiler: gcc-11
> test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
> 
> (please refer to attached dmesg/kmsg for entire log/backtrace)
> 
> 
> we noticed this commit is reintroducing "signed and unsigned overflow
> sanitizers", there is below config diff between parent and this commit in our
> buildings:
> 
> --- ea804316c9db5148d2bb0c1f40f70d7a83404638/.config    2024-01-26 22:09:35.046768122 +0800
> +++ 660787b56e6e97ddc34c7882cbe1228f4040ef74/.config    2024-01-26 19:53:20.693434428 +0800
> @@ -6706,6 +6706,7 @@ CONFIG_UBSAN_BOUNDS_STRICT=y
>  CONFIG_UBSAN_SHIFT=y
>  # CONFIG_UBSAN_DIV_ZERO is not set
>  CONFIG_UBSAN_UNREACHABLE=y
> +CONFIG_UBSAN_SIGNED_WRAP=y
>  # CONFIG_UBSAN_BOOL is not set
>  # CONFIG_UBSAN_ENUM is not set
>  # CONFIG_UBSAN_ALIGNMENT is not set

Hi! Thanks for the testing!

The added Kconfig is:

+config UBSAN_SIGNED_WRAP
+       bool "Perform checking for signed arithmetic wrap-around"
+       default UBSAN
+       depends on !COMPILE_TEST
+       depends on $(cc-option,-fsanitize=signed-integer-overflow)

So it looks like since your build already had CONFIG_UBSAN=y the signed
sanitizer got enabled too since it doesn't set CONFIG_COMPILE_TEST.

> while testing, we observed below different (and same part) between parent and
> this commit:
> 
> ea804316c9db5148 660787b56e6e97ddc34c7882cbe
> ---------------- ---------------------------
>        fail:runs  %reproduction    fail:runs
>            |             |             |
>           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_arch/x86/kernel/cpu/intel.c
>           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_arch/x86/kernel/cpu/topology.c
>           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_fs/namespace.c
>           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_fs/read_write.c
>           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_include/linux/rhashtable.h
>           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_include/net/tcp.h

Are these shift-out-of-bounds warnings new?

>            :6          100%           6:6     dmesg.UBSAN:signed-integer-overflow_in_lib/test_memcat_p.c

This is new for sure, catching an issue you show below...

> this looks like the commit uncovered issue. but since it's hard for us to back
> port this commit to each commit while bisecting, we cannot capture the real
> first bad commit. not sure if this report could help somebody to investigate
> the real issue?

Yeah, I think there is an unexpected wrap-around in test_memcat_p.c:

> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202401302219.db90a6d5-oliver.sang@intel.com
> 
> 
> [   42.894536][    T1] ------------[ cut here ]------------
> [   42.895474][    T1] UBSAN: signed-integer-overflow in lib/test_memcat_p.c:47:10
> [   42.897128][    T1] 6570 * 725861 cannot be represented in type 'int'

I'm surprised to see the sanitizer catching anything here since the
kernel is built with -fno-strict-overflow, but regardless, I'll send a
patch...

-Kees
kernel test robot Jan. 31, 2024, 1:34 a.m. UTC | #2 
hi, Kees,

On Tue, Jan 30, 2024 at 04:23:06PM -0800, Kees Cook wrote:
> On Tue, Jan 30, 2024 at 10:52:56PM +0800, kernel test robot wrote:
> > 

...
 
> > while testing, we observed below different (and same part) between parent and
> > this commit:
> > 
> > ea804316c9db5148 660787b56e6e97ddc34c7882cbe
> > ---------------- ---------------------------
> >        fail:runs  %reproduction    fail:runs
> >            |             |             |
> >           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_arch/x86/kernel/cpu/intel.c
> >           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_arch/x86/kernel/cpu/topology.c
> >           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_fs/namespace.c
> >           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_fs/read_write.c
> >           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_include/linux/rhashtable.h
> >           6:6            0%           6:6     dmesg.UBSAN:shift-out-of-bounds_in_include/net/tcp.h
> 
> Are these shift-out-of-bounds warnings new?

no, they also happen on parent commit.

thanks a lot for all guildance!

> 
> >            :6          100%           6:6     dmesg.UBSAN:signed-integer-overflow_in_lib/test_memcat_p.c
> 
> This is new for sure, catching an issue you show below...
> 
> > this looks like the commit uncovered issue. but since it's hard for us to back
> > port this commit to each commit while bisecting, we cannot capture the real
> > first bad commit. not sure if this report could help somebody to investigate
> > the real issue?
> 
> Yeah, I think there is an unexpected wrap-around in test_memcat_p.c:
> 
> > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > the same patch/commit), kindly add following tags
> > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > | Closes: https://lore.kernel.org/oe-lkp/202401302219.db90a6d5-oliver.sang@intel.com
> > 
> > 
> > [   42.894536][    T1] ------------[ cut here ]------------
> > [   42.895474][    T1] UBSAN: signed-integer-overflow in lib/test_memcat_p.c:47:10
> > [   42.897128][    T1] 6570 * 725861 cannot be represented in type 'int'
> 
> I'm surprised to see the sanitizer catching anything here since the
> kernel is built with -fno-strict-overflow, but regardless, I'll send a
> patch...
> 
> -Kees
> 
> -- 
> Kees Cook
diff mbox series

Patch

--- ea804316c9db5148d2bb0c1f40f70d7a83404638/.config    2024-01-26 22:09:35.046768122 +0800
+++ 660787b56e6e97ddc34c7882cbe1228f4040ef74/.config    2024-01-26 19:53:20.693434428 +0800
@@ -6706,6 +6706,7 @@  CONFIG_UBSAN_BOUNDS_STRICT=y
 CONFIG_UBSAN_SHIFT=y
 # CONFIG_UBSAN_DIV_ZERO is not set
 CONFIG_UBSAN_UNREACHABLE=y
+CONFIG_UBSAN_SIGNED_WRAP=y
 # CONFIG_UBSAN_BOOL is not set
 # CONFIG_UBSAN_ENUM is not set
 # CONFIG_UBSAN_ALIGNMENT is not set