- 20 Sep, 2019 1 commit
-
-
antirez authored
-
- 08 May, 2019 1 commit
-
-
Angus Pearson authored
-
- 09 Jan, 2019 9 commits
- 03 Jan, 2019 1 commit
-
-
Uman Shahzad authored
-
- 11 Jul, 2018 1 commit
-
-
Oran Agra authored
* overflow in jemalloc fragmentation hint to the defragger
-
- 03 Jul, 2018 1 commit
-
-
Jack Drogon authored
-
- 27 Jun, 2018 1 commit
-
-
Oran Agra authored
-
- 13 Jun, 2018 4 commits
-
-
antirez authored
After the first fix to the struct package I found another similar problem, which is fixed by this patch. It could be reproduced easily by running the following script: return struct.unpack('f', "xxxxxxxxxxxxx",-3) The above will access bytes before the 'data' pointer.
-
antirez authored
@soloestoy sent me this additional fixes, after searching for similar problems to the one reported in mp_pack(). I'm committing the changes because it was not possible during to make a public PR to protect Redis users and give Redis providers some time to patch their systems.
-
antirez authored
During an auditing Apple found that the "struct" Lua package we ship with Redis (http://www.inf.puc-rio.br/~roberto/struct/) contains a security problem. A bound-checking statement fails because of integer overflow. The bug exists since we initially integrated this package with Lua, when scripting was introduced, so every version of Redis with EVAL/EVALSHA capabilities exposed is affected. Instead of just fixing the bug, the library was updated to the latest version shipped by the author.
-
antirez authored
During an auditing effort, the Apple Vulnerability Research team discovered a critical Redis security issue affecting the Lua scripting part of Redis. -- Description of the problem Several years ago I merged a pull request including many small changes at the Lua MsgPack library (that originally I authored myself). The Pull Request entered Redis in commit 90b6337c, in 2014. Unfortunately one of the changes included a variadic Lua function that lacked the check for the available Lua C stack. As a result, calling the "pack" MsgPack library function with a large number of arguments, results into pushing into the Lua C stack a number of new values proportional to the number of arguments the function was called with. The pushed values, moreover, are controlled by untrusted user input. This in turn causes stack smashing which we believe to be exploitable, while not very deterministic, but it is likely that an exploit could be created targeting specific versions of Redis executables. However at its minimum the issue results in a DoS, crashing the Redis server. -- Versions affected Versions greater or equal to Redis 2.8.18 are affected. -- Reproducing Reproduce with this (based on the original reproduction script by Apple security team): https://gist.github.com/antirez/82445fcbea6d9b19f97014cc6cc79f8a -- Verification of the fix The fix was tested in the following way: 1) I checked that the problem is no longer observable running the trigger. 2) The Lua code was analyzed to understand the stack semantics, and that actually enough stack is allocated in all the cases of mp_pack() calls. 3) The mp_pack() function was modified in order to show exactly what items in the stack were being set, to make sure that there is no silent overflow even after the fix. -- Credits Thank you to the Apple team and to the other persons that helped me checking the patch and coordinating this communication.
-
- 25 May, 2018 1 commit
-
-
antirez authored
Close #4947.
-
- 24 May, 2018 5 commits
- 17 May, 2018 1 commit
-
-
Oran Agra authored
problems fixed: * failing to read fragmentation information from jemalloc * overflow in jemalloc fragmentation hint to the defragger * test suite not triggering eviction after population
-
- 22 Apr, 2017 1 commit
-
- 30 Jan, 2017 1 commit
-
-
antirez authored
The original jemalloc source tree was modified to: 1. Remove the configure error that prevents nested builds. 2. Insert the Redis private Jemalloc API in order to allow the Redis fragmentation function to work.
-
- 10 Jan, 2017 1 commit
-
-
antirez authored
This commit also includes minor aesthetic changes like removal of trailing spaces.
-
- 30 Dec, 2016 1 commit
-
-
oranagra authored
-
- 21 Dec, 2016 1 commit
-
-
antirez authored
Close #3687.
-
- 29 Jul, 2016 1 commit
-
-
antirez authored
The problem was fixed in antirez/linenoise repository applying a patch contributed by @lamby. Here the new version is updated in the Redis source tree. Close #1418 Close #3322
-
- 06 Jul, 2016 1 commit
-
-
antirez authored
They were under /deps since they originate from a different source tree, however at this point they are very modified and we took ownership of both the files making changes, fixing bugs, so there is no upgrade path from the original code tree. Given that, better to move the code under /src with proper dependencies and with a more simpler editing experience.
-
- 30 May, 2016 2 commits
-
-
antirez authored
I'm the author of this line but I can't see a good reason for it to don't be a typo, a step of 26 should be valid with 52 bits per coordinate, moreover the line was: if (step > 26) step = 25; So a step of 26 was actually already used, except when one of 27 was computed (which is invalid) only then it was trimmed to 25 instead of 26. All tests passing after the change.
-
antirez authored
Close #3266
-
- 18 May, 2016 1 commit
-
-
antirez authored
This change is documented in deps/README.md but was lost in one way or the other, neutralizing the benefits of 24 bytes size classes (and others). Close #3208.
-
- 13 Apr, 2016 1 commit
-
-
antirez authored
-
- 12 Apr, 2016 1 commit
-
-
antirez authored
-
- 06 Apr, 2016 1 commit
-
-
antirez authored
As a side effect, cat commands.txt | redis-cli now is able to handle lines more than 4096 bytes.
-
- 10 Feb, 2016 1 commit
-
-
antirez authored
-