ftp_range: avoid integer overflow when figuring out byte range #2205
Conversation
|
Travis issues are CI related and not code related. |
lib/ftp.c
Outdated
| data->req.maxdownload = (to - from) + 1; /* include last byte */ | ||
| totalsize = to-from; | ||
| if(totalsize == CURL_OFF_T_MAX) | ||
| /* this is too big to increase, so bail out */ |
There was a problem hiding this comment.
I would get rid of this comment it's implied. also you can declare totalsize in this block. also since we're here this could use a check to make sure from <= to
There was a problem hiding this comment.
This code is basically a copy of the code from https://github.com/curl/curl/blob/master/lib/file.c#L166 that @bagder wrote; should we be updating both places?
There was a problem hiding this comment.
We could, but I'd rather not lump a change of file.c into this fix as it isn't really related to this FTP range integer overflow...
There was a problem hiding this comment.
The reason I ask is that you made a change to file_range to fix a bug, file_range has the comment
/*
Check if this is a range download, and if so, set the internal variables
properly. This code is copied from the FTP implementation and might as
well be factored out.
*/
and the ftp_range function still has the issue. So my assumption is that any fixes (or markups) that need to be made in one place should be made in the other as well.
There was a problem hiding this comment.
Let's turn file_range() into Curl_range() and make both the FILE and FTP code use it.
The only difference I can spot is that ftp_range() sets ftpc->dont_check = TRUE when a range has been set, so we should make sure to set that separately.
What do you think?
There was a problem hiding this comment.
Happy with that. Do you want to run with that or shall I?
There was a problem hiding this comment.
Please go ahead, I have a few other tasks to work on anyway! =)
cmeister2
force-pushed
the
cmeister2/ftprange
branch
from
045789c
to
9c81a35
Compare
lib/curl_range.c
Outdated
| #if !defined(CURL_DISABLE_FTP) && !defined(CURL_DISABLE_FILE) | ||
|
|
||
| /* | ||
| * Curl_memrchr() |
There was a problem hiding this comment.
Sigh. todo: remove this
lib/curl_range.c
Outdated
|
|
||
| /* | ||
| Check if this is a range download, and if so, set the internal variables | ||
| properly. This code is copied from the FTP implementation and might as |
There was a problem hiding this comment.
And update this description...
cmeister2
force-pushed
the
cmeister2/ftprange
branch
from
9c81a35
to
103503e
Compare
|
Build looks fine apart from the MacOS failures which are known about. |
cmeister2
force-pushed
the
cmeister2/ftprange
branch
from
103503e
to
445c3e8
Compare
lib/file.c
Outdated
| @@ -514,7 +456,7 @@ static CURLcode file_do(struct connectdata *conn, bool *done) | |||
| } | |||
|
|
|||
| /* Check whether file range has been specified */ | |||
| file_range(conn); | |||
| Curl_range(conn); | |||
|
Hm, I'm not sure how github interpreted that but I think there should be a check of the return code but otherwise the change looks good! |
|
https://github.com/curl/curl/blob/master/lib/file.c#L517 in master doesn't do this check; is this something new that should be done? |
|
It's not new, but that's a flaw we can just as well correct while fixing up this code I think. |
|
What's the desired behaviour on checking the return code? Anything other than CURLE_OK is a failure and should stop the transfer? |
|
Right, the common pattern is to just: result = Curl_range(....);
if(result)
return result; |
|
Ok, done - hope that passes the tests! |
|
thanks! |
When trying to bump the value with one and the value is already at max,
it causes an integer overflow.
Detected by oss-fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=4853