Hi YAMAZAKI,

On Mon, Sep 8, 2025 at 11:11 PM YAMAZAKI MASAMITSU(山崎 真光)
<yamazaki-m...@nec.com> wrote:
>
> Hi,Liu
>
> Thanks your patch. What kind of environment did you test
> this KASLR problem ? Especialy is it kernel verssion
> 6.11.8-300.fc41.x86_64 ? Have you checked other versions?
> Additionally, do you know the version of eppic ?

I had primarily tested the patchset within 6.11.8-300.fc41.x86_64,
since it has been a while, and I have updated my kernel to 6.16.3. The
dwarf issue(PATCH 01/10 & PATCH 02/10) can still be reproduced there,
see the following:

1) Env:
$ uname -a
Linux localhost.localdomain 6.16.3 #3 SMP PREEMPT_DYNAMIC Thu Aug 28
15:12:38 2025 x86_64 GNU/Linux

liutgnu@localhost:~/sources/up-makedumpfile$ git log --oneline | head -2
65bf4c9 [PATCH v2] Fix a data race in multi-threading mode (--num-threads=N)

liutgnu@localhost:~/sources/up-eppic$ git branch
* master
  v5.0
liutgnu@localhost:~/sources/up-eppic$ git log --oneline | head -2
72da440 Merge pull request #20 from yselkowitz/master
5ecafb7 Fix build with glibc-2.42

liutgnu@localhost:~/sources/up-makedumpfile$ cat eppic_scripts/test.c
string test_opt() {...}
string test_usage() {...}
static void test_showusage() {...}
string test_help() {...}
int test()
{
printf("linux banner: %lx\n", (unsigned long)&linux_banner);
return 0;
}

2) The recursive issue as fixed in PATCH 02/10:

$ ./makedumpfile -d 31 -l vmcore /tmp/out -x vmlinux --eppic
eppic_scripts/test.c --dry-run
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7c3ca4b in pthread_rwlock_unlock@GLIBC_2.2.5 () from
target:/lib64/libc.so.6
(gdb) bt
...
#5  0x0000000000409a67 in search_domain (die=0x7fffff7ff220,
found=0x7fffffffcf24) at dwarf_info.c:904
#6  0x0000000000409978 in search_domain (die=0x7fffff7ff290,
found=0x7fffffffcf24) at dwarf_info.c:865
#7  0x0000000000409978 in search_domain (die=0x7fffff7ff300,
found=0x7fffffffcf24) at dwarf_info.c:865
...
#74820 0x0000000000409978 in search_domain (die=0x7fffffffcdb0,
found=0x7fffffffcf24) at dwarf_info.c:865
#74821 0x0000000000409978 in search_domain (die=0x7fffffffce60,
found=0x7fffffffcf24) at dwarf_info.c:865
#74822 0x0000000000409bfc in search_die_tree (die=0x7fffffffce60,
found=0x7fffffffcf24) at dwarf_info.c:953
#74823 0x0000000000409b2c in search_die_tree (die=0x7fffffffce90,
found=0x7fffffffcf24) at dwarf_info.c:935
#74824 0x0000000000409ec7 in get_debug_info () at dwarf_info.c:1010
#74825 0x000000000040af2a in get_domain (symname=0x90aeb0 "memset",
cmd=13, die=0x7fffffffd020) at dwarf_info.c:1381
#74826 0x00000000004143d0 in get_domain_all (symname=0x90aeb0
"memset", cmd=13, die=0x7fffffffd020) at erase_info.c:1965
#74827 0x00007ffff76c0fc1 in apigetctype (ctype=7, name=0x90aeb0
"memset", tout=0x48be80) at extension_eppic.c:280
#74828 0x00007ffff76cab1b in eppic_getctype (ctype=7, name=0x90aeb0
"memset", silent=1) at eppic_api.c:454
#74829 0x00007ffff76d56c0 in eppiclex () at lex.eppic.c:1831
#74830 0x00007ffff76d2ae5 in eppicparse () at eppic.tab.c:1804
#74831 0x00007ffff76c1f4d in eppic_parsexpr (expr=0x7ffff7707364 "int
memset(char *, int, int)") at eppic_func.c:437
#74832 0x00007ffff76c740e in eppic_builtin (proto=0x7ffff7707364 "int
memset(char *, int, int)", fp=0x7ffff76c1349 <eppic_memset>)
    at eppic_builtin.c:252
#74833 0x00007ffff76c1420 in eppic_init (fun_ptr=0x473600 <eppic_cb>)
at extension_eppic.c:461
#74834 0x0000000000414f83 in process_eppic_file
(name_config=0x7fffffffe0b7 "eppic_scripts/test.c") at
erase_info.c:2226
#74835 0x0000000000415513 in gather_filter_info () at erase_info.c:2357
#74836 0x000000000044f237 in create_dumpfile () at makedumpfile.c:10885
#74837 0x000000000045569a in main (argc=11, argv=0x7fffffffdc08) at
makedumpfile.c:12478
(gdb) frame 74821
#74821 0x0000000000409978 in search_domain (die=0x7fffffffce60,
found=0x7fffffffcf24) at dwarf_info.c:865
865 search_domain(&child, found);
(gdb) p name
$1 = 0x7ffff1bdb782 "&core::num::fmt::Part"
...
(gdb) frame 6
#6  0x0000000000409978 in search_domain (die=0x7fffff7ff290,
found=0x7fffffffcf24) at dwarf_info.c:865
865 search_domain(&child, found);
(gdb) p name
$8 = 0x7ffff1bdbe1f "and_then<char, (),
core::net::parser::{impl#0}::read_given_char::{closure#0}::{closure_env#0}>"

So the stack overflows, and is caused by rust symbols. I have no idea
why rust symbols will cause this, so in PATCH 02/10, I skipped all
rust symbols for now. With the patch applied, no segfaults.

3) The kaslr issue as fixed in PATCH 01/10:

$ ./makedumpfile -d 31 -l vmcore /tmp/out -x vmlinux --eppic
eppic_scripts/test.c --dry-run
__vtop4_x86_64: Can't get a valid pmd_pte.
readmem: Can't convert a virtual address(ffffffff828445f0) to physical address.
readmem: type_addr: 0, addr:ffffffff828445f0, size:1
linux banner: ffffffff828445f0

crash> sym linux_banner
ffffffff938445f0 (D) linux_banner

liutgnu@localhost:/lib/modules/6.16.3/build$ cat System.map |grep linux_banner
ffffffff828445f0 D linux_banner

So the value outputted by eppic script is not kaslred. With the patch
applied, the eppic can output the correct value as crash's:

$ ./makedumpfile -d 31 -l vmcore /tmp/out -x vmlinux --eppic
eppic_scripts/test.c --dry-run
linux banner: ffffffff938445f0

Hope the debug process can help for PATCH 01/10 & PATCH 02/10

Thanks,
Tao Liu

>
> Also, if possible, show this problem results when an error occurs
> and the results when it is correct. Please tell me.
>
> Sincerely
>
> On 2025/06/10 18:57, Tao Liu wrote:
> > There is a bug of not supporting randomized kernel address, this patch fix 
> > it.
> >
> > Signed-off-by: Tao Liu <l...@redhat.com>
> > ---
> >   erase_info.c | 8 ++++----
> >   1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/erase_info.c b/erase_info.c
> > index af6bfae..b67d1d0 100644
> > --- a/erase_info.c
> > +++ b/erase_info.c
> > @@ -1881,7 +1881,7 @@ get_symbol_addr_all(char *name) {
> >       if (!strcmp(get_dwarf_module_name(), "vmlinux")) {
> >               symbol_addr = get_symbol_addr(name);
> >               if (symbol_addr)
> > -                     return symbol_addr;
> > +                     return symbol_addr + info->kaslr_offset;
> >
> >               vmlinux_searched = 1;
> >       }
> > @@ -1942,9 +1942,9 @@ get_symbol_addr_all(char *name) {
> >        * this function is called with debuginfo set to a particular
> >        * kernel module and we are looking for symbol in vmlinux
> >        */
> > -     if (!vmlinux_searched)
> > -             return get_symbol_addr(name);
> > -     else
> > +     if (!vmlinux_searched && !!(symbol_addr = get_symbol_addr(name))) {
> > +             return symbol_addr + info->kaslr_offset;
> > +     } else
> >               return NOT_FOUND_SYMBOL;
> >   }
> >
--
Crash-utility mailing list -- devel@lists.crash-utility.osci.io
To unsubscribe send an email to devel-le...@lists.crash-utility.osci.io
https://${domain_name}/admin/lists/devel.lists.crash-utility.osci.io/
Contribution Guidelines: https://github.com/crash-utility/crash/wiki

Reply via email to