Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JIT Integer overflow ext/opcache/jit/ir/ir_fold.h #17430

Closed
YuanchengJiang opened this issue Jan 10, 2025 · 2 comments
Closed

JIT Integer overflow ext/opcache/jit/ir/ir_fold.h #17430

YuanchengJiang opened this issue Jan 10, 2025 · 2 comments

Comments

@YuanchengJiang
Copy link

Description

The following code:

<?php
function test(){
for($i = PHP_INT_MIN; $i < 2; $i++){
$a = @[3][$i];
}
}

Resulted in this output:

ext/opcache/jit/ir/ir_fold.h:472:2: runtime error: signed integer overflow: -9223372036854775808 * 16 cannot be represented in type 'long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ext/opcache/jit/ir/ir_fold.h:472:2

To reproduce:

-d "zend_extension=/home/phpfuzz/WorkSpace/flowfusion/php-src/modules/opcache.so" -d "opcache.enable_cli=1" -d "opcache.jit=1205"

PHP Version

nightly

Operating System

No response

@nielsdos
Copy link
Member

nielsdos commented Jan 10, 2025

This is caused by the folding of the index and zval size in the following codegen:

// JIT: _ret = &_ht->arPacked[h];
ref = ir_MUL_L(h, ir_CONST_LONG(sizeof(zval)));

However, this can't cause real problems because we check earlier that the index is in bounds.
If it were a constant instead of a zval, the JIT would know to not consider the packed case, avoiding the issue because this code path wouldn't be taken.

Anyway, the undefined behaviour needs to be fixed in the IR repository.
I'll take a look at how hard this would be.

nielsdos added a commit to nielsdos/ir that referenced this issue Jan 10, 2025
See php/php-src#17430

I changed the adds, subs, muls to use unsigned arithmetic because on
2-complement systems that's the same as signed arithmetic but without
potential UB warnings. This essentially makes the wrapping behaviour
defined. I only did this for 32 and 64 bit types because for 8 and 16
bit the operations will do integer promotion, avoiding the issue.

There is also `val.i64 < 0 && val.i64 - 1 < 0` that I changed.
This is because the second condition would be thrown away by the
compiler because `val.i64 < 0` and signed wrapping is undefined.
dstogov pushed a commit to dstogov/ir that referenced this issue Jan 14, 2025
See php/php-src#17430

I changed the adds, subs, muls to use unsigned arithmetic because on
2-complement systems that's the same as signed arithmetic but without
potential UB warnings. This essentially makes the wrapping behaviour
defined. I only did this for 32 and 64 bit types because for 8 and 16
bit the operations will do integer promotion, avoiding the issue.

There is also `val.i64 < 0 && val.i64 - 1 < 0` that I changed.
This is because the second condition would be thrown away by the
compiler because `val.i64 < 0` and signed wrapping is undefined.
dstogov pushed a commit to dstogov/ir that referenced this issue Jan 14, 2025
See php/php-src#17430

I changed the adds, subs, muls to use unsigned arithmetic because on
2-complement systems that's the same as signed arithmetic but without
potential UB warnings. This essentially makes the wrapping behaviour
defined. I only did this for 32 and 64 bit types because for 8 and 16
bit the operations will do integer promotion, avoiding the issue.

There is also `val.i64 < 0 && val.i64 - 1 < 0` that I changed.
This is because the second condition would be thrown away by the
compiler because `val.i64 < 0` and signed wrapping is undefined.
@nielsdos
Copy link
Member

This is now fixed in the IR repo and will soon make its way into PHP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants