php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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: [email protected] Assigned: aharvey (profile)
Status: Closed Package: Filter related
PHP Version: 5.3.3 OS:
Private report: No CVE-ID: 2010-3710
View Developer Edit
 [2010-09-27 02:09 UTC] [email protected] 
Description:
------------
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:
---------------
<?php
  $email = file_get_contents('x.data');
  $r = filter_var($email, FILTER_VALIDATE_EMAIL);
  var_dump($r);

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

Expected result:
----------------
bool(false)

Actual result:
--------------
segfault

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-09-27 02:38 UTC] [email protected] 
Looking at the source at
http://svn.php.net/viewvc/php/php-src/trunk/ext/filter/logical_filters.c?view=markup
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] [email protected]
-Package: Unknown/Other Function +Package: Filter related
 [2010-09-27 05:19 UTC] [email protected] 
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 
preg_replace
 [2010-09-27 05:21 UTC] [email protected] 
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] [email protected] 
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] [email protected]
-Status: Open +Status: Assigned -Assigned To: +Assigned To: aharvey
 [2010-09-27 08:47 UTC] [email protected] 
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] [email protected] 
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] [email protected] 
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=303779
Log: Fix bug #52929 (Segfault in filter_var with FILTER_VALIDATE_EMAIL with large
amount of data).
 [2010-09-27 09:08 UTC] [email protected]
-Status: Assigned +Status: Closed
 [2010-09-27 09:08 UTC] [email protected] 
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.
 [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] [email protected] 
Hi, 5.2.x branch is in security bug fixes only. :)
 [2010-09-28 15:14 UTC] [email protected] 
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] [email protected] 
@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] [email protected] 
Automatic comment from SVN on behalf of aharvey
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=303885
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] [email protected] 
Merged to 5.2.
 [2010-10-19 11:57 UTC] [email protected] 
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=304507
Log: - update #52929 and zip NULL deref
 [2010-10-19 12:15 UTC] [email protected] 
CVE-2010-3710 has been created for this issue.
 [2010-10-19 12:16 UTC] [email protected] 
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=304508
Log: - update #52929 and zip NULL deref
 [2010-11-16 21:31 UTC] [email protected]
-CVE-ID: +CVE-ID: 2010-3710
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Dec 28 03:00:01 2025 UTC