Hey, we found one memory issue about stack-buffer-overflow reported by the address sanitizer. The following is the bug report:
2023-03-28 07:05:04 Jepsen starting /opt/redis/redis-server --protected-mode no --bind 0.0.0.0 --dbfilename redis.rdb --loadmodule /opt/redis/redisraft.so --raft.loglevel debug --raft.log-filename raftlog.db --raft.log-max-file-size 32000 --raft.log-max-cache-size 1000000 --raft.follower-proxy no
=================================================================
==4768==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffffffe510 at pc 0x00000058ab37 bp 0x7fffffffe330 sp 0x7fffffffe328
WRITE of size 4 at 0x7fffffffe510 thread T0
#0 0x58ab36 in main /opt/fs/redis/src/server.c:6806:12
#1 0x7ffff7ad809a in __libc_start_main /build/glibc-6iIyft/glibc-2.28/csu/../csu/libc-start.c:308:16
#2 0x45aa89 in _start (/opt/redis/redis-server+0x45aa89)
Address 0x7fffffffe510 is located in stack of thread T0 at offset 464 in frame
#0 0x58a87f in main /opt/fs/redis/src/server.c:6798
This frame has 5 object(s):
[32, 48) 'tv' (line 6799)
[64, 464) 'x' (line 6805) <== Memory access at offset 464 overflows this variable
[528, 544) 'hashseed' (line 6872)
[560, 564) 'argc_tmp' (line 6941)
[576, 584) 'err_msg' (line 7034)
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 /opt/fs/redis/src/server.c:6806:12 in main
Shadow bytes around the buggy address:
0x10007fff7c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7c60: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2
0x10007fff7c70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7c90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007fff7ca0: 00 00[f2]f2 f2 f2 f2 f2 f2 f2 f8 f8 f2 f2 f8 f2
0x10007fff7cb0: f8 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7cc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7cd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7ce0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x10007fff7cf0: 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
==4768==ABORTING
Comment From: oranagra
@jerrytesting you please mention which redis version is it. from the command line arguments, i understand that's actually with https://github.com/RedisLabs/redisraft, so probably related to something the module does. @tezc FYI
Comment From: tezc
Seems like it throws the warning in main(), even before it loads the module. @jerrytesting please mention redis version.
Comment From: jerrytesting
The redis version that we used is v7.0.4. Yeah, we run redis with the redisraft module.
Comment From: tezc
looks like somehow line numbers don't match, I don't see that object x anywhere.
Comment From: oranagra
Maybe this is a modified version of redis (not the official one)? Where did you get it from? How is it built (compiler / flags)?
Comment From: jerrytesting
Yeah, we have some code annotations and instrumentation, which make the lines mismatch. After the double check, I think this bug may be from our instrumentation. Thanks for your investigation. I will close this issue if so.