# base64_encode() memory issue - Thread: https://externals.io/message/14219 - Original archive: https://news-web.php.net/php.internals/14219 - Started by Ron Korving on 2004-12-28T15:44:59+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #14219 — Ron Korving — 2004-12-28T15:44:59+00:00 URL: https://externals.io/message/14219#14219 Hi, I'm not sure how to test what I noticed, so I figured I would post this here and see if any of you could test it and see if I'm correct. When I test this in a non-PHP environment with malloc(), this does present a problem however, and when running segfaults randomly appear because of it. In base64.c, the string is closed with a \0 byte, but this one byte is never allocated. Since it's just 1 byte, this often happens without causing trouble, but every once in a while it does cause a segfault. I hope someone can confirm this. Happy holidays, Ron --- ## #14233 — Andi Gutmans — 2004-12-30T01:44:34+00:00 URL: https://externals.io/message/14219#14233 · In reply to: #14219 Do you have a patch which you think should be applied? If not, can you send a reproducing script (a short one). Maybe you want to run it through valgrind and see where the damage is done. Andi At 04:44 PM 12/28/2004 +0100, Ron Korving wrote: >Hi, > >I'm not sure how to test what I noticed, so I figured I would post this here >and see if any of you could test it and see if I'm correct. When I test this >in a non-PHP environment with malloc(), this does present a problem however, >and when running segfaults randomly appear because of it. > >In base64.c, the string is closed with a \0 byte, but this one byte is never >allocated. Since it's just 1 byte, this often happens without causing >trouble, but every once in a while it does cause a segfault. I hope someone >can confirm this. > >Happy holidays, > >Ron --- ## #14237 — Ron Korving — 2004-12-30T08:27:30+00:00 URL: https://externals.io/message/14219#14237 · In reply to: #14233 A patch (I'm not familiar with the normal protocol) would simply be to increase the allocated size by 1: result = (unsigned char *)safe_emalloc(((length + 2) / 3) * 4, sizeof(char), 1); would become result = (unsigned char *)safe_emalloc(((length + 2) / 3) * 4 + 1, sizeof(char), 1); But I must add, I've only tried this function in a non-php environment in C with malloc(). Maybe I'm just looking at it the wrong way in the case of php, but in this specific environment I had (C, malloc() and not safe_emalloc(), no php interpreting), the base64 encode function would allocate 1 byte short of what it needed because of the \0 byte at the end of the string. This at least happened as I tried to encode a 9 character long string. So maybe safe_emalloc() provides for this 1 byte and this whole post can be ignored, otherwise I think someone with a little more knowledge about the php engine should look into it. Ron "Andi Gutmans" schreef in bericht news:5.1.0.14.2.20041229174350.02ed81c0@localhost... > Do you have a patch which you think should be applied? If not, can you send > a reproducing script (a short one). Maybe you want to run it through > valgrind and see where the damage is done. > > Andi > > At 04:44 PM 12/28/2004 +0100, Ron Korving wrote: > > […] here > > […] this > > […] however, > > […] never > > […] someone > > […] --- ## #14238 — Ron Korving — 2004-12-30T08:28:56+00:00 URL: https://externals.io/message/14219#14238 · In reply to: #14233 Forgot to add that in my specific case valgrind mentioned an illegal read and write of 1 byte. Ron "Andi Gutmans" schreef in bericht news:5.1.0.14.2.20041229174350.02ed81c0@localhost... > Do you have a patch which you think should be applied? If not, can you send > a reproducing script (a short one). Maybe you want to run it through > valgrind and see where the damage is done. > > Andi > > At 04:44 PM 12/28/2004 +0100, Ron Korving wrote: > > […] here > > […] this > > […] however, > > […] never > > […] someone > > […] --- ## #14239 — Stefan Esser — 2004-12-30T10:02:29+00:00 URL: https://externals.io/message/14219#14239 · In reply to: #14237 Hello, this issue was already cleared as bogus safe_emalloc already takes care of the one extra byte that should get added. safe_emalloc does allocate param1 * param2 + param3 bytes > result = (unsigned char *)safe_emalloc(((length + 2) / 3) * 4, sizeof(char), > 1); > > would become > > result = (unsigned char *)safe_emalloc(((length + 2) / 3) * 4 + 1, > sizeof(char), 1); Stefan --- ## #14240 — Ron Korving — 2004-12-30T10:15:41+00:00 URL: https://externals.io/message/14219#14240 · In reply to: #14239 My bad, sorry for wasting your time. Ron "Stefan Esser" schreef in bericht news:41D3D235.4000409@php.net... > Hello, > > this issue was already cleared as bogus > > safe_emalloc already takes care of the one extra byte that should get added. > > safe_emalloc does allocate param1 * param2 + param3 bytes > > > […] sizeof(char), > > […] > > Stefan