[Libguestfs] libldm crashes in a linux-sandbox context

Laszlo Ersek
2023-06-19T12:16:25Z

On 6/19/23 13:18, Vincent MAILHOL wrote:
> On Fri. 16 juin 2023 at 16:34, Richard W.M. Jones <rjones at
redhat.com> wrote:
> (...)
>>> Last thing, the segfault on ldmtool [1] still seems a valid issue.
>>> Even if I now do have a workaround for my problem, that segfault
might
>>> be worth a bit more investigation.
>>
>> Yes that does look like a real problem.  Does it crash if you just run
>> ldmtool as a normal command, nothing to do with libguestfs?  Might be
>> a good idea to try to get a stack trace of the crash.
>
> The fact is that it only crashes with the UUID 65534 in the qemu VM. I
> am not sure what command line is passed to ldmtool for this crash to
> occur.
>
> I can help to gather information, but my biggest issue is that I do
> not know how to interact with the VM under /tmp/.guestfs-1001/
>
>   [    0.777352] ldmtool[164]: segfault at 0 ip 0000563a225cd6a5 sp
> 00007ffe54965a60 error 4 in ldmtool[563a225cb000+3000]
>                                         ^^^^ ^^^^^^^^^^^^^^^^^^^
> This smells like a NULL pointer dereference.

... Hey this is actually my line from an email I started writing earlier
today :) , but I then decided not to send it.

It certainly looks like a null pointer dereference, and if you
disassemble the instruction byte stream dump (the "Code:" line from
the
kernel log) with (e.g.) ndisasm, that confirms it. You get something like

00000025  E8DBFDFFFF        call 0xfffffffffffffe05
0000002A  4C8B20            mov r12,[rax]              <---- crash
0000002D  4889442408        mov [rsp+0x8],rax
00000032  4C89E7            mov rdi,r12
00000035  E80BE1FFFF        call 0xffffffffffffe145

with the "mov r12,[rax]" instruction faulting (with the previously
called function presumably having returned 0 in rax). See the "<4c>
8b
20" substring in the "Code:" line -- the angle brackets point at
the
first byte of the crashing instruction.

I didn't send the email ultimately because your email included a link
[1] pointing at a particular line number:

https://github.com/mdbooth/libldm/blob/master/src/ldmtool.c#L164

and so I assumed you actually traced the crash to that line.

Is that the case?

Or did you perhaps mistake *PID* 164 (from the kernel log) for the line
number?

> The instruction pointer
> being 563a225cd6a5, I installed libguestfs-tools-dbgsym and tried a:
>
>   addr2line -e /usr/bin/ldmtool 564a892506a5
>
> Results:
>
>   ??:0
>
> Without conviction, I also tried in GDB:
>
>   $ gdb /usr/bin/ldmtool
>   (...)
>   Reading symbols from /usr/bin/ldmtool...
>   Reading symbols from
> /usr/lib/debug/.build-id/21/37b4a64903ebe427c242be08b8d496ba570583.debug...
>   (gdb) info line *0x564a892506a5
>   No line number information available for address 0x564a892506a5
>
> Debug symbols are correctly installed but impossible to convert that
> instruction pointer into a line number. It is as if the ldmtool on my
> host and the ldmtool in the qemu VM were from a different build. I
> tried to mount /tmp/.guestfs-1001/appliance.d/root but that disk image
> did not contain ldmtool.
>
> I am not sure how to generate a stack trace or a core dump within that
> qemu VM. If you can tell me how to get an interactive prompt (or any
> other guidance) I can try to collect more information.

The IP where the crash occurs is 0000563a225cd6a5. The ldmtool binary
(as opposed to a shared object / library) is mapped into the process's
address space at 563a225cb000, for a length of 0x3000 bytes. So the
offending instruction is supposed to be 0000563a225cd6a5 - 563a225cb000
= 26A5.

With the debug symbols installed, can you attach the output of

  objdump --headers --wide -S /usr/bin/ldmtool

?

Can you try

  addr2line -p -i -f -e /usr/bin/ldmtool 26A5

?

(This still may not be good enough; we might have to offset the
difference 0x26A5 with some address related to the .text section... The
objdump output should help us experiment.)

Laszlo