| commit | be2d37ad3cbb5a36fee410f2e36e53b1ee019f48 | |
| author | Nick Mathewson <nickm@torproject.org> | |
| Thu, 19 May 2016 14:52:27 +0000 (19 10:52 -0400) | ||
| committer | Nick Mathewson <nickm@torproject.org> | |
| Wed, 25 May 2016 13:20:37 +0000 (25 09:20 -0400) | ||
| tree | 1172f66b9cb9a9d8b2e36cb8731915407eaf5c86 | treesnapshot (tar.gz zip) |
| parent | 4165b1a0da893a9f67a2ba32b4fcd54a7804ce14 | commitdiff |
Fix a pointer arithmetic bug in memarea_alloc()
Fortunately, the arithmetic cannot actually overflow, so long as we
*always* check for the size of potentially hostile input before
copying it. I think we do, though. We do check each line against
MAX_LINE_LENGTH, and each object name or object against
MAX_UNPARSED_OBJECT_SIZE, both of which are 128k. So to get this
overflow, we need to have our memarea allocated way way too high up
in RAM, which most allocators won't actually do.
Bugfix on 0.2.1.1-alpha, where memarea was introduced.
Found by Guido Vranken.
Fortunately, the arithmetic cannot actually overflow, so long as we
*always* check for the size of potentially hostile input before
copying it. I think we do, though. We do check each line against
MAX_LINE_LENGTH, and each object name or object against
MAX_UNPARSED_OBJECT_SIZE, both of which are 128k. So to get this
overflow, we need to have our memarea allocated way way too high up
in RAM, which most allocators won't actually do.
Bugfix on 0.2.1.1-alpha, where memarea was introduced.
Found by Guido Vranken.
| changes/memarea_overflow | [new file with mode: 0644] | blob |
| src/common/memarea.c | diffblobblamehistory |