I cannot reproduce the problem. It may already have been fixed by patch 9.0.0021

Verified with latest codebase (v9.0.0032). The issue still exsits.

SAN

./vim/src/vim -u NONE -i NONE -n -m -X -Z -e -s -S ./poc_sbo1_s.dat -c :qa!
=================================================================
==17799==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5f460988 at pc 0x56387552d842 bp 0x7fff5f4604e0 sp 0x7fff5f4604d0
WRITE of size 4 at 0x7fff5f460988 thread T0
    #0 0x56387552d841 in spell_dump_compl /home/fuzz/fuzz/vim/vim/src/spell.c:4038
    #1 0x5638752b2157 in ins_compl_dictionaries /home/fuzz/fuzz/vim/vim/src/insexpand.c:1432
    #2 0x5638752b98bc in get_next_dict_tsr_completion /home/fuzz/fuzz/vim/vim/src/insexpand.c:3328
    #3 0x5638752bbc61 in get_next_completion_match /home/fuzz/fuzz/vim/vim/src/insexpand.c:3665
    #4 0x5638752bc1ec in ins_compl_get_exp /home/fuzz/fuzz/vim/vim/src/insexpand.c:3767
    #5 0x5638752bce6e in find_next_completion_match /home/fuzz/fuzz/vim/vim/src/insexpand.c:4002
    #6 0x5638752bd23b in ins_compl_next /home/fuzz/fuzz/vim/vim/src/insexpand.c:4103
    #7 0x5638752c0367 in ins_complete /home/fuzz/fuzz/vim/vim/src/insexpand.c:4954
    #8 0x56387511ae4c in edit /home/fuzz/fuzz/vim/vim/src/edit.c:1281
    #9 0x56387538e67e in invoke_edit /home/fuzz/fuzz/vim/vim/src/normal.c:7037
    #10 0x56387538e4c6 in nv_edit /home/fuzz/fuzz/vim/vim/src/normal.c:7007
    #11 0x563875366b4e in normal_cmd /home/fuzz/fuzz/vim/vim/src/normal.c:939
    #12 0x5638751ebe54 in exec_normal /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:8814
    #13 0x5638751ebc13 in exec_normal_cmd /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:8777
    #14 0x5638751eb4b7 in ex_normal /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:8695
    #15 0x5638751c7e1e in do_one_cmd /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:2570
    #16 0x5638751bf0c1 in do_cmdline /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:992
    #17 0x56387565a779 in call_user_func /home/fuzz/fuzz/vim/vim/src/userfunc.c:2901
    #18 0x56387565b9c7 in call_user_func_check /home/fuzz/fuzz/vim/vim/src/userfunc.c:3058
    #19 0x56387565e27b in call_func /home/fuzz/fuzz/vim/vim/src/userfunc.c:3614
    #20 0x563875654c76 in get_func_tv /home/fuzz/fuzz/vim/vim/src/userfunc.c:1834
    #21 0x56387566a859 in ex_call /home/fuzz/fuzz/vim/vim/src/userfunc.c:5595
    #22 0x5638751c7e1e in do_one_cmd /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:2570
    #23 0x5638751bf0c1 in do_cmdline /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:992
    #24 0x5638754de7b2 in do_source_ext /home/fuzz/fuzz/vim/vim/src/scriptfile.c:1674
    #25 0x5638754df8e4 in do_source /home/fuzz/fuzz/vim/vim/src/scriptfile.c:1801
    #26 0x5638754dc473 in cmd_source /home/fuzz/fuzz/vim/vim/src/scriptfile.c:1174
    #27 0x5638754dc4d8 in ex_source /home/fuzz/fuzz/vim/vim/src/scriptfile.c:1200
    #28 0x5638751c7e1e in do_one_cmd /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:2570
    #29 0x5638751bf0c1 in do_cmdline /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:992
    #30 0x5638751bd45b in do_cmdline_cmd /home/fuzz/fuzz/vim/vim/src/ex_docmd.c:586
    #31 0x5638757b15f2 in exe_commands /home/fuzz/fuzz/vim/vim/src/main.c:3133
    #32 0x5638757aa760 in vim_main2 /home/fuzz/fuzz/vim/vim/src/main.c:780
    #33 0x5638757aa018 in main /home/fuzz/fuzz/vim/vim/src/main.c:432
    #34 0x7fdac81c3082 in __libc_start_main ../csu/libc-start.c:308
    #35 0x563875046e2d in _start (/home/fuzz/fuzz/vim/vim/src/vim+0x139e2d)

Address 0x7fff5f460988 is located in stack of thread T0 at offset 1048 in frame
    #0 0x56387552c998 in spell_dump_compl /home/fuzz/fuzz/vim/vim/src/spell.c:3872

  This frame has 3 object(s):
    [32, 1048) 'arridx' (line 3875) <== Memory access at offset 1048 overflows this variable
    [1184, 2200) 'curi' (line 3876)
    [2336, 2590) 'word' (line 3877)
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /home/fuzz/fuzz/vim/vim/src/spell.c:4038 in spell_dump_compl
Shadow bytes around the buggy address:
  0x10006be840e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006be840f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006be84100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006be84110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006be84120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10006be84130: 00[f2]f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
  0x10006be84140: f2 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006be84150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006be84160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006be84170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006be84180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==17799==ABORTING

Valgrind

valgrind DOES NOT report this issue:

valgrind ./valgrind/src/vim -u NONE -i NONE -n -m -X -Z -e -s -S ./poc_sbo1_s.dat -c :qa!
==17804== Memcheck, a memory error detector
==17804== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==17804== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==17804== Command: ./valgrind/src/vim -u NONE -i NONE -n -m -X -Z -e -s -S ./poc_sbo1_s.dat -c :qa!
==17804== 
==17804== 
==17804== HEAP SUMMARY:
==17804==     in use at exit: 77,614 bytes in 406 blocks
==17804==   total heap usage: 1,889 allocs, 1,483 frees, 1,165,812 bytes allocated
==17804== 
==17804== LEAK SUMMARY:
==17804==    definitely lost: 0 bytes in 0 blocks
==17804==    indirectly lost: 0 bytes in 0 blocks
==17804==      possibly lost: 393 bytes in 8 blocks
==17804==    still reachable: 77,221 bytes in 398 blocks
==17804==         suppressed: 0 bytes in 0 blocks
==17804== Rerun with --leak-check=full to see details of leaked memory
==17804== 
==17804== For lists of detected and suppressed errors, rerun with: -s
==17804== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I see, this doesn't fail with valgrind because the invalid access is in the stack. I can reproduce it with ASAN.

Fixed with patch 9.0.0035