1. 04 Oct, 2021 1 commit
    • Oran Agra's avatar
      Prevent unauthenticated client from easily consuming lots of memory (CVE-2021-32675) · 71be9729
      Oran Agra authored
      This change sets a low limit for multibulk and bulk length in the
      protocol for unauthenticated connections, so that they can't easily
      cause redis to allocate massive amounts of memory by sending just a few
      characters on the network.
      The new limits are 10 arguments of 16kb each (instead of 1m of 512mb)
      
      (cherry picked from commit 3d221e81f3b680543e34942579af190b049ff283)
      71be9729
  2. 21 Jul, 2021 1 commit
    • 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
  3. 22 Feb, 2021 1 commit
    • 杨博东's avatar
      Fix flock cluster config may cause failure to restart after kill -9 (#7674) · e4ab38a3
      杨博东 authored
      
      
      After fork, the child process(redis-aof-rewrite) will get the fd opened
      by the parent process(redis), when redis killed by kill -9, it will not
      graceful exit(call prepareForShutdown()), so redis-aof-rewrite thread may still
      alive, the fd(lock) will still be held by redis-aof-rewrite thread, and
      redis restart will fail to get lock, means fail to start.
      
      This issue was causing failures in the cluster tests in github actions.
      Co-authored-by: default avatarOran Agra <oran@redislabs.com>
      (cherry picked from commit cbaf3c5b)
      e4ab38a3
  4. 27 Oct, 2020 2 commits
    • Oran Agra's avatar
      Allow blocked XREAD on a cluster replica (#7881) · 89c68ba3
      Oran Agra authored
      I suppose that it was overlooked, since till recently none of the blocked commands were readonly.
      
      other changes:
      - add test for the above.
      - add better support for additional (and deferring) clients for
        cluster tests
      - improve a test which left the client in MULTI state.
      
      (cherry picked from commit 216c1106)
      89c68ba3
    • Oran Agra's avatar
      RESTORE ABSTTL won't store expired keys into the db (#7472) · e9c9e4c2
      Oran Agra authored
      Similarly to EXPIREAT with TTL in the past, which implicitly deletes the
      key and return success, RESTORE should not store key that are already
      expired into the db.
      When used together with REPLACE it should emit a DEL to keyspace
      notification and replication stream.
      
      (cherry picked from commit 5977a948)
      (cherry picked from commit 95ba01b5)
      e9c9e4c2
  5. 05 Mar, 2020 2 commits
    • Guy Benoish's avatar
      Blocking XREAD[GROUP] should always reply with valid data (or timeout) · 7f3fcedb
      Guy Benoish authored
      This commit solves the following bug:
      127.0.0.1:6379> XGROUP CREATE x grp $ MKSTREAM
      OK
      127.0.0.1:6379> XADD x 666 f v
      "666-0"
      127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x >
      1) 1) "x"
         2) 1) 1) "666-0"
               2) 1) "f"
                  2) "v"
      127.0.0.1:6379> XADD x 667 f v
      "667-0"
      127.0.0.1:6379> XDEL x 667
      (integer) 1
      127.0.0.1:6379> XREADGROUP GROUP grp Alice BLOCK 0 STREAMS x >
      1) 1) "x"
         2) (empty array)
      
      The root cause is that we use s->last_id in streamCompareID
      while we should use the last *valid* ID
      7f3fcedb
    • Guy Benoish's avatar
      Stream: Handle streamID-related edge cases · 89682d96
      Guy Benoish authored
      This commit solves several edge cases that are related to
      exhausting the streamID limits: We should correctly calculate
      the succeeding streamID instead of blindly incrementing 'seq'
      This affects both XREAD and XADD.
      
      Other (unrelated) changes:
      Reply with a better error message when trying to add an entry
      to a stream that has exhausted last_id
      89682d96
  6. 19 Nov, 2019 4 commits
  7. 05 Sep, 2019 1 commit
  8. 14 May, 2019 1 commit
    • antirez's avatar
      Test: fix slowlog test false positive. · 7ac7ffd5
      antirez authored
      In fast systems "SLOWLOG RESET" is fast enough to don't be logged even
      when the time limit is "1" sometimes. Leading to false positives such
      as:
      
      [err]: SLOWLOG - can be disabled in tests/unit/slowlog.tcl
      Expected '1' to be equal to '0'
      7ac7ffd5
  9. 13 May, 2019 9 commits
  10. 18 Mar, 2019 2 commits
  11. 13 Mar, 2019 2 commits
  12. 21 Dec, 2018 1 commit
  13. 11 Dec, 2018 3 commits
  14. 20 Nov, 2018 2 commits
  15. 17 Oct, 2018 5 commits
  16. 15 Oct, 2018 3 commits