1. 17 Oct, 2021 1 commit
  2. 15 Oct, 2021 1 commit
  3. 14 Oct, 2021 1 commit
  4. 13 Oct, 2021 2 commits
  5. 12 Oct, 2021 1 commit
  6. 11 Oct, 2021 2 commits
  7. 10 Oct, 2021 1 commit
  8. 08 Oct, 2021 2 commits
  9. 07 Oct, 2021 2 commits
  10. 06 Oct, 2021 4 commits
    • Andy Pan's avatar
      Implement anetPipe() to combine creating pipe and setting flags (#9511) · 2391aefd
      Andy Pan authored
      
      
      Implement createPipe() to combine creating pipe and setting flags, also reduce
      system calls by prioritizing pipe2() over pipe().
      
      Without createPipe(), we have to call pipe() to create a pipe and then call some
      functions (like anetCloexec() and anetNonBlock()) of anet.c to set flags respectively,
      which leads to some extra system calls, now we can leverage pipe2() to combine
      them and make the process of creating pipe more convergent in createPipe().
      Co-authored-by: default avatarViktor Söderqvist <viktor.soderqvist@est.tech>
      Co-authored-by: default avatarOran Agra <oran@redislabs.com>
      2391aefd
    • yoav-steinberg's avatar
      Avoid argv memcpy when queuing a multi command. (#9602) · 5725088f
      yoav-steinberg authored
      When queuing a multi command we duplicated the argv (meaning an alloc
      and a memcpy). This isn't needed since we can use the previously allocated
      argv and just reset the client objects argv to NULL. This should saves some
      memory and is a minor optimization in heavy MULTI/EXEC traffic, especially
      if there are lots of arguments.
      5725088f
    • Meir Shpilraien (Spielrein)'s avatar
      Added module-acquire-GIL latency stats (#9608) · 4fb39b67
      Meir Shpilraien (Spielrein) authored
      The new value indicates how long Redis wait to
      acquire the GIL after sleep. This can help identify
      problems where a module perform some background
      operation for a long time (with the GIL held) and
      blocks the Redis main thread.
      4fb39b67
    • tzongw's avatar
      improve latency when a client is unblocked by module timer (#9593) · f5160ed0
      tzongw authored
      Scenario:
      1. client block on command `XREAD BLOCK 0 STREAMS mystream  $`
      2. in a module, calling `XADD mystream * field value` via lua from a timer callback
      3. client will receive response after some latency up to 100ms
      
      Reason:
      When `XADD` signal the key `mystream` as ready, `beforeSleep` in next eventloop will call
      `handleClientsBlockedOnKeys` to unblock the client and add pending data to write but not
      actually install a write handler, so next redis will block in `aeApiPoll` up to 100ms given `hz`
      config as default 10, pending data will be sent in another next eventloop by
      `handleClientsWithPendingWritesUsingThreads`.
      
      Calling `handleClientsBlockedOnKeys` before `handleClientsWithPendingWritesUsingThreads`
      in `beforeSleep` solves the problem.
      f5160ed0
  11. 05 Oct, 2021 1 commit
    • yoav-steinberg's avatar
      argv mem leak during multi command execution. (#9598) · 83478e61
      yoav-steinberg authored
      Changes in #9528 lead to memory leak if the command implementation
      used rewriteClientCommandArgument inside MULTI-EXEC.
      
      Adding an explicit test for that case since the test that uncovered it
      didn't specifically target this scenario
      83478e61
  12. 04 Oct, 2021 7 commits
    • Meir Shpilraien (Spielrein)'s avatar
      Fix invalid memory write on lua stack overflow (CVE-2021-32626) (#9591) · 0f8b634c
      Meir Shpilraien (Spielrein) authored
      When LUA call our C code, by default, the LUA stack has room for 10
      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.
      0f8b634c
    • Oran Agra's avatar
      Fix mem leak in loading AOF, introduced by #9528 (#9582) · 9e3dca8b
      Oran Agra authored
      Recently merged PR introduced a leak when loading AOF files.
      This was because argv_len wasn't set, so rewriteClientCommandArgument
      would shrink the argv array and updating argc to a small value.
      9e3dca8b
    • Oran Agra's avatar
      Fix protocol parsing on 'ldbReplParseCommand' (CVE-2021-32672) (#9590) · b0ca3be2
      Oran Agra 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.
      Co-authored-by: default avatarmeir@redislabs.com <meir@redislabs.com>
      b0ca3be2
    • Oran Agra's avatar
      Fix ziplist and listpack overflows and truncations (CVE-2021-32627, CVE-2021-32628) (#9589) · c5e6a620
      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.
      Co-authored-by: default avatarsundb <sundbcn@gmail.com>
      c5e6a620
    • Oran Agra's avatar
      Prevent unauthenticated client from easily consuming lots of memory (CVE-2021-32675) (#9588) · fba15850
      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)
      fba15850
    • Oran Agra's avatar
      Fix Integer overflow issue with intsets (CVE-2021-32687) (#9586) · 7cb89a5a
      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
      7cb89a5a
    • yiyuaner's avatar
      Fix integer overflow in _sdsMakeRoomFor (CVE-2021-41099) (#9558) · 24cc0b98
      yiyuaner authored
      The existing overflow checks handled the greedy growing, but didn't handle
      a case where the addition of the header size is what causes the overflow.
      24cc0b98
  13. 03 Oct, 2021 3 commits
  14. 01 Oct, 2021 1 commit
  15. 30 Sep, 2021 2 commits
  16. 29 Sep, 2021 1 commit
  17. 27 Sep, 2021 1 commit
  18. 26 Sep, 2021 3 commits
  19. 24 Sep, 2021 2 commits
  20. 23 Sep, 2021 2 commits