1. 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
  2. 22 Feb, 2021 3 commits
    • Oran Agra's avatar
    • 杨博东'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
    • George Prekas's avatar
      Add check for the MADV_FREE/fork arm64 Linux kernel bug (#8224) · ddf81e2f
      George Prekas authored
      
      
      Older arm64 Linux kernels have a bug that could lead to data corruption during
      background save under the following scenario:
      
      1) jemalloc uses MADV_FREE on a page,
      2) jemalloc reuses and writes the page,
      3) Redis forks the background save process, and
      4) Linux performs page reclamation.
      
      Under these conditions, Linux will reclaim the page wrongfully and the
      background save process will read zeros when it tries to read the page.
      
      The bug has been fixed in Linux with commit:
      ff1712f953e27f0b0718762ec17d0adb15c9fd0b ("arm64: pgtable: Ensure dirty bit is
      preserved across pte_wrprotect()")
      
      This Commit adds an ignore-warnings config, when not found, redis will
      print a warning and exit on startup (default behavior).
      Co-authored-by: default avatarOran Agra <oran@redislabs.com>
      (cherry picked from commit b02780c4)
      ddf81e2f
  3. 27 Oct, 2020 1 commit
    • 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
  4. 23 Apr, 2020 1 commit
    • srzhao's avatar
      Check OOM at script start to get stable lua OOM state. · 0efb93d0
      srzhao authored
      Checking OOM by `getMaxMemoryState` inside script might get different result
      with `freeMemoryIfNeededAndSafe` at script start, because lua stack and
      arguments also consume memory.
      
      This leads to memory `borderline` when memory grows near server.maxmemory:
      
      - `freeMemoryIfNeededAndSafe` at script start detects no OOM, no memory freed
      - `getMaxMemoryState` inside script detects OOM, script aborted
      
      We solve this 'borderline' issue by saving OOM state at script start to get
      stable lua OOM state.
      
      related to issue #6565 and #5250.
      0efb93d0
  5. 19 Nov, 2019 2 commits
  6. 14 Nov, 2019 1 commit
  7. 06 Nov, 2019 3 commits
    • antirez's avatar
      Update PR #6537: use a fresh time outside call(). · d3f4dec4
      antirez authored
      One problem with the solution proposed so far in #6537 is that key
      lookups outside a command execution via call(), still used a cached
      time. The cached time needed to be refreshed in multiple places,
      especially because of modules callbacks from timers, cluster bus, and
      thread safe contexts, that may use RM_Open().
      
      In order to avoid this problem, this commit introduces the ability to
      detect if we are inside call(): this way we can use the reference fixed
      time only when we are in the context of a command execution or Lua
      script, but for the asynchronous lookups, we can still use mstime() to
      get a fresh time reference.
      d3f4dec4
    • antirez's avatar
      Update PR #6537 patch to for generality. · 33f42665
      antirez authored
      After the thread in #6537 and thanks to the suggestions received, this
      commit updates the original patch in order to:
      
      1. Solve the problem of updating the time in multiple places by updating
      it in call().
      2. Avoid introducing a new field but use our cached time.
      
      This required some minor refactoring to the function updating the time,
      and the introduction of a new cached time in microseconds in order to
      use less gettimeofday() calls.
      33f42665
    • zhaozhao.zz's avatar
      expires: refactoring judgment about whether a key is expired · 68d71d83
      zhaozhao.zz authored
      Calling lookupKey*() many times to search a key in one command
      may get different result.
      
      That's because lookupKey*() calls expireIfNeeded(), and delete
      the key when reach the expire time. So we can get an robj before
      the expire time, but a NULL after the expire time.
      
      The worst is that may lead to Redis crash, for example
      `RPOPLPUSH foo foo` the first time we get a list form `foo` and
      hold the pointer, but when we get `foo` again it's expired and
      deleted. Now we hold a freed memory, when execute rpoplpushHandlePush()
      redis crash.
      
      To fix it, we can refactor the judgment about whether a key is expired,
      using the same basetime `server.cmd_start_mstime` instead of calling
      mstime() everytime.
      68d71d83
  8. 25 Sep, 2019 1 commit
  9. 05 Sep, 2019 1 commit
  10. 13 May, 2019 2 commits
  11. 10 May, 2019 1 commit
  12. 10 Apr, 2019 1 commit
  13. 14 Mar, 2019 4 commits
  14. 12 Dec, 2018 1 commit
  15. 11 Dec, 2018 2 commits
  16. 17 Oct, 2018 2 commits
  17. 15 Oct, 2018 1 commit
  18. 09 Oct, 2018 1 commit
  19. 03 Oct, 2018 1 commit
  20. 14 Sep, 2018 2 commits
  21. 04 Sep, 2018 2 commits
  22. 29 Aug, 2018 3 commits
  23. 02 Aug, 2018 2 commits
  24. 30 Jul, 2018 1 commit