Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Missing update of local /proc/{pid}/maps in remote session when new shared library is loaded #1057

Open
9 tasks
MrNbaYoh opened this issue Jan 25, 2024 · 5 comments

Comments

@MrNbaYoh
Copy link

GEF+GDB version

GDB: 13.2
GDB-Python: 3.11

Operating System

Manjaro Linux

Describe the issue you encountered

When a program in a remote session loads additional shared library after it started, the remote_objfile_event_handler:

gef/gef.py

Lines 11246 to 11258 in 570cc03

def remote_objfile_event_handler(self, evt: "gdb.events.NewObjFileEvent") -> None:
dbg(f"[remote] in remote_objfile_handler({evt.new_objfile.filename if evt else 'None'}))")
if not evt or not evt.new_objfile.filename:
return
if not evt.new_objfile.filename.startswith("target:") and not evt.new_objfile.filename.startswith("/"):
warn(f"[remote] skipping '{evt.new_objfile.filename}'")
return
if evt.new_objfile.filename.startswith("target:"):
src: str = evt.new_objfile.filename[len("target:"):]
if not self.sync(src):
raise FileNotFoundError(f"Failed to sync '{src}'")
return

downloads the shared library from the remote and store it in the local folder.
However, it does not update the local /proc/{pid}/maps file, leading to wrong vmmap outputs (and maybe other erroneous results).

Do you read the docs and look at previously closed issues/PRs for similar cases?

Yes

Architecture impacted

  • X86
  • X64
  • ARM
  • ARM64
  • MIPS
  • MIPS64
  • PPC
  • PPC64
  • RISCV

Describe your issue. Without a proper reproduction step-by-step, your issue will be ignored.

  1. Start a remote debugging session on a program that loads additional shared libraries with dlopen for example.
  2. Run the program and tries vmmap, the additional shared library won't show in the output.

Minimalist test case

No response

Additional context?

No response

@hugsy
Copy link
Owner

hugsy commented Jan 26, 2024

Which gef version are you using?

I cannot reproduce: it works well with this

cat meh.c << EOF
#include <stdio.h>
#include <dlfcn.h>
int main()
{
        __asm__("int3");
        void** handle = dlopen("/usr/local/lib/libkeystone.so.0", RTLD_NOW);
        printf("handle = %p -> %p\n", handle, *handle);
        __asm__("int3");
        dlclose(handle);
        __asm__("int3");
        return 0;
}
EOF

and

make meh
gdbserver localhost:1234 ./meh

on start, no libkeystone
image

but on the 2nd int3 libkeystone shows
image

If you think there is a bug, provide a detail step-by-step.

@pnck
Copy link

pnck commented Feb 4, 2024

@hugsy Hi, I might encounter a similar problem, but I'm not sure whether it is a bug. Have you tried printing the vmmap for a remote process attached by gdbserver? I'm wondering if gef updates the mapping when the remote target is loading new libs.

@hugsy
Copy link
Owner

hugsy commented Feb 4, 2024

@pnck See the comment above. It works well. Provide a step-by-step to reproduce reliably from the main version if you think there's a bug. Otherwise I'll close the issue.

@pnck
Copy link

pnck commented Feb 5, 2024

@hugsy Sorry I didn't read carefully.

I tried a couple of versions and see it seems fixed on the main branch.

I can reproduce with docker on the 2024.01 tagged version, which is likely the version I downloaded. (I remember I manually downloaded it from somewhere, probably the release page.)

reproduce on the older version:

  • docker run --rm -it --privileged -p1234:1234 --name tmp ubuntu:22.04
  • (inside docker) apt update && apt install build-essential gdbserver
  • build a minimal program: printf '#include<stdio.h>\nmain(){return 0;}' | gcc -xc -
  • attach: gdbserver :1234 a.out
  • connect the gdbserver from outside docker
  • tb main; c
  • vmmap doesn't show libc

@hugsy
Copy link
Owner

hugsy commented Feb 5, 2024

Thanks @pnck that's much more useful!
I can reproduce the bug now on 2024.01, and I'm fairly sure this bug was killed with many others in #1046 Since I can reproduce it, I'll be adding some non-regression tests so we're able to catch those in the future.

Since it's fixed in main and already many more bugs were fixed in there too, we will probably create another release very soon, including those changes. So for now please keep using main.

Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants