[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Feb 2020 02:25:08 +0100
From: Adam Zabrocki <pi3@....com.pl>
To: lkrg-users@...ts.openwall.com
Subject: Re: [p_lkrg] - BUG: KASAN: global-out-of-bounds in
p_lkrg_fast_hash+0x103/0x350 [p_lkrg]
Hi,
Nope. KASAN will report that we poke the region of memory where they put
redzones. To be specific we calculate the hash from the entire RODATA region
where we might poke such zones. It's ok.
Thanks,
Adam
On Sun, Feb 09, 2020 at 10:32:40PM +0100, bryn1u85 . wrote:
> Hey guys,
>
> I showed something in kernel dmesg. Im wondering if i should be worried
> about this info ?
>
> [ 30.449753] [p_lkrg] Loading LKRG...
> [ 30.456336] Freezing user space processes ... (elapsed 0.007 seconds)
> done.
> [ 30.464323] OOM killer disabled.
> [ 30.464325] [p_lkrg] Verifying 21 potential UMH paths for whitelisting...
> [ 30.465892] [p_lkrg] 5 UMH paths were whitelisted...
> [ 30.955444] [p_lkrg] [kretprobe] register_kretprobe() for
> <ovl_create_or_link> failed! [err=-22]
> [ 30.955516] [p_lkrg] ERROR: Can't hook ovl_create_or_link function :(
> [ 31.306165]
> ==================================================================
> [ 31.306244] *BUG: KASAN: global-out-of-bounds in
> p_lkrg_fast_hash+0x103/0x350 [p_lkrg]*
> [ 31.306301] Read of size 8 at addr ffffffff8ce000a8 by task modprobe/1624
>
> [ 31.306371] CPU: 5 PID: 1624 Comm: modprobe Tainted: G O T
> 5.5.2 #1
> [ 31.306373] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
> [ 31.306374] Call Trace:
> [ 31.306379] dump_stack+0x8b/0xc8
> [ 31.306395] ? p_lkrg_fast_hash+0x103/0x350 [p_lkrg]
> [ 31.306409] ? p_lkrg_fast_hash+0x103/0x350 [p_lkrg]
> [ 31.306412] print_address_description.constprop.6.cold.8+0x1cf/0x314
> [ 31.306426] ? p_lkrg_fast_hash+0x103/0x350 [p_lkrg]
> [ 31.306440] ? p_lkrg_fast_hash+0x103/0x350 [p_lkrg]
> [ 31.306442] __kasan_report.cold.9+0x1a/0x33
> [ 31.306456] ? p_lkrg_fast_hash+0x103/0x350 [p_lkrg]
> [ 31.306459] kasan_report+0x29/0x40
> [ 31.306473] ? p_lkrg_fast_hash+0x103/0x350 [p_lkrg]
> [ 31.306475] check_memory_region+0xf5/0x1d0
> [ 31.306489] p_lkrg_fast_hash+0x103/0x350 [p_lkrg]
> [ 31.306504] ? get_kallsyms_address+0x80/0x80 [p_lkrg]
> [ 31.306508] ? register_kretprobe+0x36a/0x560
> [ 31.306523] hash_from_kernel_rodata+0x8b/0xe0 [p_lkrg]
> [ 31.306537] p_create_database+0x1c2/0x3e0 [p_lkrg]
> [ 31.306552] p_lkrg_register+0x23e/0x1000 [p_lkrg]
> [ 31.306554] ? 0xffffffffc08a0000
> [ 31.306557] do_one_initcall+0x93/0x2d0
> [ 31.306560] ? perf_trace_initcall_level+0x240/0x240
> [ 31.306562] ? kasan_unpoison_shadow+0x33/0x40
> [ 31.306564] ? kasan_unpoison_shadow+0x33/0x40
> [ 31.306568] do_init_module+0x103/0x380
> [ 31.306571] load_module+0x2a58/0x2c30
> [ 31.306578] ? layout_and_allocate+0x1040/0x1040
> [ 31.306580] ? kernel_read+0x95/0xb0
> [ 31.306583] ? kernel_read_file+0x19e/0x330
> [ 31.306587] ? __do_sys_finit_module+0x121/0x1b0
> [ 31.306589] __do_sys_finit_module+0x121/0x1b0
> [ 31.306592] ? __x64_sys_init_module+0x50/0x50
> [ 31.306596] ? __audit_syscall_entry+0x17b/0x1e0
> [ 31.306599] ? ktime_get_coarse_real_ts64+0x4b/0x70
> [ 31.306602] do_syscall_64+0xd6/0x8a3
> [ 31.306605] ? syscall_return_slowpath+0x420/0x420
> [ 31.306609] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 31.306611] RIP: 0033:0x7f833503b99d
> [ 31.306614] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48
> 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05
> <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d bb 64 2c 00 f7 d8 64 89 01 48
> [ 31.306615] RSP: 002b:00007ffedb5566a8 EFLAGS: 00000246 ORIG_RAX:
> 0000000000000139
> [ 31.306618] RAX: ffffffffffffffda RBX: 00005631ac189c10 RCX:
> 00007f833503b99d
> [ 31.306619] RDX: 0000000000000000 RSI: 00005631ac189df0 RDI:
> 0000000000000003
> [ 31.306620] RBP: 00005631ac189df0 R08: 0000000000000000 R09:
> 0000000000000000
> [ 31.306621] R10: 0000000000000003 R11: 0000000000000246 R12:
> 0000000000000000
> [ 31.306622] R13: 00005631ac189d40 R14: 0000000000040000 R15:
> 0000000000000000
>
> *[ 31.306637] The buggy address belongs to the variable:*
> [ 31.306676] __start_rodata+0xa8/0x10a0
>
> [ 31.306717] Memory state around the buggy address:
> [ 31.306751] ffffffff8cdfff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00
> [ 31.306797] ffffffff8ce00000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00
> [ 31.306861] >ffffffff8ce00080: 00 00 00 00 00 fa fa fa fa fa fa fa 00 01
> fa fa
> [ 31.306907] ^
> [ 31.306937] ffffffff8ce00100: fa fa fa fa 00 00 00 07 fa fa fa fa 00 04
> fa fa
> [ 31.306983] ffffffff8ce00180: fa fa fa fa 05 fa fa fa fa fa fa fa 00 00
> 00 00
> [ 31.307028]
> ==================================================================
> [ 31.307073] Disabling lock debugging due to kernel taint
> [ 31.407639] [p_lkrg] LKRG initialized successfully!
> [ 31.407710] OOM killer enabled.
> [ 31.407711] Restarting tasks ... done.
> [ 33.619675] 8139cp 0000:00:03.0 ens3: link up, 100Mbps, full-duplex, lpa
> 0x05E1
> [ 33.779869] [p_lkrg] [JUMP_LABEL <batch mode>] Updating kernel core
> .text section hash!
> [ 33.820095] [p_lkrg] [JUMP_LABEL <batch mode>] Updating kernel core
> .text section hash!
> [ 34.384693] [p_lkrg] [JUMP_LABEL <batch mode>] Updating kernel core
> .text section hash!
> [ 36.466531] [p_lkrg] [JUMP_LABEL <batch mode>] Updating kernel core
> .text section hash!
> [ 36.484063] [p_lkrg] [JUMP_LABEL <batch mode>] Updating kernel core
> .text section hash!
--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
