|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52929 Segfault in filter_var with FILTER_VALIDATE_EMAIL with large amount of data
Submitted: 2010-09-27 02:09 UTC Modified: 2010-11-16 21:31 UTC
From: Assigned: aharvey (profile)
Status: Closed Package: Filter related
PHP Version: 5.3.3 OS:
Private report: No CVE-ID: 2010-3710
 [2010-09-27 02:09 UTC]
Using the attached test-script with just a large amount of data (e.g. 8kb of just "x") segfaults php. Tried with 5.3.3 (Fedora) and also some 5.3.4-snapshot that I could get hold of.

Crashed for me with around 8kb of data. If it works fine for you, maybe increase that limit to 16kb or so.

Test script:
  $email = file_get_contents('');
  $r = filter_var($email, FILTER_VALIDATE_EMAIL);

// and just dump a large number of characters like "x" in
// for a in `seq 1 8000`; do echo -n x>>; done

Expected result:

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-09-27 02:38 UTC]
Looking at the source at
I wonder if the problem itself might be in the pcre-lib used since the email-validation itself is PCRE-based? Fedora Linux here ships with PCRE 7.8.
 [2010-09-27 04:16 UTC]
-Package: Unknown/Other Function +Package: Filter related
 [2010-09-27 05:19 UTC]
This is the normal issue with heavily nested regular expressions
exhausting the available stack size. I can upload a backtrace if
there's a sudden desire to see several thousand recursive
invocations of PCRE's match function. :)

I'm not really comfortable closing this, even though we normally just close 
 [2010-09-27 05:21 UTC]
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.
 [2010-09-27 07:24 UTC]
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 08:47 UTC]
-Status: Open +Status: Assigned -Assigned To: +Assigned To: aharvey
 [2010-09-27 08:47 UTC]
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 09:00 UTC]
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 09:08 UTC]
Automatic comment from SVN on behalf of aharvey
Log: Fix bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL with large
amount of data).
 [2010-09-27 09:08 UTC]
-Status: Assigned +Status: Closed
 [2010-09-27 09:08 UTC]
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
Thank you for the report, and for helping us make PHP better.

 [2010-09-28 15:03 UTC] support at hosting-agency dot de
This problem is also included in PHP version 5.2.14
 [2010-09-28 15:12 UTC]
Hi, 5.2.x branch is in security bug fixes only. :)
 [2010-09-28 15:14 UTC]
Well, a remotely triggerable segfault might be worth a security-thought/backport of such a minimal invasive patch, wouldn't it? :-)
 [2010-09-28 16:43 UTC] f dot stolle at hosting-agency dot de
The problem exists also in PHP 5.2.14.
 [2010-09-29 05:31 UTC]
@Stefan: It might be. I've pinged Ilia and Johannes to look at it and
decide if they want it merged to 5.2.
 [2010-09-30 04:35 UTC]
Automatic comment from SVN on behalf of aharvey
Log: MFH: Fix for bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL with
large amount of data).
 [2010-09-30 04:36 UTC]
Merged to 5.2.
 [2010-10-19 11:57 UTC]
Automatic comment from SVN on behalf of pajoye
Log: - update #52929 and zip NULL deref
 [2010-10-19 12:15 UTC]
CVE-2010-3710 has been created for this issue.
 [2010-10-19 12:16 UTC]
Automatic comment from SVN on behalf of pajoye
Log: - update #52929 and zip NULL deref
 [2010-11-16 21:31 UTC]
-CVE-ID: +CVE-ID: 2010-3710
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Feb 26 10:01:27 2024 UTC