php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #52049 crash when verifying gnupg signature
Submitted: 2010-06-11 14:11 UTC Modified: 2010-06-12 18:51 UTC
From: viktors at ok dot lv Assigned:
Status: Not a bug Package: Unknown/Other Function
PHP Version: 5.3.2 OS: ubuntu linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: viktors at ok dot lv
New email:
PHP Version: OS:

 

 [2010-06-11 14:11 UTC] viktors at ok dot lv
Description:
------------
Ubuntu 10.04 amd64. 100% reproducable on version 5.3.2-1ubuntu4.2 and 5.2.10.dfsg.1-2ubuntu6.4.
On version 5.2.6.dfsg.1-3ubuntu4.5 works fine!

GnuPG extension installed with "pecl install gnupg".

Key import works fine, but signature verification on valid pgp file crashes php.
Any ideas how to further debug and find out whats the reason for crash?

Thank you!

# cat cc.php
<?php
    $gpg = new gnupg();
    $plaintext = '';
    $gpg->verify(file_get_contents('valid.gpg'), false, $plaintext);
?>


# gdb php5
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/php5...Reading symbols from /usr/lib/debug/usr/bin/php5...done.
done.
(gdb) run cc.php 
Starting program: /usr/bin/php5 cc.php
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff129e710 (LWP 15940)]
[Thread 0x7ffff129e710 (LWP 15940) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00000000006e5f47 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff00000000) at /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:371
371	/build/buildd/php5-5.3.2/Zend/zend_vm_execute.h: No such file or directory.
	in /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h
(gdb) bt
#0  0x00000000006e5f47 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fff00000000) at /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:371
#1  0x00000000006bd400 in execute (op_array=0xfc75b0) at /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:104
#2  0x000000000069512d in zend_execute_scripts (type=0, retval=0x7fffffffc450, file_count=3) at /build/buildd/php5-5.3.2/Zend/zend.c:1266
#3  0x0000000000640d98 in php_execute_script (primary_file=0x2e36302e30312c30) at /build/buildd/php5-5.3.2/main/main.c:2288
#4  0x0000000000726236 in main (argc=0, argv=0x1) at /build/buildd/php5-5.3.2/sapi/cli/php_cli.c:1196
(gdb) 


# valgrind php5 cc.php
==16252== Memcheck, a memory error detector
==16252== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==16252== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==16252== Command: php5 cc.php
==16252== 
==16257== 
==16257== HEAP SUMMARY:
==16257==     in use at exit: 3,052,371 bytes in 18,450 blocks
==16257==   total heap usage: 19,824 allocs, 1,374 frees, 3,507,304 bytes allocated
==16257== 
==16257== LEAK SUMMARY:
==16257==    definitely lost: 0 bytes in 0 blocks
==16257==    indirectly lost: 0 bytes in 0 blocks
==16257==      possibly lost: 262,144 bytes in 1 blocks
==16257==    still reachable: 2,790,227 bytes in 18,449 blocks
==16257==         suppressed: 0 bytes in 0 blocks
==16257== Rerun with --leak-check=full to see details of leaked memory
==16257== 
==16257== For counts of detected and suppressed errors, rerun with: -v
==16257== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 10)
==16259== 
==16259== HEAP SUMMARY:
==16259==     in use at exit: 3,052,441 bytes in 18,453 blocks
==16259==   total heap usage: 19,827 allocs, 1,374 frees, 3,507,374 bytes allocated
==16259== 
==16259== LEAK SUMMARY:
==16259==    definitely lost: 0 bytes in 0 blocks
==16259==    indirectly lost: 0 bytes in 0 blocks
==16259==      possibly lost: 262,144 bytes in 1 blocks
==16259==    still reachable: 2,790,297 bytes in 18,452 blocks
==16259==         suppressed: 0 bytes in 0 blocks
==16259== Rerun with --leak-check=full to see details of leaked memory
==16259== 
==16259== For counts of detected and suppressed errors, rerun with: -v
==16259== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 10)
==16261== 
==16261== HEAP SUMMARY:
==16261==     in use at exit: 3,052,513 bytes in 18,456 blocks
==16261==   total heap usage: 19,830 allocs, 1,374 frees, 3,507,446 bytes allocated
==16261== 
==16261== LEAK SUMMARY:
==16261==    definitely lost: 0 bytes in 0 blocks
==16261==    indirectly lost: 0 bytes in 0 blocks
==16261==      possibly lost: 262,144 bytes in 1 blocks
==16261==    still reachable: 2,790,369 bytes in 18,455 blocks
==16261==         suppressed: 0 bytes in 0 blocks
==16261== Rerun with --leak-check=full to see details of leaked memory
==16261== 
==16261== For counts of detected and suppressed errors, rerun with: -v
==16261== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 10)
==16263== 
==16263== HEAP SUMMARY:
==16263==     in use at exit: 3,052,520 bytes in 18,457 blocks
==16263==   total heap usage: 19,831 allocs, 1,374 frees, 3,507,453 bytes allocated
==16263== 
==16263== LEAK SUMMARY:
==16263==    definitely lost: 0 bytes in 0 blocks
==16263==    indirectly lost: 0 bytes in 0 blocks
==16263==      possibly lost: 262,144 bytes in 1 blocks
==16263==    still reachable: 2,790,376 bytes in 18,456 blocks
==16263==         suppressed: 0 bytes in 0 blocks
==16263== Rerun with --leak-check=full to see details of leaked memory
==16263== 
==16263== For counts of detected and suppressed errors, rerun with: -v
==16263== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 10)
==16265== 
==16265== HEAP SUMMARY:
==16265==     in use at exit: 3,064,159 bytes in 18,520 blocks
==16265==   total heap usage: 19,897 allocs, 1,377 frees, 3,519,112 bytes allocated
==16265== 
==16265== LEAK SUMMARY:
==16265==    definitely lost: 0 bytes in 0 blocks
==16265==    indirectly lost: 0 bytes in 0 blocks
==16265==      possibly lost: 262,144 bytes in 1 blocks
==16265==    still reachable: 2,802,015 bytes in 18,519 blocks
==16265==         suppressed: 0 bytes in 0 blocks
==16265== Rerun with --leak-check=full to see details of leaked memory
==16265== 
==16265== For counts of detected and suppressed errors, rerun with: -v
==16265== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 10)
==16252== Invalid read of size 8
==16252==    at 0x6E5F47: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==16252==    by 0x6BD3FF: execute (in /usr/bin/php5)
==16252==    by 0x69512C: zend_execute_scripts (in /usr/bin/php5)
==16252==    by 0x640D97: php_execute_script (in /usr/bin/php5)
==16252==    by 0x726235: main (in /usr/bin/php5)
==16252==  Address 0x38 is not stack'd, malloc'd or (recently) free'd
==16252== 
==16252== 
==16252== Process terminating with default action of signal 11 (SIGSEGV)
==16252==  Access not within mapped region at address 0x38
==16252==    at 0x6E5F47: zend_do_fcall_common_helper_SPEC (in /usr/bin/php5)
==16252==    by 0x6BD3FF: execute (in /usr/bin/php5)
==16252==    by 0x69512C: zend_execute_scripts (in /usr/bin/php5)
==16252==    by 0x640D97: php_execute_script (in /usr/bin/php5)
==16252==    by 0x726235: main (in /usr/bin/php5)
==16252==  If you believe this happened as a result of a stack
==16252==  overflow in your program's main thread (unlikely but
==16252==  possible), you can try to increase the size of the
==16252==  main thread stack using the --main-stacksize= flag.
==16252==  The main thread stack size used in this run was 8388608.
==16252== 
==16252== HEAP SUMMARY:
==16252==     in use at exit: 3,056,132 bytes in 18,521 blocks
==16252==   total heap usage: 19,913 allocs, 1,392 frees, 3,646,646 bytes allocated
==16252== 
==16252== LEAK SUMMARY:
==16252==    definitely lost: 0 bytes in 0 blocks
==16252==    indirectly lost: 0 bytes in 0 blocks
==16252==      possibly lost: 265,761 bytes in 59 blocks
==16252==    still reachable: 2,790,371 bytes in 18,462 blocks
==16252==         suppressed: 0 bytes in 0 blocks
==16252== Rerun with --leak-check=full to see details of leaked memory
==16252== 
==16252== For counts of detected and suppressed errors, rerun with: -v
==16252== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 23 from 10)
Segmentation fault


Test script:
---------------
<?php
$gpg = new gnupg();
$plaintext = '';
$gpg->verify(file_get_contents('valid.gpg'), false, $plaintext);
?>


Actual result:
--------------
Segmentation fault.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-06-12 18:45 UTC] pajoye@php.net
-Status: Open +Status: Bogus
 [2010-06-12 18:45 UTC] pajoye@php.net
Please report Gnupg bugs to the pecl bugs report (http://pecl.php.net/gnupg)
 [2010-06-12 18:51 UTC] viktors at ok dot lv
Is this really a gnupg extensions bug not php?

1) GnuPG pecl extension hasn't changed for years, all that changed is PHP.
2) If the bug is in extension why does PHP segfaults in cryptic zend_do_fcall_common_helper_SPEC()?

Is there a way to track down bug to get more hints whats the reason for it?

Thank you!
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Wed May 07 17:01:30 2025 UTC