|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #47736 imap_headerinfo() segfaults with large address lists
Submitted: 2009-03-20 19:24 UTC Modified: 2009-05-01 18:48 UTC
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: etremblay at kronostechnologies dot com Assigned: pajoye (profile)
Status: Not a bug Package: IMAP related
PHP Version: 5.*, 6CVS (2009-03-31) OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
10 + 7 = ?
Subscribe to this entry?

 [2009-03-20 19:24 UTC] etremblay at kronostechnologies dot com
This is a duplicate of bug #19280 which is closed.

I can reproduced it php 5.2.9.  
With 5.2.6, it worked well.

I see that imap address related code have been touched by bug #46918 (shown in 5.2.9 releasenotes)

Look like someone broke it when fixing some other issue.

Reproduce code:
Look in bug #19280

Expected result:
No segfault

Actual result:


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-03-23 12:14 UTC] etremblay at kronostechnologies dot com
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb757e700 (LWP 21722)]
0xb7e7fbb6 in memcpy () from /lib/tls/i686/cmov/
(gdb) bt
#0  0xb7e7fbb6 in memcpy () from /lib/tls/i686/cmov/
#1  0xbf877e84 in ?? ()
#2  0xb6c72d42 in ?? () from /usr/lib/
#3  0xb6c738b3 in rfc822_output_address () from /usr/lib/
#4  0xb6c73abd in rfc822_output_address_list () from /usr/lib/
#5  0xb6f9a0ea in _php_rfc822_write_address (addresslist=0xb8ccc6f8) at /opt/php-5.2.9/ext/imap/php_imap.c:3947
#6  0x0061632e in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
 [2009-03-23 12:16 UTC]
Which imap version do you use?
 [2009-03-23 12:22 UTC] etremblay at kronostechnologies dot com
libc-client2007b (ubuntu intrepid)
I try the current snapshot of php.  Post back in 2 minutes.
 [2009-03-31 07:55 UTC]
This explains the bug:

 [2009-03-31 11:49 UTC] etremblay at kronostechnologies dot com
If you look closely at, it say that the fixed api functions begin with rfc822_output_*.  

In the core dump, we see that the problem is in the function 
rfc822_output_address () from /usr/lib/

So, the actual problem is not the same.
 [2009-04-27 23:15 UTC]
We still use some of the risky APIs. Testing again before the commit.
 [2009-05-01 14:29 UTC]
This error is due to a too old cclient version, I should have saw it earlier (backtrace). Update the c-client to a more recent version (2007e for example).
 [2009-05-01 17:24 UTC] etremblay at kronostechnologies dot com
If so, why does it work with php 5.2.6 ? (And before, we are using this since 2005)

The only thing I can see, is that someone in PHP removed a workaround for a c-client bug int php 5.2.9??

c-client2007e doesn't seem to be widely distributed.  The only place I've seen it is in a ftp ( and it look like it's packaged with an imap server.  I don't like this solution.
 [2009-05-01 18:31 UTC] etremblay at kronostechnologies dot com
I still agree with what I said in the last message, but you are right, it works with imap2007e.
 [2009-05-01 18:39 UTC]
The old functions are even less safe and should be used. Most distributions have either updated to a decent version or have backported the fixes. If yours does not work I would suggest to report a bug there.

Not a php bug but a c-client one.

ps: yes, the c-client is part of the UW imap server but can be compiled alone.
 [2009-05-01 18:48 UTC] etremblay at kronostechnologies dot com
Now I understand.  With php 5.2.6 and less, the old c-client unsafe method where used.  Now the new ones are used but they are broken in old version of c-client.  That sound logical.

Thank you for your time.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Feb 26 19:01:29 2024 UTC