• Huang Zhw's avatar
    On 32 bit platform, the bit position of GETBIT/SETBIT/BITFIELD/BITCOUNT,BITPOS... · 449af2cd
    Huang Zhw authored
    On 32 bit platform, the bit position of GETBIT/SETBIT/BITFIELD/BITCOUNT,BITPOS may overflow (see CVE-2021-32761) (#9191)
    
    GETBIT, SETBIT may access wrong address because of wrap.
    BITCOUNT and BITPOS may return wrapped results.
    BITFIELD may access the wrong address but also allocate insufficient memory and segfault (see CVE-2021-32761).
    
    This commit uses `uint64_t` or `long long` instead of `size_t`.
    related https://github.com/redis/redis/pull/8096
    
    At 32bit platform:
    > setbit bit 4294967295 1
    (integer) 0
    > config set proto-max-bulk-len 536870913
    OK
    > append bit "\xFF"
    (integer) 536870913
    > getbit bit 4294967296
    (integer) 0
    
    When the bit index is larger than 4294967295, size_t can't hold bit index. In the past,  `proto-max-bulk-len` is limit to 536870912, so there is no problem.
    
    After this commit, bit position is stored in `uint64_t` or `long long`. So when `proto-max-bulk-len > 536870912`, 32bit platforms can still be correct.
    
    For 64bit platform, this problem still exists. The major reason is bit pos 8 times of byte pos. When proto-max-bulk-len is very larger, bit pos may overflow.
    But at 64bit platform, we don't have so long string. So this bug may never happen.
    
    Additionally this commit add a test cost `512MB` memory which is tag as `large-memory`. Make freebsd ci and valgrind ci ignore this test.
    * This test is disabled in this version since bitops doesn't rely on
    proto-max-bulk-len. some of the overflows can still occur so we do want
    the fixes.
    
    (cherry picked from commit 71d45287)
    (cherry picked from commit 2be8f1de1d452886fbf45030409707c52323da20)
    449af2cd
server.h 97.1 KB