mirror of
https://github.com/hugsy/gef.git
synced 2026-10-11 21:49:56 +00:00
NaveenkumarandNK
49c07dc606
Fixes #1225 ## Problem glibc 2.43 removed the fastbin infrastructure (upstream commit `bb5a4f5`), so `struct malloc_state` no longer contains `fastbinsY[NFASTBINS]` nor `have_fastchunks`. GEF's `GlibcArena.malloc_state_t()` was still parsing the old layout, so on glibc >= 2.43 every heap command reading the arena showed garbage (`heap arenas` with wrong `top`/`last_remainder`, broken `heap bins`, ...). ## Fix Made the arena layout version-aware: - `GlibcArena.has_fastbins()`: fastbins exist only on glibc < 2.43 - `GlibcArena.malloc_state_t()`: no longer defines `fastbinsY` / `have_fastchunks` on glibc >= 2.43 - `GlibcArena.fastbinsY` returns an empty array, `fastbin()` returns `None`, so existing callers behave safely - `heap bins fast` exits with a clear message instead of parsing corrupted data ## Tests Added `HeapCommandNoFastbins` (tests/commands/heap.py): it forces `gef.libc._version = (2, 43)` regardless of the host glibc and verifies the 2.43 arena layout has no fastbins and `heap bins fast` reports them as unsupported. The initial CI run failed on `fedora-rawhide` (glibc 2.44) for two reasons, both fixed in the follow-up commit: - `HeapCommandFastBins::test_cmd_heap_bins_fast` was missing the `skipif(is_glibc_ge(2, 43))` marker that all the other fastbin tests use, and failed on a real no-fastbins glibc - `CanaryCommand::test_cmd_canary` asserted that the stack canary equals the `AT_RANDOM`-derived value; on glibc >= 2.44 the canary is no longer derived from `AT_RANDOM`, so the test is skipped there (the `canary` command itself still reads the right value from the TLS slot) Verified locally against glibc 2.41 (Debian), 2.43 (fedora:44) and 2.44 (fedora:rawhide) containers, plus `pre-commit run --all-files`. --------- Co-authored-by: NK <[email protected]>