On Sun, Jun 11, 2023 at 09:41:30PM +0800, kernel test robot wrote: > the issue we found below is by clang-15, but we confirmed clang-15 we use is > commit 8dfdcc7b7b in llvm-project. it supports the flag already. Interesting! Thanks for the report. > [ 228.605608][ C1] BUG: unable to handle page fault for address: 04090300 > [...] > [ 228.608262][ C1] EIP: string (lib/vsprintf.c:644 lib/vsprintf.c:726) > [...] > [ 228.608262][ C1] Call Trace: > [ 228.608262][ C1] <SOFTIRQ> > [ 228.608262][ C1] vsnprintf (lib/vsprintf.c:2817) > [ 228.608262][ C1] vprintk_store (kernel/printk/printk.c:2191) > [ 228.608262][ C1] vprintk_emit (kernel/printk/printk.c:2288) > [ 228.608262][ C1] vprintk_default (kernel/printk/printk.c:2318) > [ 228.608262][ C1] vprintk (kernel/printk/printk_safe.c:50) > [ 228.608262][ C1] _printk (kernel/printk/printk.c:2331) > [ 228.608262][ C1] __ubsan_handle_out_of_bounds (lib/ubsan.c:209 lib/ubsan.c:343) This is a crash within the UBSAN handler! That's very unexpected. > [ 228.608262][ C1] get_string (drivers/usb/gadget/composite.c:1314) > [ 228.608262][ C1] composite_setup (drivers/usb/gadget/composite.c:1871) > [ 228.608262][ C1] dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:?) And the out-of-bounds condition got triggered in dummy_hcd. I also see this is happening in SOFTIRQ context. I wonder if there is a problem with UBSAN vs SOFTIRQ. Again, I'd find that surprising... I'll see what I can find... -- Kees Cook
