1. 10 Jul, 2023 3 commits
  2. 17 Apr, 2023 4 commits
  3. 28 Feb, 2023 5 commits
  4. 17 Jan, 2023 14 commits
    • Oran Agra's avatar
      Redis 6.0.17 · 6ed4dc50
      Oran Agra authored
      6ed4dc50
    • Mikhail Fesenko's avatar
      fflush stdout after responses partial backport from (#9136) · cbcdebe3
      Mikhail Fesenko authored
      
      
      2. Make redis-cli flush stdout when printing a reply
        This was needed in order to fix a hung in redis-cli test that uses
        --replica.
         Note that printf does flush when there's a newline, but fwrite does not.
      
      3. fix the redis-cli --replica test which used to pass previously
         because it didn't really care what it read, and because redis-cli
         used printf to print these other things to stdout.
      
      4. improve redis-cli --replica test to run with both diskless and disk-based.
      Co-authored-by: default avatarOran Agra <oran@redislabs.com>
      Co-authored-by: default avatarViktor Söderqvist <viktor@zuiderkwast.se>
      (cherry picked from commit 1eb4baa5)
      (cherry picked from commit 88849712)
      cbcdebe3
    • Yossi Gottlieb's avatar
      Fix TLS tests on newer tcl-tls/OpenSSL. (#10910) · 196d06b9
      Yossi Gottlieb authored
      Before this commit, TLS tests on Ubuntu 22.04 would fail as dropped
      connections result with an ECONNABORTED error thrown instead of an empty
      read.
      
      (cherry picked from commit 69d55768)
      196d06b9
    • Ozan Tezcan's avatar
      Some fixes to undefined behaviour bugs taken from (#9601) · cb6beec2
      Ozan Tezcan authored
      **Signed integer overflow.** Although, signed overflow issue can be problematic time to time
      and change how compiler generates code, current findings mostly about signed shift or simple
      addition overflow. For most platforms Redis can be compiled for, this wouldn't cause any issue
      as far as I can tell (checked generated code on godbolt.org).
      
      UB means nothing guaranteed and risky to reason about program behavior but I don't think any
      of the fixes here worth backporting. As sanitizers are now part of the CI, preventing new issues
      will be the real benefit.
      
      partial cherry pick from commit b91d8b28
      The bug in BITFIELD seems to affect 12.2.1 used on Alpine
      
      (cherry picked from commit 4418cf166e025e7d0d2c965e75ad57c05ecff43f)
      cb6beec2
    • Yossi Gottlieb's avatar
      Fix test modules build issue on OS X 11. (#9658) · 542ccdc9
      Yossi Gottlieb authored
      (cherry picked from commit 8bf4c2e3)
      (cherry picked from commit 30533370)
      542ccdc9
    • Oran Agra's avatar
      Avoid integer overflows in SETRANGE and SORT (CVE-2022-35977) · c6bbfec2
      Oran Agra authored
      Authenticated users issuing specially crafted SETRANGE and SORT(_RO)
      commands can trigger an integer overflow, resulting with Redis attempting
      to allocate impossible amounts of memory and abort with an OOM panic.
      c6bbfec2
    • Oran Agra's avatar
      Obuf limit, exit during loop in *RAND* commands · 4779ed5e
      Oran Agra authored
      Related to the hang reported in #11671
      Currently, redis can disconnect a client due to reaching output buffer limit,
      it'll also avoid feeding that output buffer with more data, but it will keep
      running the loop in the command (despite the client already being marked for
      disconnection)
      
      This PR is an attempt to mitigate the problem, specifically for commands that
      are easy to abuse, specifically: SRANDMEMBER.
      The RAND family of commands can take a negative COUNT argument (which is not
      bound to the number of elements in the key), so it's enough to create a key
      with one field, and then these commands can be used to hang redis.
      
      NOTICE:
      For in Redis 7.0 this fix handles KEYS as well, but in this branch
      it doesn't, details in #11676
      4779ed5e
    • Oran Agra's avatar
      crash report instructions (#10816) · 2fc6a24f
      Oran Agra authored
      Trying to avoid people opening crash report issues about module crashes and ARM QEMU bugs.
      
      (cherry picked from commit 475563e2)
      (cherry picked from commit 66472a5e)
      2fc6a24f
    • Meir Shpilraien (Spielrein)'s avatar
      Remove dead code on sorting reply on Lua scripts. (#10701) · dad7f71f
      Meir Shpilraien (Spielrein) authored
      On v6.2.7 a new mechanism was added to Lua scripts that allows
      filtering the globals of the Lua interpreter. This mechanism was
      added on the following commit: https://github.com/redis/redis/commit/11b602fbf8f9cdf8fc741c24625ab6287ab998a9
      
      One of the globals that was filtered out was `__redis__compare_helper`. This global
      was missed and was not added to the allow list or to the deny list. This is
      why we get the following warning when Redis starts:
      `A key '__redis__compare_helper' was added to Lua globals which is not on the globals allow list nor listed on the deny list.`
      
      After investigating the git blame log, the conclusion is that `__redis__compare_helper`
      is no longer needed, the PR deletes this function, and fixes the warning.
      
      Detailed Explanation:
      
      `__redis__compare_helper` was added on this commit: https://github.com/redis/redis/commit/2c861050c1
      Its purpose is to sort the replies of `SORT` command when script replication is enable and keep the replies
      deterministic and avoid primary and replica synchronization issues. On `SORT` command, there was a need for
      special compare function that are able to compare boolean values.
      
      The need to sort the `SORT` command reply was removed on this commit: https://github.com/redis/redis/commit/36741b2c818a95e8ef167818271614ee6b1bc414
      The sorting was moved to be part of the `SORT` command and there was not longer a need
      to sort it on the Lua interpreter. The commit made `__redis__compare_helper` a dead code but did
      not deleted it.
      
      (cherry picked from commit 64c657a8)
      dad7f71f
    • Oran Agra's avatar
      Bring some CI adjustments from 7.0 into 6.0 · 5e841b55
      Oran Agra authored
      5e841b55
    • Oran Agra's avatar
      Attempt to fix a rare crash in cluster tests. (#10265) · 04ca7d8a
      Oran Agra authored
      The theory is that a replica gets disconnected from within REPLCONF ACK,
      so when we go up the stack, we'll crash when attempting to access
      c->cmd->flags
      
      (cherry picked from commit aa9beaca)
      04ca7d8a
    • Oran Agra's avatar
      crash log, print killer pid only when si_code is SI_USER (#10454) · 280e6a89
      Oran Agra authored
      Avoid printing "Killed by PID" when si_code != SI_USER.
      Apparently SI_USER isn't always set to 0. e.g. on Mac it's 0x10001 and the check that did <= was wrong.
      
      (cherry picked from commit 6761d10c)
      280e6a89
    • Meir Shpilraien (Spielrein)'s avatar
      Clean Lua stack before parsing call reply to avoid crash on a call with many arguments (#9809) · a511af7c
      Meir Shpilraien (Spielrein) authored
      This commit 0f8b634c (CVE-2021-32626 released in 6.2.6, 6.0.16, 5.0.14)
      fixes an invalid memory write issue by using `lua_checkstack` API to make
      sure the Lua stack is not overflow. This fix was added on 3 places:
      1. `luaReplyToRedisReply`
      2. `ldbRedis`
      3. `redisProtocolToLuaType`
      
      On the first 2 functions, `lua_checkstack` is handled gracefully while the
      last is handled with an assert and a statement that this situation can
      not happened (only with misbehave module):
      
      > the Redis reply might be deep enough to explode the LUA stack (notice
      that currently there is no such command in Redis that returns such a nested
      reply, but modules might do it)
      
      The issue that was discovered is that user arguments is also considered part
      of the stack, and so the following script (for example) make the assertion reachable:
      ```
      local a = {}
      for i=1,7999 do
          a[i] = 1
      end
      return redis.call("lpush", "l", unpack(a))
      ```
      
      This is a regression because such a script would have worked before and now
      its crashing Redis. The solution is to clear the function arguments from the Lua
      stack which makes the original assumption true and the assertion unreachable.
      
      (cherry picked from commit 6b0b04f1)
      a511af7c
    • Vo Trong Phuc's avatar
      add check good slaves to write when execute script (#10249) · 2adbbbcd
      Vo Trong Phuc authored
      
      
      There was no check min-slave-* config when evaluating Lua script.
      Add check enough good slaves for write command when evaluating scripts.
      Co-authored-by: default avatarPhuc. Vo Trong <phucvt@vng.com.vn>
      (cherry picked from commit 34505d26)
      2adbbbcd
  5. 04 Oct, 2021 13 commits
    • Oran Agra's avatar
      Redis 6.0.16 · 5895d119
      Oran Agra authored
      5895d119
    • sundb's avatar
      Fix the timing of read and write events under kqueue (#9416) · aabe9512
      sundb authored
      Normally we execute the read event first and then the write event.
      When the barrier is set, we will do it reverse.
      However, under `kqueue`, if an `fd` has both read and write events,
      reading the event using `kevent` will generate two events, which will
      result in uncontrolled read and write timing.
      
      This also means that the guarantees of AOF `appendfsync` = `always` are
      not met on MacOS without this fix.
      
      The main change to this pr is to cache the events already obtained when reading
      them, so that if the same `fd` occurs again, only the mask in the cache is updated,
      rather than a new event is generated.
      
      This was exposed by the following test failure on MacOS:
      ```
      *** [err]: AOF fsync always barrier issue in tests/integration/aof.tcl
      Expected 544 != 544 (context: type eval line 26 cmd {assert {$size1 != $size2}} proc ::test)
      ```
      
      (cherry picked from commit 306a5ccd)
      aabe9512
    • Wang Yuan's avatar
      Fix the wrong detection of sync_file_range system call (#9371) · 03cb27e8
      Wang Yuan authored
      If we want to check `defined(SYNC_FILE_RANGE_WAIT_BEFORE)`, we should include fcntl.h.
      otherwise, SYNC_FILE_RANGE_WAIT_BEFORE is not defined, and there is alway not `sync_file_range` system call.
      Introduced by #8532
      
      (cherry picked from commit 8edc3cd6)
      03cb27e8
    • Ewg-c's avatar
      Minor refactoring for rioConnRead and adding errno (#9280) · dde1c975
      Ewg-c authored
      minor refactoring for rioConnRead and adding errno
      
      (cherry picked from commit a4038164)
      dde1c975
    • zhaozhao.zz's avatar
      more strict check in rioConnRead (#7564) · 5a82df05
      zhaozhao.zz authored
      
      (cherry picked from commit da840e98)
      5a82df05
    • Oran Agra's avatar
      Fix harmless bug in rioConnRead (#7557) · 12a6b438
      Oran Agra authored
      this code is in use only if the master is disk-based, and the replica is
      diskless. In this case we use a buffered reader, but we must avoid reading
      past the rdb file, into the command stream. which Luckly rdb.c doesn't
      really attempt to do (it knows how much it should read).
      
      When rioConnRead detects that the extra buffering attempt reaches beyond
      the read limit it should read less, but if the caller actually requested
      more, then it should return with an error rather than a short read. the
      bug would have resulted in short read.
      
      in order to fix it, the code must consider the real requested size, and
      not the extra buffering size.
      
      (cherry picked from commit 40d7fca3)
      12a6b438
    • YiyuanGUO's avatar
      c6ad8767
    • Oran Agra's avatar
      Fix ziplist and listpack overflows and truncations (CVE-2021-32627, CVE-2021-32628) · f6a40570
      Oran Agra authored
      - fix possible heap corruption in ziplist and listpack resulting by trying to
        allocate more than the maximum size of 4GB.
      - prevent ziplist (hash and zset) from reaching size of above 1GB, will be
        converted to HT encoding, that's not a useful size.
      - prevent listpack (stream) from reaching size of above 1GB.
      - XADD will start a new listpack if the new record may cause the previous
        listpack to grow over 1GB.
      - XADD will respond with an error if a single stream record is over 1GB
      - List type (ziplist in quicklist) was truncating strings that were over 4GB,
        now it'll respond with an error.
      f6a40570
    • meir@redislabs.com's avatar
      Fix invalid memory write on lua stack overflow {CVE-2021-32626} · 666ed7fa
      meir@redislabs.com authored
      When LUA call our C code, by default, the LUA stack has room for 20
      elements. In most cases, this is more than enough but sometimes it's not
      and the caller must verify the LUA stack size before he pushes elements.
      
      On 3 places in the code, there was no verification of the LUA stack size.
      On specific inputs this missing verification could have lead to invalid
      memory write:
      1. On 'luaReplyToRedisReply', one might return a nested reply that will
         explode the LUA stack.
      2. On 'redisProtocolToLuaType', the Redis reply might be deep enough
         to explode the LUA stack (notice that currently there is no such
         command in Redis that returns such a nested reply, but modules might
         do it)
      3. On 'ldbRedis', one might give a command with enough arguments to
         explode the LUA stack (all the arguments will be pushed to the LUA
         stack)
      
      This commit is solving all those 3 issues by calling 'lua_checkstack' and
      verify that there is enough room in the LUA stack to push elements. In
      case 'lua_checkstack' returns an error (there is not enough room in the
      LUA stack and it's not possible to increase the stack), we will do the
      following:
      1. On 'luaReplyToRedisReply', we will return an error to the user.
      2. On 'redisProtocolToLuaType' we will exit with panic (we assume this
         scenario is rare because it can only happen with a module).
      3. On 'ldbRedis', we return an error.
      666ed7fa
    • meir@redislabs.com's avatar
      Fix protocol parsing on 'ldbReplParseCommand' (CVE-2021-32672) · 6ac3c0b7
      meir@redislabs.com authored
      The protocol parsing on 'ldbReplParseCommand' (LUA debugging)
      Assumed protocol correctness. This means that if the following
      is given:
      *1
      $100
      test
      The parser will try to read additional 94 unallocated bytes after
      the client buffer.
      This commit fixes this issue by validating that there are actually enough
      bytes to read. It also limits the amount of data that can be sent by
      the debugger client to 1M so the client will not be able to explode
      the memory.
      6ac3c0b7
    • Oran Agra's avatar
      Prevent unauthenticated client from easily consuming lots of memory (CVE-2021-32675) · 5674b005
      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)
      5674b005
    • Oran Agra's avatar
      Fix redis-cli / redis-sential overflow on some platforms (CVE-2021-32762) · bb7597f4
      Oran Agra authored
      The redis-cli command line tool and redis-sentinel service may be vulnerable
      to integer overflow when parsing specially crafted large multi-bulk network
      replies. This is a result of a vulnerability in the underlying hiredis
      library which does not perform an overflow check before calling the calloc()
      heap allocation function.
      
      This issue only impacts systems with heap allocators that do not perform their
      own overflow checks. Most modern systems do and are therefore not likely to
      be affected. Furthermore, by default redis-sentinel uses the jemalloc allocator
      which is also not vulnerable.
      bb7597f4
    • Oran Agra's avatar
      Fix Integer overflow issue with intsets (CVE-2021-32687) · a30d367a
      Oran Agra authored
      The vulnerability involves changing the default set-max-intset-entries
      configuration parameter to a very large value and constructing specially
      crafted commands to manipulate sets
      a30d367a
  6. 21 Jul, 2021 1 commit