Steve Langasek wrote: > On Wed, Feb 06, 2008 at 08:41:22PM +0100, Vincent Tondellier wrote: >> The patch 043-recode_size_t.patch is broken. > >> req_len and str_len should be integers, but are size_t >> (zend_parse_parameters wants pointers to int). This is a problem for 64 >> bits arches since a part of the variables is not initialized >> (sizof(size_t) != sizeof(int)), and recode_buffer_to_buffer is called >> with funny values that makes librecode eat all the system's memory. > > So then, PHP isn't capable of passing values whose length exceeds UINT_MAX? > That's an annoyingly arbitrary limitation. >
PHP isn't designed to do large memory allocations ... > But yes, your analysis here looks correct to me. > >> An updated version of the patch witch fixes the problem for me is >> attached to this mail and should be, IMO, applied as a security fix for >> etch. > > I don't see any evidence that this is a security issue, but it should be > applied as a stable release update. > I think this is a security issue since it can cause a Denial Of Service by eating all the server memory. I had the problem on one of my servers (2GB RAM / 3GB swap) and it took at least 10min for oom_killer to kill the process, and in another case the kernel crashed (I didn't change the memory limit settings in /etc/security/limits.conf). And you can trigger the bug remotely by sending a mail like Sebastian Göbel said above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
