status-im/nimbus-eth2

[Crash/Fuzzing] segmentation fault during state transition (process_final_updates)

pventuzelo opened this issue · 2 comments

During fuzzing, I triggered a segmentation fault in state transition processing. Based on gdb, issue come from process_final_updates.

https://github.com/status-im/nim-beacon-chain/blob/96431bfd861be168ecc4cefb14fdb77d28108a24/beacon_chain/spec/state_transition_epoch.nim#L376-L380

Reproducing

branch: devel
commit: 65ca74c

Download:
segfault_transition_process_final.zip

$ make
$ cd ncli
$ ../env.sh nim c -d:const_preset=mainnet ncli_transition
$ ./ncli_transition --pre= segfault_transition_process_final_beacon_nimbus_devel.ssz --blck= segfault_transition_process_final_block_nimbus_devel.ssz  --post= segfault_transition_process_final_beacon_nimbus_devel.ssz
[1]    29114 segmentation fault  ./ncli_transition --pre= beacon-pre.ssz --blck= block-crash.ssz --post= beacon-pre.ssz

GDB

$ gdb --args ./ncli_transition --pre= segfault_transition_process_final_beacon_nimbus_devel.ssz --blck= segfault_transition_process_final_block_nimbus_devel.ssz  --post= segfault_transition_process_final_beacon_nimbus_devel.ssz

[...]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
process_final_updates__lKFDgP7VBTZCZIy9a9b589cTw_3 (state=state@entry=0x7fffffd6d580)
    at XXX/nim-beacon-chain/beacon_chain/spec/state_transition_epoch.nim:379
379	func process_final_updates*(state: var BeaconState) {.nbench.}=
(gdb) bt
#0  process_final_updates__lKFDgP7VBTZCZIy9a9b589cTw_3 (state=state@entry=0x7fffffd6d580)
    at XXX/nim-beacon-chain/beacon_chain/spec/state_transition_epoch.nim:379
#1  0x00005555556a2151 in process_epoch__lKFDgP7VBTZCZIy9a9b589cTw (state=state@entry=0x7fffffd6d580)
    at XXX/nim-beacon-chain/beacon_chain/spec/state_transition_epoch.nim:451
#2  0x00005555556a5f31 in process_slots__qihLKyAUoREyhTUi9b9cAKJQ (state=state@entry=0x7fffffd6d580, 
    slot=<optimized out>)
    at XXX/nim-beacon-chain/beacon_chain/state_transition.nim:249
#3  0x00005555556aca9f in state_transition__o10Cn5E9cwiqw303qyIywww (state=0x7fffffd6d580, 
    signedBlock=0x7fffffadcfe0, flags=<optimized out>)
    at XXX/nim-beacon-chain/beacon_chain/state_transition.nim:263
#4  0x00005555556ad1bf in CLI__pSFxEjrp6Wmf3rE51bmZ9cg (pre=0x7ffff7f54678, blck=0x7ffff7f57438, 
    post=0x7ffff7f54938, verifyStateRoot=<optimized out>)
    at XXX/nim-beacon-chain/ncli/ncli_transition.nim:13
#5  0x00005555556aec33 in NimMainModule ()
    at XXX/nim-beacon-chain/vendor/nim-confutils/confutils.nim:981
#6  NimMainInner ()
    at XXX/nim-beacon-chain/vendor/nim-serialization/serialization/errors.nim:83
#7  0x00005555556b09c2 in NimMain ()
    at XXX/nim-beacon-chain/vendor/nim-serialization/serialization/errors.nim:91
#8  0x000055555555677d in main (argc=<optimized out>, args=<optimized out>, env=<optimized out>)
    at XXX/nim-beacon-chain/vendor/nim-serialization/serialization/errors.nim:98

Separately from the PR linked, this test case also drives the state_transition(...) machinery from slot 0 to slot 65537, which simply takes a while, but that's functioning as designed as far as I can tell.