* [linux-next:master] [vsnprintf] 8d4826cc8a: BUG:KASAN:global-out-of-bounds_in_number
@ 2025-01-13 6:11 kernel test robot
2025-01-13 7:07 ` Linus Torvalds
0 siblings, 1 reply; 3+ messages in thread
From: kernel test robot @ 2025-01-13 6:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: oe-lkp, lkp, linux-kernel, oliver.sang
Hello,
kernel test robot noticed "BUG:KASAN:global-out-of-bounds_in_number" on:
commit: 8d4826cc8a8aca01a3b5e95438dfc0eb3bd589ab ("vsnprintf: collapse the number format state into one single state")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
[test failed on linux-next/master 2b88851f583d3c4e40bcd40cfe1965241ec229dd]
in testcase: blktests
version: blktests-x86_64-827924b-1_20250108
with following parameters:
disk: 1SSD
test: nvme-group-01
nvme_trtype: rdma
config: x86_64-rhel-9.4-func
compiler: gcc-12
test machine: 8 threads 1 sockets Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (Haswell) with 16G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
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/202501131352.e226f995-lkp@intel.com
[ 53.288261][ T1140] BUG: KASAN: global-out-of-bounds in number (lib/vsprintf.c:494)
[ 53.295106][ T1140] Read of size 1 at addr ffffffff843035c8 by task ln/1140
[ 53.302035][ T1140]
[ 53.304209][ T1140] CPU: 1 UID: 0 PID: 1140 Comm: ln Not tainted 6.13.0-rc4-00009-g8d4826cc8a8a #1
[ 53.313125][ T1140] Hardware name: Dell Inc. OptiPlex 9020/0DNKMN, BIOS A05 12/05/2013
[ 53.321002][ T1140] Call Trace:
[ 53.324131][ T1140] <TASK>
[ 53.326913][ T1140] dump_stack_lvl (lib/dump_stack.c:123 (discriminator 1))
[ 53.331252][ T1140] print_address_description+0x2c/0x3a0
[ 53.337665][ T1140] ? number (lib/vsprintf.c:494)
[ 53.341660][ T1140] print_report (mm/kasan/report.c:490)
[ 53.345914][ T1140] ? kasan_addr_to_slab (mm/kasan/common.c:37)
[ 53.350684][ T1140] ? number (lib/vsprintf.c:494)
[ 53.354679][ T1140] kasan_report (mm/kasan/report.c:604)
[ 53.358845][ T1140] ? number (lib/vsprintf.c:494)
[ 53.362841][ T1140] number (lib/vsprintf.c:494)
[ 53.366661][ T1140] ? rmqueue+0x7d0/0x3350
[ 53.371865][ T1140] ? __pfx_number (lib/vsprintf.c:446)
[ 53.376205][ T1140] ? nvmet_port_subsys_allow_link (drivers/nvme/target/configfs.c:1065) nvmet
[ 53.382805][ T1140] ? __pfx_ip4_string (lib/vsprintf.c:1332)
[ 53.387489][ T1140] ? __module_address (kernel/module/main.c:3702)
[ 53.392264][ T1140] ? exit_xfs_fs (fs/xfs/xfs_trace.c:218) xfs
[ 53.397474][ T1140] ? nvmet_port_subsys_allow_link (drivers/nvme/target/configfs.c:1065) nvmet
[ 53.404072][ T1140] ? nvmet_port_subsys_allow_link (drivers/nvme/target/configfs.c:1065) nvmet
[ 53.410671][ T1140] ip4_addr_string_sa (lib/vsprintf.c:1594)
[ 53.415532][ T1140] ? __pfx_ip4_addr_string_sa (lib/vsprintf.c:1569)
[ 53.420908][ T1140] ? __pfx_check_pointer (lib/vsprintf.c:695)
[ 53.425850][ T1140] ? __kernel_text_address (kernel/extable.c:79)
[ 53.430882][ T1140] ? unwind_get_return_address (arch/x86/kernel/unwind_orc.c:369)
[ 53.436353][ T1140] ? __pfx_stack_trace_consume_entry (kernel/stacktrace.c:83)
[ 53.442338][ T1140] ip_addr_string (lib/vsprintf.c:1624)
[ 53.446860][ T1140] ? __pfx_ip_addr_string (lib/vsprintf.c:1604)
[ 53.451889][ T1140] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)
[ 53.457612][ T1140] ? depot_alloc_stack (lib/stackdepot.c:326 lib/stackdepot.c:408)
[ 53.462471][ T1140] pointer (lib/vsprintf.c:2459)
[ 53.466378][ T1140] ? __pfx_pointer (lib/vsprintf.c:2425)
[ 53.470803][ T1140] ? kasan_save_stack (mm/kasan/common.c:49)
[ 53.475487][ T1140] ? __kasan_kmalloc (mm/kasan/common.c:377 mm/kasan/common.c:394)
[ 53.480086][ T1140] ? siw_create_listen (drivers/infiniband/sw/siw/siw_cm.c:1853) siw
[ 53.485555][ T1140] ? iw_cm_listen (drivers/infiniband/core/iwcm.c:585) iw_cm
[ 53.490758][ T1140] ? cma_iw_listen (drivers/infiniband/core/cma.c:2668 (discriminator 12)) rdma_cm
[ 53.496229][ T1140] ? rdma_listen (drivers/infiniband/core/cma.c:3953) rdma_cm
[ 53.501530][ T1140] vsnprintf (lib/vsprintf.c:2848)
[ 53.505700][ T1140] ? do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
[ 53.510214][ T1140] ? entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[ 53.516108][ T1140] ? __pfx_vsnprintf (lib/vsprintf.c:2760)
[ 53.520707][ T1140] vprintk_store (kernel/printk/printk.c:2279)
[ 53.525131][ T1140] ? __pfx_vprintk_store (kernel/printk/printk.c:2244)
[ 53.530071][ T1140] ? __kmalloc_cache_noprof (mm/slub.c:4119 mm/slub.c:4168 mm/slub.c:4324)
[ 53.535445][ T1140] ? kasan_save_track (arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69)
[ 53.540127][ T1140] ? __kasan_kmalloc (mm/kasan/common.c:377 mm/kasan/common.c:394)
[ 53.544724][ T1140] ? siw_create_listen (include/linux/list.h:150 include/linux/list.h:183 drivers/infiniband/sw/siw/siw_cm.c:1861) siw
[ 53.550195][ T1140] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
[ 53.555398][ T1140] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)
[ 53.561119][ T1140] ? alloc_work_entries (include/linux/list.h:150 include/linux/list.h:169 drivers/infiniband/core/iwcm.c:154 drivers/infiniband/core/iwcm.c:180 drivers/infiniband/core/iwcm.c:167) iw_cm
[ 53.566841][ T1140] vprintk_emit (kernel/printk/printk.c:749)
[ 53.567978][ T328] LKP: stdout: 301: Kernel tests: Boot OK!
[ 53.571781][ T1140] ? __pfx_vprintk_emit (kernel/printk/printk.c:2381)
[ 53.571786][ T1140] _printk (kernel/printk/printk.c:2452)
[ 53.571789][ T1140] ? __pfx__printk (kernel/printk/printk.c:2452)
[ 53.577422][ T328]
[ 53.582861][ T1140] ? rdma_bind_addr_dst (drivers/infiniband/core/cma.c:4027) rdma_cm
[ 53.599093][ T1140] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)
[ 53.604299][ T1140] nvmet_rdma_add_port (drivers/nvme/target/rdma.c:1972 (discriminator 1)) nvmet_rdma
[ 53.610379][ T1140] nvmet_enable_port (drivers/nvme/target/core.c:354) nvmet
[ 53.615858][ T1140] nvmet_port_subsys_allow_link (drivers/nvme/target/configfs.c:1065) nvmet
[ 53.622286][ T1140] configfs_symlink (fs/configfs/symlink.c:202)
[ 53.626973][ T1140] ? generic_permission (fs/namei.c:410 fs/namei.c:471)
[ 53.632004][ T1140] ? __pfx_configfs_symlink (fs/configfs/symlink.c:142)
[ 53.637204][ T1140] ? from_kgid (kernel/user_namespace.c:499)
[ 53.641284][ T1140] ? inode_permission (fs/namei.c:593 fs/namei.c:567)
[ 53.646053][ T1140] vfs_symlink (fs/namei.c:4669 fs/namei.c:4653)
[ 53.650319][ T1140] do_symlinkat (fs/namei.c:4695)
[ 53.654658][ T1140] ? __pfx_do_symlinkat (fs/namei.c:4677)
[ 53.659513][ T1140] ? getname_flags (include/linux/audit.h:316)
[ 53.664628][ T1140] __x64_sys_symlinkat (fs/namei.c:4708)
[ 53.669398][ T1140] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
[ 53.673739][ T1140] ? handle_pte_fault (mm/memory.c:5801)
[ 53.678596][ T1140] ? _raw_spin_lock (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:134 kernel/locking/spinlock.c:154)
[ 53.683106][ T1140] ? __pfx_handle_pte_fault (mm/memory.c:5758)
[ 53.688319][ T1140] ? file_close_fd_locked (arch/x86/include/asm/bitops.h:227 (discriminator 4) arch/x86/include/asm/bitops.h:239 (discriminator 4) include/asm-generic/bitops/instrumented-non-atomic.h:142 (discriminator 4) fs/file.c:325 (discriminator 4) fs/file.c:599 (discriminator 4) fs/file.c:684 (discriminator 4))
[ 53.693522][ T1140] ? __handle_mm_fault (mm/memory.c:5944)
[ 53.698552][ T1140] ? __pfx___handle_mm_fault (mm/memory.c:5853)
[ 53.703839][ T1140] ? file_close_fd_locked (arch/x86/include/asm/bitops.h:227 (discriminator 4) arch/x86/include/asm/bitops.h:239 (discriminator 4) include/asm-generic/bitops/instrumented-non-atomic.h:142 (discriminator 4) fs/file.c:325 (discriminator 4) fs/file.c:599 (discriminator 4) fs/file.c:684 (discriminator 4))
[ 53.709042][ T1140] ? __count_memcg_events (mm/memcontrol.c:583 mm/memcontrol.c:857)
[ 53.714245][ T1140] ? handle_mm_fault (mm/memory.c:5986 mm/memory.c:6138)
[ 53.719018][ T1140] ? do_user_addr_fault (include/linux/rcupdate.h:882 include/linux/mm.h:742 arch/x86/mm/fault.c:1340)
[ 53.724047][ T1140] ? exc_page_fault (arch/x86/include/asm/irqflags.h:37 arch/x86/include/asm/irqflags.h:92 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)
[ 53.728558][ T1140] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
[ 53.734280][ T1140] RIP: 0033:0x7f54290d89f7
[ 53.738532][ T1140] Code: 73 01 c3 48 8b 0d 09 84 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0a 01 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d d9 83 0d 00 f7 d8 64 89 01 48
All code
========
0: 73 01 jae 0x3
2: c3 ret
3: 48 8b 0d 09 84 0d 00 mov 0xd8409(%rip),%rcx # 0xd8413
a: f7 d8 neg %eax
c: 64 89 01 mov %eax,%fs:(%rcx)
f: 48 83 c8 ff or $0xffffffffffffffff,%rax
13: c3 ret
14: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
1b: 00 00 00
1e: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
23: b8 0a 01 00 00 mov $0x10a,%eax
28: 0f 05 syscall
2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction
30: 73 01 jae 0x33
32: c3 ret
33: 48 8b 0d d9 83 0d 00 mov 0xd83d9(%rip),%rcx # 0xd8413
3a: f7 d8 neg %eax
3c: 64 89 01 mov %eax,%fs:(%rcx)
3f: 48 rex.W
Code starting with the faulting instruction
===========================================
0: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
6: 73 01 jae 0x9
8: c3 ret
9: 48 8b 0d d9 83 0d 00 mov 0xd83d9(%rip),%rcx # 0xd83e9
10: f7 d8 neg %eax
12: 64 89 01 mov %eax,%fs:(%rcx)
15: 48 rex.W
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20250113/202501131352.e226f995-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [linux-next:master] [vsnprintf] 8d4826cc8a: BUG:KASAN:global-out-of-bounds_in_number
2025-01-13 6:11 [linux-next:master] [vsnprintf] 8d4826cc8a: BUG:KASAN:global-out-of-bounds_in_number kernel test robot
@ 2025-01-13 7:07 ` Linus Torvalds
2025-01-13 13:26 ` Oliver Sang
0 siblings, 1 reply; 3+ messages in thread
From: Linus Torvalds @ 2025-01-13 7:07 UTC (permalink / raw)
To: kernel test robot; +Cc: oe-lkp, lkp, linux-kernel
On Sun, 12 Jan 2025 at 22:11, kernel test robot <oliver.sang@intel.com> wrote:
>
> [ 53.288261][ T1140] BUG: KASAN: global-out-of-bounds in number (lib/vsprintf.c:494)
> [ 53.295106][ T1140] Read of size 1 at addr ffffffff843035c8 by task ln/1140
Bah. That's this:
494 tmp[i++] = (hex_asc_upper[((unsigned
char)num) & mask] | locase);
and the one-byte read is that
hex_asc_upper[((unsigned char)num) & mask]
access.
And 'mask' is supposed to be either 7 or 15 (for base 8 or 16
respectively), but it turns out that this all comes from (I think)
pr_info("enabling port %d (%pISpcs)\n",
le16_to_cpu(nport->disc_addr.portid),
(struct sockaddr *)&port->addr);
in nvmet_rdma_add_port(), and that commit 8d4826cc8a8a ("vsnprintf:
collapse the number format state into one single state") doesn't set
the number base for non-numeric formats (like the 'p').
Or rather, it sets the base to zero.
The '%pISpcs' causes the call chain to be pointer() ->
ip_addr_string() -> ip4_addr_string_sa() -> number(), and there the
number base being zero confuses things terminally.
And then when the 'p' logic calls 'number()' with zero base then
confuses number printing and the 'mask' logic.
Most other number() callers - for example special_hex_number - will
set the base explicitly, but several of the more specialized pointer
things seem to just pass in the 'spec' from the original pointer
format, and expects the "base" of a pointer spec to be 10.
Which wasn't very obvious, butused to be the default, and that commit
broke that.
Does this trivial one-liner (sorry, whitespace-damaged) fix it?
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -2682,7 +2682,7 @@ struct fmt format_decode(struct fmt fmt,
struct printf_spec *spec)
p = lookup_state + *fmt.str;
}
if (p->state) {
- spec->base = p->base;
+ if (p->base) spec->base = p->base;
spec->flags |= p->flags_or_double_size;
fmt.state = p->state;
fmt.str++;
so that the format decoding will only set the spec base to something
else than 10 if the format actually has a base (i.e. is a
FORMAT_STATE_NUM).
Linus
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [linux-next:master] [vsnprintf] 8d4826cc8a: BUG:KASAN:global-out-of-bounds_in_number
2025-01-13 7:07 ` Linus Torvalds
@ 2025-01-13 13:26 ` Oliver Sang
0 siblings, 0 replies; 3+ messages in thread
From: Oliver Sang @ 2025-01-13 13:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: oe-lkp, lkp, linux-kernel, oliver.sang
hi, Linus,
On Sun, Jan 12, 2025 at 11:07:02PM -0800, Linus Torvalds wrote:
> On Sun, 12 Jan 2025 at 22:11, kernel test robot <oliver.sang@intel.com> wrote:
> >
> > [ 53.288261][ T1140] BUG: KASAN: global-out-of-bounds in number (lib/vsprintf.c:494)
> > [ 53.295106][ T1140] Read of size 1 at addr ffffffff843035c8 by task ln/1140
>
> Bah. That's this:
>
> 494 tmp[i++] = (hex_asc_upper[((unsigned
> char)num) & mask] | locase);
>
> and the one-byte read is that
>
> hex_asc_upper[((unsigned char)num) & mask]
>
> access.
>
> And 'mask' is supposed to be either 7 or 15 (for base 8 or 16
> respectively), but it turns out that this all comes from (I think)
>
> pr_info("enabling port %d (%pISpcs)\n",
> le16_to_cpu(nport->disc_addr.portid),
> (struct sockaddr *)&port->addr);
>
> in nvmet_rdma_add_port(), and that commit 8d4826cc8a8a ("vsnprintf:
> collapse the number format state into one single state") doesn't set
> the number base for non-numeric formats (like the 'p').
>
> Or rather, it sets the base to zero.
>
> The '%pISpcs' causes the call chain to be pointer() ->
> ip_addr_string() -> ip4_addr_string_sa() -> number(), and there the
> number base being zero confuses things terminally.
>
> And then when the 'p' logic calls 'number()' with zero base then
> confuses number printing and the 'mask' logic.
>
> Most other number() callers - for example special_hex_number - will
> set the base explicitly, but several of the more specialized pointer
> things seem to just pass in the 'spec' from the original pointer
> format, and expects the "base" of a pointer spec to be 10.
>
> Which wasn't very obvious, butused to be the default, and that commit
> broke that.
>
> Does this trivial one-liner (sorry, whitespace-damaged) fix it?
yes, below diff fixes the issue we reported. thanks
Tested-by: kernel test robot <oliver.sang@intel.com>
>
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -2682,7 +2682,7 @@ struct fmt format_decode(struct fmt fmt,
> struct printf_spec *spec)
> p = lookup_state + *fmt.str;
> }
> if (p->state) {
> - spec->base = p->base;
> + if (p->base) spec->base = p->base;
> spec->flags |= p->flags_or_double_size;
> fmt.state = p->state;
> fmt.str++;
>
> so that the format decoding will only set the spec base to something
> else than 10 if the format actually has a base (i.e. is a
> FORMAT_STATE_NUM).
>
> Linus
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-01-13 13:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-13 6:11 [linux-next:master] [vsnprintf] 8d4826cc8a: BUG:KASAN:global-out-of-bounds_in_number kernel test robot
2025-01-13 7:07 ` Linus Torvalds
2025-01-13 13:26 ` Oliver Sang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox