I wrote this post. As I mention in it, I’ve been using GDB almost daily for about 10 years, but I had never actually looked at its source code. I finally started digging into it to make sense of some quirky behaviors, and I ended up uncovering some fascinating details.
You can understand how things work in theory, but it’s always fascinating to see the challenges that crop up when implementing them in practice. I knew a mature debugger like GDB would be complex, but I didn't expect these specific issues and their solutions.
Confira nos links abaixo as discussões e contribuições públicas que nasceram dessa turma:
Mitigating __pointer_chk_guard_local exposure and pointer mangling in ld.so
sourceware.org/pipermail/li...
E você, vai ficar de fora? Podemos fazer história novamente em nosso próximo treinamento de Exploração de Vulnerabilidades no Kernel do Linux.
We started analyzing a classic case where GDB creates the illusion that code in writable memory is corrupted. We ended up discovering two interesting behaviors of GDB.
vtop returns stale page table entries due to FILL_PUD caching logic
lists.crash-utility.osci.io/archives/lis...
I really enjoyed learning these nuances and writing about them, especially since this deep dive wasn't originally planned!
CVE-2026-45257: FreeBSD kTLS-RX in-place AES-GCM decrypt over sendfile(2) EXTPG mbufs to page-cache write / local root
seclists.org/oss-sec/2026...
[PATCH] target/i386: helper_sysret(): Check that RCX contains a canonical address when emulating an Intel CPU
lore.kernel.org/qemu-devel/2...
Did you know there's a way to hit a breakpoint without using hardware or software breakpoints? Or how GDB patches the binary to execute an instruction?
Learn more about how GDB works under the hood.
Why is my shellcode being corrupted?
allelesecurity.com/why-is-my-sh...
