Hey, amazing work on the VSet HNSW duplicate-ID RCE. The primitive chain (RESTORE → VREM → VLINKS → ModuleType corruption) is brilliant.
We're trying to make it build-independent. The only blocker is LUA_TO_OLD_B and LUA_TO_C0 — the heap distances from the leaked table to the Lua type objects change per compilation. We've got the read oracle, write primitive, and RCE trigger all working locally on our own libc build, but can't pass the VLINKS self-test without the right offsets
Would you be willing to share either:
- The exact redis-server binary from the successful PoC run (build c8d40b9af9f5dac8), or
- Which Lua type objects LUA_TO_OLD_B and LUA_TO_C0 actually point to? Are they global_State->mt[] entries, interned strings, or specific TValues allocated during EVAL?
Knowing WHAT they are would let us walk the Lua GC chain to find them in any build.
Thanks for publishing this — the writeup quality is exceptional.
Kind Regards
Hey, amazing work on the VSet HNSW duplicate-ID RCE. The primitive chain (RESTORE → VREM → VLINKS → ModuleType corruption) is brilliant.
We're trying to make it build-independent. The only blocker is LUA_TO_OLD_B and LUA_TO_C0 — the heap distances from the leaked table to the Lua type objects change per compilation. We've got the read oracle, write primitive, and RCE trigger all working locally on our own libc build, but can't pass the VLINKS self-test without the right offsets
Would you be willing to share either:
Knowing WHAT they are would let us walk the Lua GC chain to find them in any build.
Thanks for publishing this — the writeup quality is exceptional.
Kind Regards