vjzning / redis

Automatically exported from code.google.com/p/redis
https://code.google.com/p/redis/
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

SET operation with invalid length. #166

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Let's say that I have this in a file:
-------------------------------------
SET foo 8
BAR<crlf>
<crlf>
<crlf>
<crlf>
<crlf>
<crlf>
<crlf>

and then run: cat foo.txt | nc localhost 6379

Redis will insert the key foo with the value BAR<crlf><crlf> but report 8 
as the length. Shouldn't an error have been reported while adding the 
value, and if a poorly written client tries to parse the result one might 
get a buffer overflow error since redis reports the wrong size in the 
reply.

Original issue reported on code.google.com by chr...@gmail.com on 25 Feb 2010 at 2:21

GoogleCodeExporter commented 9 years ago
I think this is working as expected. When you send a newline (<crlf>) via 
telnet the 
server ignores it unless it is expecting a value. In your example foo is set to 
"BAR\r\n\r\n\r". So Redis is reporting the correct length of 8, and there is no 
buffer overflow.

To validate this yourself. Issue your "cat foo.txt | nc localhost 6379", then 
issue 
"echo GET foo | nc localhost 6379 > foo2.txt". If you look at this file with 
hexdump 
you'll see:
00000000  24 38 0d 0a 42 41 52 0d  0a 0d 0a 0d 0d 0a        |$8..BAR.......|

There are two starting bytes "$8", then another two bytes, "\r\n". This is then 
followed by 8 chars "BAR\r\n\r\n\r", and finally a "\r\n" (which is not part of 
the 
value).

Original comment by brampton on 27 Mar 2010 at 3:51

GoogleCodeExporter commented 9 years ago
Indeed, there is no bug about that, setting the issue as invalid.
Thanks for reporting, and thanks to brampton for the very informative comment.

Original comment by anti...@gmail.com on 27 Mar 2010 at 7:33