- 20 Jan, 2022 1 commit
-
-
Oran Agra authored
-
- 04 Oct, 2021 8 commits
-
-
Oran Agra authored
-
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. (cherry picked from commit 68e221a3f98a427805d31c1760b4cdf37ba810ab)
-
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. (cherry picked from commit d32a3f74f2a343846b50920e95754a955c1a10a9)
-
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. (cherry picked from commit 4f95e6809902665ced50646107d174dd8137bcaa)
-
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)
-
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. (cherry picked from commit dbb5d95046e6a415fbd32c721c56e9ea32632898)
-
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 (cherry picked from commit 4cb7075edaaf0584c74eb080d838ca8f56c190e3)
-
YiyuanGUO authored
-
- 21 Jul, 2021 3 commits
-
-
Oran Agra authored
-
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)
-
Rob Snyder authored
Adds call to intrev16ifbe to ensure ZIPLIST_LENGTH is compared correctly (cherry picked from commit eaa52719)
-
- 02 Mar, 2021 2 commits
-
-
Oran Agra authored
-
Yossi Gottlieb authored
Also adds a new daily CI test, relying on the fact that we don't use malloc_size() on alpine libmusl. Fixes #8531 (cherry picked from commit dd885780)
-
- 22 Feb, 2021 12 commits
-
-
Oran Agra authored
-
Oran Agra authored
-
Yossi Gottlieb authored
On 32-bit systems, setting the proto-max-bulk-len config parameter to a high value may result with integer overflow and a subsequent heap overflow when parsing an input bulk (CVE-2021-21309). This fix has two parts: Set a reasonable limit to the config parameter. Add additional checks to prevent the problem in other potential but unknown code paths. (cherry picked from commit d32f2e99) Fix MSVR reported issue.
-
Viktor Söderqvist authored
Without this fix, RM_ZsetRem can leave empty sorted sets which are not allowed to exist. Removing from a sorted set while iterating seems to work (while inserting causes failed assetions). RM_ZsetRangeEndReached is modified to return 1 if the key doesn't exist, to terminate iteration when the last element has been removed. (cherry picked from commit aea6e71e)
-
Meir Shpilraien (Spielrein) authored
Turns out that when the fork child crashes, the crash log was deleting the pidfile from the disk (although the parent is still running. Now we set the pidfile of the fork process to NULL so the fork process will never deletes it. (cherry picked from commit 92a483bc)
-
杨博东 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:
Oran Agra <oran@redislabs.com> (cherry picked from commit cbaf3c5b)
-
Yossi Gottlieb authored
At least in one case the arm64 cow kernel bug test triggers an assert, which is a problem because it cannot be ignored like cases where the bug is found. On older systems (Linux <4.5) madvise fails because MADV_FREE is not supported. We treat these failures as an indication the system is not affected. Fixes #8351, #8406 (cherry picked from commit 3a504904)
-
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:
Oran Agra <oran@redislabs.com> (cherry picked from commit b02780c4)
-
Yossi Gottlieb authored
Makes spt_init more careful with assumptions about what memory regions may be overwritten. It will now only consider a contiguous block of argv and envp elements and mind any gaps. (cherry picked from commit ec02c761)
-
Yossi Gottlieb authored
Seems to have gone unnoticed for a long time, because at least with glibc it will only be triggered if setenv() was called before spt_init, which Redis doesn't. Fixes #8064. (cherry picked from commit 7e5a6313)
-
namtsui authored
The Redis sentinel would crash with a segfault after a few minutes because it tried to read from a page without read permissions. Check up front whether the sds is long enough to contain redis:slave or redis:master before memcmp() as is done everywhere else in sentinelRefreshInstanceInfo(). Bug report and commit message from Theo Buehler. Fix from Nam Nguyen. Co-authored-by:
Nam Nguyen <namn@berkeley.edu> (cherry picked from commit 63dae523)
-
- 27 Oct, 2020 14 commits
-
-
Oran Agra authored
-
Yossi Gottlieb authored
This fixes the issue described in CVE-2014-5461. At this time we cannot confirm that the original issue has a real impact on Redis, but it is included as an extra safety measure. (cherry picked from commit d75ad774) (cherry picked from commit 941174d9c9ed438f1c70dd46cddc02468614db12)
-
Yossi Gottlieb authored
When using a system with no malloc_usable_size(), zmalloc_size() assumed that the heap allocator always returns blocks that are long-padded. This may not always be the case, and will result with zmalloc_size() returning a size that is bigger than allocated. At least in one case this leads to out of bound write, process crash and a potential security vulnerability. Effectively this does not affect the vast majority of users, who use jemalloc or glibc. This problem along with a (different) fix was reported by Drew DeVault. (cherry picked from commit 9824fe3e) (cherry picked from commit ce0d74d8fdff55d07929f562ec9acf2d00caf893)
-
WuYunlong authored
We should sync temp DB file before renaming as rdb_fsync_range does not use flag `SYNC_FILE_RANGE_WAIT_AFTER`. Refer to `Linux Programmer's Manual`: SYNC_FILE_RANGE_WAIT_AFTER Wait upon write-out of all pages in the range after performing any write. (cherry picked from commit 0d62caab)
-
Ariel Shtul authored
redis-check-rdb was unable to parse rdb files containing module aux data. Co-authored-by:
Oran Agra <oran@redislabs.com> (cherry picked from commit 63a05dde)
-
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)
-
Angus Pearson authored
This addresses two problems, one where infinite (negative) repeat count is broken for all types for Redis, and another specific to cluster mode where redirection is needed. Now allows and works correctly for negative (i.e. -1) repeat values passed with `-r` argument to redis-cli as documented here https://redis.io/topics/rediscli#continuously-run-the-same-command which seems to have regressed as a feature in 95b988 (though that commit removed bad integer wrap-around to `0` behaviour). This broken behaviour exists currently (e50458), and redis-cli will just exit immediately with repeat `-r <= 0` as opposed to send commands indefinitely as it should with `-r < 0` Additionally prevents a repeat * interval seconds hang/time spent doing nothing at the start before issuing commands in cluster mode (`-c`), where the command needed to redirect to a slot on another node, as commands where failing and waiting to be reissued but this was fully repeated before being reissued. For example, redis-cli -c -r 10 -i 0.5 INCR test_key_not_on_6379 Would hang and show nothing for 5 seconds (10 * 0.5) before showing (integer) 1 (integer) 2 (integer) 3 (integer) 4 (integer) 5 (integer) 6 (integer) 7 (integer) 8 (integer) 9 (integer) 10 at half second intervals as intended. (cherry picked from commit 2f6ed933)
-
antirez authored
We want to send pings and pongs at specific intervals, since our packets also contain information about the configuration of the cluster and are used for gossip. However since our cluster bus is used in a mixed way for data (such as Pub/Sub or modules cluster messages) and metadata, sometimes a very busy channel may delay the reception of pong packets. So after discussing it in #7216, this commit introduces a new field that is not exposed in the cluster, is only an internal information about the last time we received any data from a given node: we use this field in order to avoid detecting failures, claiming data reception of new data from the node is a proof of liveness. (cherry picked from commit 960186a7)
-
Madelyn Olson authored
partial cherry pick from 7d217547
-
Guy Benoish authored
Fixes GitHub issue #6492 Added stream support in RM_KeyType and RM_ValueLength. Also moduleDelKeyIfEmpty was updated, even though it has no effect now (It will be relevant when stream type direct API will be coded - i.e. RM_StreamAdd) cherry picked from commit 1833d008 * modified to avoid adding new API to 5.0 (reverting the change to RM_KeyType)
-
Itamar Haber authored
Otherwise, it is treated as a single allocation and freed synchronously. The following logic is used for estimating the effort in constant-ish time complexity: 1. Check the number of nodes. 1. Add an allocation for each consumer group registered inside the stream. 1. Check the number of PELs in the first CG, and then add this count times the number of CGs. 1. Check the number of consumers in the first CG, and then add this count times the number of CGs. (cherry picked from commit 5b0a06af) (cherry picked from commit 5a9a653f)
-