News › linux
By The Linux Camp News, October 11, 2026
The October 10 release isolates a privileged Python helper, limits recursive processing and expands dump compatibility. Scripts using module address ranges may need changes.
Drgn 0.3.0 was released on October 10, 2026, with hardening against untrusted debugging information and core dumps, conditional direct-memory access for QEMU guest debugging, and compatibility fixes. The open-source debugger from Meta emphasizes programmable debugging: engineers can use scripts rather than relying only on interactive commands. 2 1
The maintainer reports fixes for memory-safety defects, undefined behavior and leaks. The distinction for operators is how those defects are reached: some accept crafted inputs as triggers, while others require pathological user code. That makes input provenance relevant when assessing the hardening, without implying that every ordinary debugging session encounters these bugs. 2
One fix changes the CLI helper that opens /proc/kcore through sudo: it runs Python in isolated mode so other modules cannot shadow, or substitute for, standard-library modules. This protection concerns that privileged helper, not every Python execution path. Separately, drgn limits excessive recursion when deeply nested or cyclic types or namespaces would otherwise drive repeated processing. 2 3
For QEMU guests, the optimization is direct reading of memory from the QEMU process when possible. The release notes retrieved October 11 describe neither the eligibility conditions nor a measured speedup. Engineers should therefore treat this as a conditional optimization, not a performance guarantee for every guest-debugging setup. 2
Compatibility gains include s390x and ppc64 dumps without virtual memory segments. Kernel-facing changes also track internal interfaces: Linux 7.2 support handles the renamed nr_irqs global, while Linux 7.3 support adjusts filesystem lookup for changes to the initial mount namespace's root filesystem. These are debugger adaptations to the structures it inspects. 2 3
Before adopting 0.3.0 in scripted workflows, review code that assumes each loaded userspace module occupies one address range. Ranges are now page-aligned, and noncontiguous segments produce multiple ranges. The maintainer specifically warns that scripts may need drgn.Module.address_ranges instead of drgn.Module.address_range; this is a concrete migration check rather than a reason to rewrite every script. 2