php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77447 PHP 7.3 built with ASAN crashes in zend_cpu_supports_avx2
Submitted: 2019-01-11 14:59 UTC Modified: 2019-01-19 09:31 UTC
From: hanno at hboeck dot de Assigned: nikic (profile)
Status: Closed Package: Reproducible crash
PHP Version: 7.3.1 OS: 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: hanno at hboeck dot de
New email:
PHP Version: OS:

 

 [2019-01-11 14:59 UTC] hanno at hboeck dot de
Description:
------------
I'm unable to get PHP 7.3 to run with address sanitizer.

Reproduce:
./configure CFLAGS="-fsanitize=address -g" CXXFLAGS="-fsanitize=address -g" LDFLAGS="-fsanitize=address" --enable-debug
make

./sapi/cli/php
leads to a segfault.

This problem does not happen with 7.2.x.
Address Sanitizer has been an extremely helpful tool to identify memory corruption bugs and security issues in PHP, therefore this is concerning, as it might hamper the ability of security researchers to find bugs in PHP.

A stack trace from GDB shows this happens in the function zend_cpu_supports_avx2(). AVX2 support is not available in PHP 7.2, therefore I believe this explains the difference between 7.2 and 7.3.

Expected result:
----------------
No segfault with ASAN.

Actual result:
--------------
Segfault with ASAN.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-01-14 09:56 UTC] nikic@php.net
-Status: Open +Status: Verified
 [2019-01-14 09:56 UTC] nikic@php.net
Confirming the segfault. Had to add LIBS="-ldl" to avoid linker errors.
 [2019-01-14 10:24 UTC] nikic@php.net
0x555555c21f56 <zend_cpu_supports_sse42+4>      callq  0x555555832560 <__cpu_indicator_init>
0x555555c21f5b <zend_cpu_supports_sse42+9>      lea    0xb6971e(%rip),%rax
0x555555c21f62 <zend_cpu_supports_sse42+16>     lea    0xc(%rax),%rax
0x555555c21f66 <zend_cpu_supports_sse42+20>     mov    %rax,%rdx
0x555555c21f69 <zend_cpu_supports_sse42+23>     shr    $0x3,%rdx
0x555555c21f6d <zend_cpu_supports_sse42+27>     add    $0x7fff8000,%rdx
> 0x555555c21f74 <zend_cpu_supports_sse42+34>     movzbl (%rdx),%edx

(gdb) p &__cpu_model
$8 = (<data variable, no debug info> *) 0x55555678b680 <__cpu_model>
(gdb) p/x $rax
$9 = 0x55555678b68c
(gdb) p/x $rdx
$10 = 0xaab2ace96d1

From what I gathered (addr>>3)+0x7fff8000 is the shadow address used by asan, and apparently it is not mapped.
 [2019-01-14 10:31 UTC] nikic@php.net
Looks like asan being incompatible with ifunc resolvers is a longstanding problem: https://github.com/google/sanitizers/issues/342

We might be able to work around it with some __attribute__((no_sanitize_address)) attributes.
 [2019-01-14 10:45 UTC] nikic@php.net
Automatic comment on behalf of nikita.ppv@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=c8c5a3ab8afdaa4692784a54a678cc565ecd1834
Log: Fixed bug #77447
 [2019-01-14 10:45 UTC] nikic@php.net
-Status: Verified +Status: Closed
 [2019-01-16 11:56 UTC] hanno at hboeck dot de
I tried patching 7.3.1 with that commit and it still crashes for me, so I don't believe this is fixed.
 [2019-01-16 15:33 UTC] nikic@php.net
-Assigned To: +Assigned To: nikic
 [2019-01-16 15:33 UTC] nikic@php.net
Did you do a full rebuild after applying the change? The header change will not be picked up in an incremental build.
 [2019-01-16 17:54 UTC] hanno at hboeck dot de
I did, it was a completely fresh build.

Is it possible it's using the headers from the system-wide installed version instead of from the source code?
 [2019-01-18 12:11 UTC] nikic@php.net
Could you please provide a stacktrace for the segfault? I'm wondering which codepath is calling cpu_supports() in your case.

Just to check, you are using gcc, and you are compiling with --enable-debug?
 [2019-01-18 12:58 UTC] hanno at hboeck dot de
The "--enable-debug" was the issue. With it no segfault, without I still get a segfault.

Is this intentional? (I don't think this is good: It will mean people will end up seeing segfaults e.g. if they want to fuzz, where people don't want to enable debugging, because they want max speed.)
 [2019-01-18 13:06 UTC] nikic@php.net
No, it's not intentional. I only marked the cpu_supports functions as no_sanitize_address, but with optimization they're probably inlined and the attribute is lost. We'll probably need the attributes also on the ifuncs themselves.
 [2019-01-19 09:32 UTC] hanno at hboeck dot de
Thanks, with both commits applied no more segfaults!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC