- 12 12月, 2018 3 次提交
-
-
由 antirez 提交于
Fake clients are used in special situations and are not linked to the normal clients list, freeing them will always result in Redis crashing in one way or the other. It's not common to send replies to fake clients, but we have one usage in the modules API. When a client is blocked, we associate to the blocked client object (that is safe to manipulate in a thread), a fake client that accumulates replies. So because of this bug there was the problem described in issue #5443. The fix was verified to work with the provided example module. To write a regression is very hard and unlikely to be triggered in the future.
-
由 Guy Benoish 提交于
-
由 antirez 提交于
See #5632.
-
- 22 11月, 2018 1 次提交
-
-
由 Salvatore Sanfilippo 提交于
Backport #4497 to redis 4
-
- 14 11月, 2018 2 次提交
-
-
由 antirez 提交于
We have this operation in two places: when caching the master and when linking a new client after the client creation. By having an API for this we avoid incurring in errors when modifying one of the two places forgetting the other. The function is also a good place where to document why we cache the linked list node. Related to #4497 and #4210.
-
由 zhaozhao.zz 提交于
-
- 31 10月, 2018 3 次提交
-
-
由 antirez 提交于
This logs what happens in the context of the fix in PR #5367.
-
由 Andrey Bugaevskiy 提交于
-
由 Andrey Bugaevskiy 提交于
During the full database resync we may still have unsaved changes on the receiving side. This causes a race condition between synced data rename/load and the rename of rdbSave tempfile.
-
- 10 10月, 2018 3 次提交
-
-
由 antirez 提交于
Related to #5201. I removed the !!! Warning part since compared to the other errors, a missing EXEC is in theory a normal happening in the AOF file, at least in theory: may happen in a differnet number of situations, and it's probably better to don't give the user the feeling that something really bad happened.
-
由 zhaozhao.zz 提交于
-
由 antirez 提交于
Realted to #5201.
-
- 04 8月, 2018 1 次提交
-
-
由 antirez 提交于
-
- 03 8月, 2018 3 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
PR #5081 fixes an "interesting" bug about Redis Cluster failover but in general about the updating of repl_down_since, that is used in order to count the time a slave was left disconnected from its master. While the fix provided resolves the specific issue, in general the validity of repl_down_since is limited to states that are different than the state CONNECTED, and the disconnected time is set when the state is DISCONNECTED. However from CONNECTED to other states, the state machine must always go to DISCONNECTED first. So it makes sense to set the field to zero (since it is meaningless in that context) when the state is set to CONNECTED.
-
由 WuYunlong 提交于
automatically as expected.
-
- 24 7月, 2018 1 次提交
-
-
由 Oran Agra 提交于
The slave sends \n keepalive messages to the master while parsing the rdb, and later sends REPLCONF ACK once a second. rarely, the master recives both a linefeed char and a REPLCONF in the same read, \n*3\r\n$8\r\nREPLCONF\r\n... and it tries to trim two chars (\r\n) from the query buffer, trimming the '*' from *3\r\n$8\r\nREPLCONF\r\n... then the master tries to process a command starting with '3' and replies to the slave a bunch of -ERR and one +OK. although the slave silently ignores these (prints a log message), this corrupts the replication offset at the slave since the slave increases the replication offset, and the master did not. other than the fix in processInlineBuffer, i did several other improvments while hunting this very rare bug. - when redis replies with "unknown command" it includes a portion of the arguments, not just the command name. so it would be easier to understand what was recived, in my case, on the slave side, it was -ERR, but the "arguments" were the interesting part (containing info on the error). - about a year ago i added code in addReplyErrorLength to print the error to the log in case of a reply to master (since this string isn't actually trasmitted to the master), now changed that block to print a similar log message to indicate an error being sent from the master to the slave. note that the slave is marked as CLIENT_SLAVE only after PSYNC was received, so this will not cause any harm for REPLCONF, and will only indicate problems that are gonna corrupt the replication stream anyway. - two places were c->reply was emptied, and i wanted to reset sentlen this is a precaution (i did not actually see such a problem), since a non-zero sentlen will cause corruption to be transmitted on the socket.
-
- 29 6月, 2018 3 次提交
-
-
由 zhaozhao.zz 提交于
-
由 antirez 提交于
Thanks to @kevinmcgehee for signaling the issue and reasoning about the consequences and potential fixes. Issue #5015.
-
由 antirez 提交于
The ability of "SENTINEL SET" to change the reconfiguration script at runtime is a problem even in the security model of Redis: any client inside the network may set any executable to be ran once a failover is triggered. This option adds protection for this problem: by default the two SENTINEL SET subcommands modifying scripts paths are denied. However the user is still able to rever that using the Sentinel configuration file in order to allow such a feature.
-
- 13 6月, 2018 6 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
Thanks to Fakhri Zulkifli for reporting it. The fix switched to dynamic allocation, copying the final prompt in the static buffer only at the end.
-
由 antirez 提交于
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 提交于
@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 提交于
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 提交于
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.
-
- 01 6月, 2018 1 次提交
-
-
由 赵磊 提交于
-
- 29 5月, 2018 11 次提交
-
-
由 dejun.xdj 提交于
-
由 dejun.xdj 提交于
In case that the incoming repeat parameter is negative and causes a deadless loop.
-
由 dejun.xdj 提交于
To be in consistent with the original definition.
-
由 dejun.xdj 提交于
If command like "-1 set a b" is sent with redis-cli, it will cause a deadless loop. So some repeat value checking logic is added to avoid this.
-
由 dejun.xdj 提交于
Put the repeat option checking code a little forward to avoid repeat logic.
-
由 dejun.xdj 提交于
-
由 dejun.xdj 提交于
-
由 dejun.xdj 提交于
-
由 antirez 提交于
The AOF tail of a combined RDB+AOF is based on the premise of applying the AOF commands to the exact state that there was in the server while the RDB was persisted. By expiring keys while loading the RDB file, we change the state, so applying the AOF tail later may change the state. Test case: * Time1: SET a 10 * Time2: EXPIREAT a $time5 * Time3: INCR a * Time4: PERSIT A. Start bgrewiteaof with RDB preamble. The value of a is 11 without expire time. * Time5: Restart redis from the RDB+AOF: consistency violation. Thanks to @soloestoy for providing the patch. Thanks to @trevor211 for the original issue report and the initial fix. Check issue #4950 for more info.
-
由 WuYunlong 提交于
we add a new slave, and do a failover, eighter by manual or not, other local slaves will delete the expired keys properly.
-
由 antirez 提交于
Close #4947.
-
- 23 5月, 2018 2 次提交
-
-
由 antirez 提交于
-
由 antirez 提交于
While this feature is not used by Redis, ae.c implements the ability for a timer to call a finalizer callback when an timer event is deleted. This feature was bugged since the start, and because it was never used we never noticed a problem. However Anthony LaTorre was using the same library in order to implement a different system: he found a bug that he describes as follows, and which he fixed with the patch in this commit, sent me by private email: --- Anthony email --- 've found one bug in the current implementation of the timed events. It's possible to lose track of a timed event if an event is added in the finalizerProc of another event. For example, suppose you start off with three timed events 1, 2, and 3. Then the linked list looks like: 3 -> 2 -> 1 Then, you run processTimeEvents and events 2 and 3 finish, so now the list looks like: -1 -> -1 -> 2 Now, on the next iteration of processTimeEvents it starts by deleting the first event, and suppose this finalizerProc creates a new event, so that the list looks like this: 4 -> -1 -> 2 On the next iteration of the while loop, when it gets to the second event, the variable prev is still set to NULL, so that the head of the event loop after the next event will be set to 2, i.e. after deleting the next event the event loop will look like: 2 and the event with id 4 will be lost. I've attached an example program to illustrate the issue. If you run it you will see that it prints: ``` foo id = 0 spam! ``` But if you uncomment line 29 and run it again it won't print "spam!". --- End of email --- Test.c source code is as follows: #include "ae.h" #include <stdio.h> aeEventLoop *el; int foo(struct aeEventLoop *el, long long id, void *data) { printf("foo id = %lld\n", id); return AE_NOMORE; } int spam(struct aeEventLoop *el, long long id, void *data) { printf("spam!\n"); return AE_NOMORE; } void bar(struct aeEventLoop *el, void *data) { aeCreateTimeEvent(el, 0, spam, NULL, NULL); } int main(int argc, char **argv) { el = aeCreateEventLoop(100); //aeCreateTimeEvent(el, 0, foo, NULL, NULL); aeCreateTimeEvent(el, 0, foo, NULL, bar); aeMain(el); return 0; } Anthony fixed the problem by using a linked list for the list of timers, and sent me back this patch after he tested the code in production for some time. The code looks sane to me, so committing it to Redis.
-