Bug #52929 [Asn->Csd]: Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data

Edit report at http://bugs.php.net/bug.php?id=52929&edit=1 ID: 52929 Updated by: aharvey@php.net Reported by: neufeind@php.net Summary: Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data -Status: Assigned +Status: Closed Type: Bug Package: Filter related PHP Version: 5.3.3 Assigned To: aharvey Block user comment: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: ------------------------------------------------------------------------ [2010-09-27 09:08:06] aharvey@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=303779 Log: Fix bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data). ------------------------------------------------------------------------ [2010-09-27 09:00:05] neufeind@php.net Well, then how about please at least adding a pre-filter as rasmus suggested? For the special case (I agree) of email-validation that should be possible. ------------------------------------------------------------------------ [2010-09-27 08:47:09] aharvey@php.net Fair call; I'll prosecute the argument for NO_RECURSE elsewhere! The limit on address length is 320 octets per RFC 2821 (64 octet local-part + 1 octet "@" + 255 octet domain), so we may as well set the limit there for now. (If RFC 5336 becomes widespread, that may need to be revisited, but let's cross that bridge when we come to it.) Any system that's so stack constrained for that to be an issue is likely to have other problems anyway. :) Fix for 5.3 and trunk forthcoming, just as soon as I write a test. ------------------------------------------------------------------------ [2010-09-27 07:24:16] rasmus@php.net Perhaps a simple pre-filter before we hit the regex. You can't actually have an 8k email address. There are length limits both before and after the @. ------------------------------------------------------------------------ [2010-09-27 05:21:50] aharvey@php.net I hate you, Chrome. Anyway, as I was saying, I'm not terribly comfortable closing this, since it's likely sites will actually be passing user data straight to filter_var(). I mean, that's what it's there for. Is it worth revisiting the decision to compile our bundled libpcre in its default stack recursive mode? I know NO_RECURSE is slower, but I'm nervous about potential remote crashers. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=52929 -- Edit this bug report at http://bugs.php.net/bug.php?id=52929&edit=1