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

Fix bug #40531 mb_substr optional parameters #13

Closed
wants to merge 3 commits into from
Closed

Fix bug #40531 mb_substr optional parameters #13

wants to merge 3 commits into from

Conversation

mytskine
Copy link

The fix is in 3 commits. First, I enable a test that was skipped. Then I add a small feature to zend_verify_arg_type(). The last commit modifies the 2 functions that were buggy, mb_substr() and mb_strcut(). The last commit message details the changes.

I based my work on the branch PHP-5.4, but maybe this fix should be applied to an older version.

François Gannaz added 3 commits March 20, 2012 11:41
zend_verify_arg_type() only accepted to verify arg types as classes,
arrays or objects. Now it accepts integers. This is necessary to
check wether an argument is an integer or null, which can't be done
at a higher level like zend_parse_parameters(...,"l").
To distinguish between null and 0 for an integer parameter,
we have to use the "z!" type instead of "l" in zend_parse_parameters().
So the type checks are now done in the prototype with
ZEND_ARG_TYPE_INFO().

The prototype is more strict than before. An non integer (or a string
that isn't purely numeric) will lead to a fatal error, whereas there was
previously a simple warning.
@nikic
Copy link
Member

nikic commented Mar 20, 2012

This seems like a rather strange way to fix the issue. Changing the Zend Engine should not be required. What would be the problem with fetching the value as z, then checking for IS_NULL and otherwise converting it to a long using convert_to_long?

@mytskine
Copy link
Author

I first did like you suggested. But then there is no parameter validation in
the function. I couldn't find any function that checks the parameter is an
integer without converting it to an int. So instead of duplicating code, I added
this type check to the Zend Engine.

This is my first look at PHP's code, so of course I may be completly wrong.

@mytskine
Copy link
Author

Le 2012-03-20, nikic
[email protected]
a écrit :

This seems like a rather strange way to fix the issue. Changing the Zend
Engine should not be required. What would be the problem with fetching the
value as z, then checking for IS_NULL and otherwise converting it to a
long using convert_to_long?


Reply to this email directly or view it on GitHub:
#13 (comment)

I've just seen that my second commit re-introduces something that was removed
by commit 0e24a7c on 2010-10-19 by D. Rethans:
"Strip out the typehint checks only".

It seems my proposed patch has just landed in the hot topic of scalar type
hinting. I do think my patch is simple and logical, and I can't see a simpler
solution. But I don't have enough background to understand the consequences it
would bare on type hinting in PHP.

@smalyshev
Copy link
Contributor

I don't think changes to how the engine handles arguments can be introduced without RFC and discussion.

@php-pulls
Copy link

Comment on behalf of johannes at php.net:

test (please ignore)

@ircmaxell
Copy link
Contributor

This actually has a direct impact on the scalar type hinting discussion as it actually implements the type-hints differently for the core functions which as-of-yet is not supported...

Why not just change the arg type in zend_parse_parameters to expect an int in that case (like every other core function)...?

Anthony

@cataphract
Copy link
Contributor

As you can't use the ! modifier with l, the solution is simply to call zend_get_parameters_ex or the like before.

For instance, I have this still uncommitted code for the intl extension:

U_CFUNC PHP_FUNCTION(intlcal_clear)
{
    zval    **args_a[2] = {0},
            ***args     = &args_a[0];
    long    field;
    int     variant;
    CALENDAR_METHOD_INIT_VARS;

    if (ZEND_NUM_ARGS() > (getThis() ? 1 : 2) ||
            zend_get_parameters_array_ex(getThis() ? 1 : 2, args) == FAILURE) {
        intl_error_set(NULL, U_ILLEGAL_ARGUMENT_ERROR,
            "intlcal_clear: too many arguments", 0 TSRMLS_CC);
        RETURN_FALSE;
    }
    if (!getThis()) {
        args++;
    }
    if (args[0] == NULL || Z_TYPE_PP(args[0]) == IS_NULL) {
        zval *dummy; /* we know it's null */
        if (zend_parse_method_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
                getThis(), "O|z", &object, Calendar_ce_ptr, &dummy) == FAILURE) {
            intl_error_set(NULL, U_ILLEGAL_ARGUMENT_ERROR,
                "intlcal_clear: bad arguments", 0 TSRMLS_CC);
            RETURN_FALSE;
        }
        variant = 0;
    } else if (zend_parse_method_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
            getThis(), "Ol", &object, Calendar_ce_ptr, &field) == FAILURE) {
        intl_error_set(NULL, U_ILLEGAL_ARGUMENT_ERROR,
            "intlcal_clear: bad arguments", 0 TSRMLS_CC);
        RETURN_FALSE;
    } else if (field < 0 || field >= UCAL_FIELD_COUNT) {
        intl_error_set(NULL, U_ILLEGAL_ARGUMENT_ERROR,
            "intlcal_clear: invalid field", 0 TSRMLS_CC);
        RETURN_FALSE;
    } else {
        variant = 1;
    }

@mytskine
Copy link
Author

A few comments about ctaphract's suggestion:

  • zend_get_parameters_ex() is not documented. Not on php.net, but neither
    in the code (except for a cryptic comment). The variant functions are the
    same (no doc, no comments).
  • It is declared as ZEND_API ZEND_ATTRIBUTE_DEPRECATED. Deprecated?
  • I don't understand how this function work, so I won't try to use it.
    It is almost never used in PHP-5.4, this lack of examples doesn't help.

More globally, here are my "naïve" thoughts:

  • I think it is strange that a php internal function can't declare that one of
    its arguments is integer or null.
  • If I understood well, the suggested solution is to parse every argument "by
    hand" in this case, including the error messages when validating each
    argument.
  • If I didn't misunderstand, this would lead to a heavy rewrite of the parsing
    of the arguments in the functions mb_substr() and mb_strcut(). It would
    add dozens of lines of tedious code.
  • I feel that it is wiser to wait for a way to define more completely the
    prototype of the functions (through zend_parse_parameters() or scalar type
    hinting or anything else). But I'm not qualified enough to defend my point of
    view.

Finally, I believe I should have posted in the internals list instead of
posting a pull request. I now understand the patch was too intrusive to be
applied, and a discussion was much needed, at least for me!

@php-pulls
Copy link

Hi!

  • I think it is strange that a php internal function can't declare that one of
    its arguments is integer or null.

I think it's because there never was a use case for it. You actually
stepped on a much bigger problem - how to omit optional arguments if
it's not the last one. Unfortunately, PHP does not provide proper
solution to it - and null is not a very good solution since it makes
substr() and mb_substr() work differently.
I plan to propose better solution soon but of course it won't happen for
5.4.

Right now I don't see a clean way to return null in 'l' field from
zend_parse_arg_impl(), so I'm afraid you'd have to deal with 'z' and do
your own parsing. If you really want it (see above).

  • I feel that it is wiser to wait for a way to define more completely the
    prototype of the functions (through zend_parse_parameters() or scalar type
    hinting or anything else). But I'm not qualified enough to defend my point of
    view.

zend_parse_parameters() does define type, but type "long or null" is not
expressible in its language right now. 'l' can not return null since it
accepts int* and thus returns int. We could have some type that returns
"is it null?" flag, but that would be very limited use case, I'm not
sure it's worth it.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

@mytskine mytskine closed this Mar 21, 2012
@mytskine
Copy link
Author

Thanks for this reply. I'm glad to know there are plans for a better way to deal with optional arguments.

I still think that the type checks for the arguments of internal functions are too limited. Maybe type checks shouldn't be added to zend_verify_arg_type() (please note it does not enable type-hinting for user functions, though the subject is connected). If not, I feel the API lacks a helper function to validate individual arguments. I've wandered a bit in the code of several extensions, and I've often seen a function call several times zend_parse_parameters() just because one of its arguments is "int or string". I don't like this kind of code (no offense intended, I reckon I lack experience on php-src, so my opinions have a very small background).

I'm closing this pull request. I may submit another one with my own parsing and validation and error messages for "long or null" arguments, but I'll probably wait for changes in the API that would avoid this. Thanks to everyone here for the valuable experience.

@cataphract
Copy link
Contributor

I meant zend_get_parameters_array_ex, not zend_get_parameters_ex, which is in fact deprecated (but otherwise operates in a similar fashion). You can also use first zend_parse_parameters with a Z* or z* to determine whether the argument is NULL and then call zend_parse_parameters again with the proper arguments. Only by using these methods will you be able to distinguish between 0 and NULL after the second (proper) call.

In any case, you won't need to add your own error messages or type validations. I should have stripped those from my example because the intl extension actually has its own error handling mechanism. The only exception is that you have to validate the number of arguments if you use zend_get_parameters_ex, otherwise you may overflow the array you pass. But this is not a problem if you use zpp with z* (though then you to be careful not to free the array obtained).

In the long term, adding a modifier similar to ! would be a better option. The problem with ! is that it only works with pointer types (and zend_fcall_info/cache). We need a modifier that allows the nullness to be specified on an adjacent argument passed to zpp, like this (using as an example ?):

long l;
zend_bool is_null = 1;
if (zend_parse_method_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
            getThis(), "O|l?", &object, Calendar_ce_ptr, &l, &is_null) == FAILURE) {

@smalyshev
Copy link
Contributor

I would rather do it differently - I'd allow to run parse on a single parameter, i.e. have initial parse with 'z' and then depending on some code have something like:

zend_parse_single_arg(my_arg, "l", &l)

So you could do your own checks and then still benefit from the clean API provided by parameter parser.

nikic pushed a commit to nikic/php-src that referenced this pull request Jan 5, 2013
a traditional property declaration.

Also added XFAIL sections to a few tests that are expected to fail for
now until other tickets are closed.

fixes php#13
thesource93 pushed a commit to thesource93/php-src that referenced this pull request Feb 27, 2019
shqking added a commit that referenced this pull request Apr 20, 2021
The following opcodes would be generated:

  ...
  BB1:
  0003 JMP BB3

  BB2:
  0004 INIT_FCALL 1 96 string("chr")
  0005 #10.T3 [long] = SR #3.CV0($int) [long] #7.CV2($i) ...
  0006 #11.T4 [long] RANGE[0..127] = BW_AND #10.T3 [long] ...
  0007 #12.T3 [long] RANGE[128..255] = BW_OR #11.T4 [long] ...
  0008 SEND_VAL #12.T3 [long] RANGE[128..255] 1
  0009 #13.V3 [ref, rc1, rcn, any] = DO_ICALL
  0010 ASSIGN_OP (CONCAT) #6.CV1($out) [rc1, rcn, string]
  0011 ADD #7.CV2($i)... int(7) #7.CV2($i) ... -> #15.CV2($i) ...

  BB3:
  0012 #8.T4 [long] = SR #3.CV0($int) #7.CV2($i) [long, double]
  0013 #9.T3 [bool] RANGE[0..1] = IS_SMALLER int(128) #8.T4
  0014 JMPNZ #9.T3 [bool] RANGE[0..1] BB2
  ...

Main changes are:
1. SR opcode covers new path in function zend_jit_long_math_helper().
2. BW_AND and BW_OR opcodes are supported. See macro LONG_OP.
3. Function zend_jit_concat_helper() is added to support ASSIGN_OP
opcode. Speficically, CONCAT and FAST_CONCAT is supported for statements
"$out .= ...".
4. New path is covered in function zend_jit_cmp_long_long() by
IS_SMALLER opcode.
5. New path is covered in macros ZVAL_PTR_DTOR and ZVAL_DTOR_FUNC when
leaving.
dstogov pushed a commit that referenced this pull request Apr 29, 2021
The following opcodes would be generated:

  ...
  BB1:
  0003 JMP BB3

  BB2:
  0004 INIT_FCALL 1 96 string("chr")
  0005 #10.T3 [long] = SR #3.CV0($int) [long] #7.CV2($i) ...
  0006 #11.T4 [long] RANGE[0..127] = BW_AND #10.T3 [long] ...
  0007 #12.T3 [long] RANGE[128..255] = BW_OR #11.T4 [long] ...
  0008 SEND_VAL #12.T3 [long] RANGE[128..255] 1
  0009 #13.V3 [ref, rc1, rcn, any] = DO_ICALL
  0010 ASSIGN_OP (CONCAT) #6.CV1($out) [rc1, rcn, string]
  0011 ADD #7.CV2($i)... int(7) #7.CV2($i) ... -> #15.CV2($i) ...

  BB3:
  0012 #8.T4 [long] = SR #3.CV0($int) #7.CV2($i) [long, double]
  0013 #9.T3 [bool] RANGE[0..1] = IS_SMALLER int(128) #8.T4
  0014 JMPNZ #9.T3 [bool] RANGE[0..1] BB2
  ...

Main changes are:
1. SR opcode covers new path in function zend_jit_long_math_helper().
2. BW_AND and BW_OR opcodes are supported. See macro LONG_OP.
3. Function zend_jit_concat_helper() is added to support ASSIGN_OP
opcode. Speficically, CONCAT and FAST_CONCAT is supported for statements
"$out .= ...".
4. New path is covered in function zend_jit_cmp_long_long() by
IS_SMALLER opcode.
5. New path is covered in macros ZVAL_PTR_DTOR and ZVAL_DTOR_FUNC when
leaving.
dstogov pushed a commit that referenced this pull request May 12, 2021
The following opcodes would be generated:

  ...
  BB1:
  0003 JMP BB3

  BB2:
  0004 INIT_FCALL 1 96 string("chr")
  0005 #10.T3 [long] = SR #3.CV0($int) [long] #7.CV2($i) ...
  0006 #11.T4 [long] RANGE[0..127] = BW_AND #10.T3 [long] ...
  0007 #12.T3 [long] RANGE[128..255] = BW_OR #11.T4 [long] ...
  0008 SEND_VAL #12.T3 [long] RANGE[128..255] 1
  0009 #13.V3 [ref, rc1, rcn, any] = DO_ICALL
  0010 ASSIGN_OP (CONCAT) #6.CV1($out) [rc1, rcn, string]
  0011 ADD #7.CV2($i)... int(7) #7.CV2($i) ... -> #15.CV2($i) ...

  BB3:
  0012 #8.T4 [long] = SR #3.CV0($int) #7.CV2($i) [long, double]
  0013 #9.T3 [bool] RANGE[0..1] = IS_SMALLER int(128) #8.T4
  0014 JMPNZ #9.T3 [bool] RANGE[0..1] BB2
  ...

Main changes are:
1. SR opcode covers new path in function zend_jit_long_math_helper().
2. BW_AND and BW_OR opcodes are supported. See macro LONG_OP.
3. Function zend_jit_concat_helper() is added to support ASSIGN_OP
opcode. Speficically, CONCAT and FAST_CONCAT is supported for statements
"$out .= ...".
4. New path is covered in function zend_jit_cmp_long_long() by
IS_SMALLER opcode.
5. New path is covered in macros ZVAL_PTR_DTOR and ZVAL_DTOR_FUNC when
leaving.
dstogov pushed a commit that referenced this pull request May 12, 2021
The following opcodes would be generated:

  ...
  BB1:
  0003 JMP BB3

  BB2:
  0004 INIT_FCALL 1 96 string("chr")
  0005 #10.T3 [long] = SR #3.CV0($int) [long] #7.CV2($i) ...
  0006 #11.T4 [long] RANGE[0..127] = BW_AND #10.T3 [long] ...
  0007 #12.T3 [long] RANGE[128..255] = BW_OR #11.T4 [long] ...
  0008 SEND_VAL #12.T3 [long] RANGE[128..255] 1
  0009 #13.V3 [ref, rc1, rcn, any] = DO_ICALL
  0010 ASSIGN_OP (CONCAT) #6.CV1($out) [rc1, rcn, string]
  0011 ADD #7.CV2($i)... int(7) #7.CV2($i) ... -> #15.CV2($i) ...

  BB3:
  0012 #8.T4 [long] = SR #3.CV0($int) #7.CV2($i) [long, double]
  0013 #9.T3 [bool] RANGE[0..1] = IS_SMALLER int(128) #8.T4
  0014 JMPNZ #9.T3 [bool] RANGE[0..1] BB2
  ...

Main changes are:
1. SR opcode covers new path in function zend_jit_long_math_helper().
2. BW_AND and BW_OR opcodes are supported. See macro LONG_OP.
3. Function zend_jit_concat_helper() is added to support ASSIGN_OP
opcode. Speficically, CONCAT and FAST_CONCAT is supported for statements
"$out .= ...".
4. New path is covered in function zend_jit_cmp_long_long() by
IS_SMALLER opcode.
5. New path is covered in macros ZVAL_PTR_DTOR and ZVAL_DTOR_FUNC when
leaving.
dstogov pushed a commit that referenced this pull request May 14, 2021
The following opcodes would be generated:

  ...
  BB1:
  0003 JMP BB3

  BB2:
  0004 INIT_FCALL 1 96 string("chr")
  0005 #10.T3 [long] = SR #3.CV0($int) [long] #7.CV2($i) ...
  0006 #11.T4 [long] RANGE[0..127] = BW_AND #10.T3 [long] ...
  0007 #12.T3 [long] RANGE[128..255] = BW_OR #11.T4 [long] ...
  0008 SEND_VAL #12.T3 [long] RANGE[128..255] 1
  0009 #13.V3 [ref, rc1, rcn, any] = DO_ICALL
  0010 ASSIGN_OP (CONCAT) #6.CV1($out) [rc1, rcn, string]
  0011 ADD #7.CV2($i)... int(7) #7.CV2($i) ... -> #15.CV2($i) ...

  BB3:
  0012 #8.T4 [long] = SR #3.CV0($int) #7.CV2($i) [long, double]
  0013 #9.T3 [bool] RANGE[0..1] = IS_SMALLER int(128) #8.T4
  0014 JMPNZ #9.T3 [bool] RANGE[0..1] BB2
  ...

Main changes are:
1. SR opcode covers new path in function zend_jit_long_math_helper().
2. BW_AND and BW_OR opcodes are supported. See macro LONG_OP.
3. Function zend_jit_concat_helper() is added to support ASSIGN_OP
opcode. Speficically, CONCAT and FAST_CONCAT is supported for statements
"$out .= ...".
4. New path is covered in function zend_jit_cmp_long_long() by
IS_SMALLER opcode.
5. New path is covered in macros ZVAL_PTR_DTOR and ZVAL_DTOR_FUNC when
leaving.
dstogov pushed a commit that referenced this pull request May 18, 2021
The following opcodes would be generated:

  ...
  BB1:
  0003 JMP BB3

  BB2:
  0004 INIT_FCALL 1 96 string("chr")
  0005 #10.T3 [long] = SR #3.CV0($int) [long] #7.CV2($i) ...
  0006 #11.T4 [long] RANGE[0..127] = BW_AND #10.T3 [long] ...
  0007 #12.T3 [long] RANGE[128..255] = BW_OR #11.T4 [long] ...
  0008 SEND_VAL #12.T3 [long] RANGE[128..255] 1
  0009 #13.V3 [ref, rc1, rcn, any] = DO_ICALL
  0010 ASSIGN_OP (CONCAT) #6.CV1($out) [rc1, rcn, string]
  0011 ADD #7.CV2($i)... int(7) #7.CV2($i) ... -> #15.CV2($i) ...

  BB3:
  0012 #8.T4 [long] = SR #3.CV0($int) #7.CV2($i) [long, double]
  0013 #9.T3 [bool] RANGE[0..1] = IS_SMALLER int(128) #8.T4
  0014 JMPNZ #9.T3 [bool] RANGE[0..1] BB2
  ...

Main changes are:
1. SR opcode covers new path in function zend_jit_long_math_helper().
2. BW_AND and BW_OR opcodes are supported. See macro LONG_OP.
3. Function zend_jit_concat_helper() is added to support ASSIGN_OP
opcode. Speficically, CONCAT and FAST_CONCAT is supported for statements
"$out .= ...".
4. New path is covered in function zend_jit_cmp_long_long() by
IS_SMALLER opcode.
5. New path is covered in macros ZVAL_PTR_DTOR and ZVAL_DTOR_FUNC when
leaving.
devnexen added a commit to devnexen/php-src that referenced this pull request Oct 12, 2024
even without sanitizers, it is reproducible but with the following

```
<?php
$g = gmp_init(256);
var_dump(gmp_pow($g, PHP_INT_MAX));
```

we get this

```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==286922==ERROR: AddressSanitizer: FPE on unknown address 0x03e8000460ca (pc 0x7faf6c69de5c bp 0x400000000000004 sp 0x7ffe9843c740 T0)
    #0 0x7faf6c69de5c in __pthread_kill_implementation nptl/pthread_kill.c:44
    #1 0x7faf6c649c81 in __GI_raise ../sysdeps/posix/raise.c:26
    php#2 0x7faf6db9386c in __gmp_exception (/lib/x86_64-linux-gnu/libgmp.so.10+0xd86c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#3 0x7faf6db938d3 in __gmp_overflow_in_mpz (/lib/x86_64-linux-gnu/libgmp.so.10+0xd8d3) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#4 0x7faf6dbac95c in __gmpz_realloc (/lib/x86_64-linux-gnu/libgmp.so.10+0x2695c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#5 0x7faf6dba9038 in __gmpz_n_pow_ui (/lib/x86_64-linux-gnu/libgmp.so.10+0x23038) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#6 0x5565ae1ccd9f in zif_gmp_pow /home/dcarlier/Contribs/php-src/ext/gmp/gmp.c:1286
    php#7 0x5565aee96ea9 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:1312
    php#8 0x5565af144320 in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:56075
    php#9 0x5565af160f07 in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:60439
    php#10 0x5565aed6fafe in zend_execute_scripts /home/dcarlier/Contribs/php-src/Zend/zend.c:1842
    php#11 0x5565aeae70a8 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2578
    php#12 0x5565af532f4e in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:964
    php#13 0x5565af535877 in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1334
    php#14 0x7faf6c633d67 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    php#15 0x7faf6c633e24 in __libc_start_main_impl ../csu/libc-start.c:360
    php#16 0x5565adc04040 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x2604040) (BuildId: 949049955bdf8b7197390b1978a1dfc3ef6fdf38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE nptl/pthread_kill.c:44 in __pthread_kill_implementation
==286922==ABORTING
```
devnexen added a commit that referenced this pull request Oct 13, 2024
even without sanitizers, it is reproducible but with the following

```
<?php
$g = gmp_init(256);
var_dump(gmp_pow($g, PHP_INT_MAX));
```

we get this

```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==286922==ERROR: AddressSanitizer: FPE on unknown address 0x03e8000460ca (pc 0x7faf6c69de5c bp 0x400000000000004 sp 0x7ffe9843c740 T0)
    #0 0x7faf6c69de5c in __pthread_kill_implementation nptl/pthread_kill.c:44
    #1 0x7faf6c649c81 in __GI_raise ../sysdeps/posix/raise.c:26
    #2 0x7faf6db9386c in __gmp_exception (/lib/x86_64-linux-gnu/libgmp.so.10+0xd86c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    #3 0x7faf6db938d3 in __gmp_overflow_in_mpz (/lib/x86_64-linux-gnu/libgmp.so.10+0xd8d3) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    #4 0x7faf6dbac95c in __gmpz_realloc (/lib/x86_64-linux-gnu/libgmp.so.10+0x2695c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    #5 0x7faf6dba9038 in __gmpz_n_pow_ui (/lib/x86_64-linux-gnu/libgmp.so.10+0x23038) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    #6 0x5565ae1ccd9f in zif_gmp_pow /home/dcarlier/Contribs/php-src/ext/gmp/gmp.c:1286
    #7 0x5565aee96ea9 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:1312
    #8 0x5565af144320 in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:56075
    #9 0x5565af160f07 in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:60439
    #10 0x5565aed6fafe in zend_execute_scripts /home/dcarlier/Contribs/php-src/Zend/zend.c:1842
    #11 0x5565aeae70a8 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2578
    #12 0x5565af532f4e in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:964
    #13 0x5565af535877 in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1334
    #14 0x7faf6c633d67 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #15 0x7faf6c633e24 in __libc_start_main_impl ../csu/libc-start.c:360
    #16 0x5565adc04040 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x2604040) (BuildId: 949049955bdf8b7197390b1978a1dfc3ef6fdf38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE nptl/pthread_kill.c:44 in __pthread_kill_implementation
==286922==ABORTING
```
devnexen added a commit to devnexen/php-src that referenced this pull request Oct 17, 2024
even without sanitizers, it is reproducible but with the following

```
<?php
$g = gmp_init(256);
var_dump(gmp_pow($g, PHP_INT_MAX));
```

we get this

```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==286922==ERROR: AddressSanitizer: FPE on unknown address 0x03e8000460ca (pc 0x7faf6c69de5c bp 0x400000000000004 sp 0x7ffe9843c740 T0)
    #0 0x7faf6c69de5c in __pthread_kill_implementation nptl/pthread_kill.c:44
    #1 0x7faf6c649c81 in __GI_raise ../sysdeps/posix/raise.c:26
    php#2 0x7faf6db9386c in __gmp_exception (/lib/x86_64-linux-gnu/libgmp.so.10+0xd86c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#3 0x7faf6db938d3 in __gmp_overflow_in_mpz (/lib/x86_64-linux-gnu/libgmp.so.10+0xd8d3) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#4 0x7faf6dbac95c in __gmpz_realloc (/lib/x86_64-linux-gnu/libgmp.so.10+0x2695c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#5 0x7faf6dba9038 in __gmpz_n_pow_ui (/lib/x86_64-linux-gnu/libgmp.so.10+0x23038) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#6 0x5565ae1ccd9f in zif_gmp_pow /home/dcarlier/Contribs/php-src/ext/gmp/gmp.c:1286
    php#7 0x5565aee96ea9 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:1312
    php#8 0x5565af144320 in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:56075
    php#9 0x5565af160f07 in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:60439
    php#10 0x5565aed6fafe in zend_execute_scripts /home/dcarlier/Contribs/php-src/Zend/zend.c:1842
    php#11 0x5565aeae70a8 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2578
    php#12 0x5565af532f4e in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:964
    php#13 0x5565af535877 in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1334
    php#14 0x7faf6c633d67 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    php#15 0x7faf6c633e24 in __libc_start_main_impl ../csu/libc-start.c:360
    php#16 0x5565adc04040 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x2604040) (BuildId: 949049955bdf8b7197390b1978a1dfc3ef6fdf38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE nptl/pthread_kill.c:44 in __pthread_kill_implementation
==286922==ABORTING
```
devnexen added a commit to devnexen/php-src that referenced this pull request Oct 21, 2024
even without sanitizers, it is reproducible but with the following

```
<?php
$g = gmp_init(256);
var_dump(gmp_pow($g, PHP_INT_MAX));
```

we get this

```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==286922==ERROR: AddressSanitizer: FPE on unknown address 0x03e8000460ca (pc 0x7faf6c69de5c bp 0x400000000000004 sp 0x7ffe9843c740 T0)
    #0 0x7faf6c69de5c in __pthread_kill_implementation nptl/pthread_kill.c:44
    #1 0x7faf6c649c81 in __GI_raise ../sysdeps/posix/raise.c:26
    php#2 0x7faf6db9386c in __gmp_exception (/lib/x86_64-linux-gnu/libgmp.so.10+0xd86c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#3 0x7faf6db938d3 in __gmp_overflow_in_mpz (/lib/x86_64-linux-gnu/libgmp.so.10+0xd8d3) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#4 0x7faf6dbac95c in __gmpz_realloc (/lib/x86_64-linux-gnu/libgmp.so.10+0x2695c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#5 0x7faf6dba9038 in __gmpz_n_pow_ui (/lib/x86_64-linux-gnu/libgmp.so.10+0x23038) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#6 0x5565ae1ccd9f in zif_gmp_pow /home/dcarlier/Contribs/php-src/ext/gmp/gmp.c:1286
    php#7 0x5565aee96ea9 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:1312
    php#8 0x5565af144320 in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:56075
    php#9 0x5565af160f07 in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:60439
    php#10 0x5565aed6fafe in zend_execute_scripts /home/dcarlier/Contribs/php-src/Zend/zend.c:1842
    php#11 0x5565aeae70a8 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2578
    php#12 0x5565af532f4e in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:964
    php#13 0x5565af535877 in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1334
    php#14 0x7faf6c633d67 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    php#15 0x7faf6c633e24 in __libc_start_main_impl ../csu/libc-start.c:360
    php#16 0x5565adc04040 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x2604040) (BuildId: 949049955bdf8b7197390b1978a1dfc3ef6fdf38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE nptl/pthread_kill.c:44 in __pthread_kill_implementation
==286922==ABORTING
```
devnexen added a commit to devnexen/php-src that referenced this pull request Oct 24, 2024
even without sanitizers, it is reproducible but with the following

```
<?php
$g = gmp_init(256);
var_dump(gmp_pow($g, PHP_INT_MAX));
```

we get this

```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==286922==ERROR: AddressSanitizer: FPE on unknown address 0x03e8000460ca (pc 0x7faf6c69de5c bp 0x400000000000004 sp 0x7ffe9843c740 T0)
    #0 0x7faf6c69de5c in __pthread_kill_implementation nptl/pthread_kill.c:44
    #1 0x7faf6c649c81 in __GI_raise ../sysdeps/posix/raise.c:26
    php#2 0x7faf6db9386c in __gmp_exception (/lib/x86_64-linux-gnu/libgmp.so.10+0xd86c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#3 0x7faf6db938d3 in __gmp_overflow_in_mpz (/lib/x86_64-linux-gnu/libgmp.so.10+0xd8d3) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#4 0x7faf6dbac95c in __gmpz_realloc (/lib/x86_64-linux-gnu/libgmp.so.10+0x2695c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#5 0x7faf6dba9038 in __gmpz_n_pow_ui (/lib/x86_64-linux-gnu/libgmp.so.10+0x23038) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    php#6 0x5565ae1ccd9f in zif_gmp_pow /home/dcarlier/Contribs/php-src/ext/gmp/gmp.c:1286
    php#7 0x5565aee96ea9 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:1312
    php#8 0x5565af144320 in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:56075
    php#9 0x5565af160f07 in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:60439
    php#10 0x5565aed6fafe in zend_execute_scripts /home/dcarlier/Contribs/php-src/Zend/zend.c:1842
    php#11 0x5565aeae70a8 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2578
    php#12 0x5565af532f4e in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:964
    php#13 0x5565af535877 in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1334
    php#14 0x7faf6c633d67 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    php#15 0x7faf6c633e24 in __libc_start_main_impl ../csu/libc-start.c:360
    php#16 0x5565adc04040 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x2604040) (BuildId: 949049955bdf8b7197390b1978a1dfc3ef6fdf38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE nptl/pthread_kill.c:44 in __pthread_kill_implementation
==286922==ABORTING
```
devnexen added a commit that referenced this pull request Oct 25, 2024
even without sanitizers, it is reproducible but with the following

```
<?php
$g = gmp_init(256);
var_dump(gmp_pow($g, PHP_INT_MAX));
```

we get this

```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==286922==ERROR: AddressSanitizer: FPE on unknown address 0x03e8000460ca (pc 0x7faf6c69de5c bp 0x400000000000004 sp 0x7ffe9843c740 T0)
    #0 0x7faf6c69de5c in __pthread_kill_implementation nptl/pthread_kill.c:44
    #1 0x7faf6c649c81 in __GI_raise ../sysdeps/posix/raise.c:26
    #2 0x7faf6db9386c in __gmp_exception (/lib/x86_64-linux-gnu/libgmp.so.10+0xd86c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    #3 0x7faf6db938d3 in __gmp_overflow_in_mpz (/lib/x86_64-linux-gnu/libgmp.so.10+0xd8d3) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    #4 0x7faf6dbac95c in __gmpz_realloc (/lib/x86_64-linux-gnu/libgmp.so.10+0x2695c) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    #5 0x7faf6dba9038 in __gmpz_n_pow_ui (/lib/x86_64-linux-gnu/libgmp.so.10+0x23038) (BuildId: 1af68a49fe041a5bb48a2915c3d47541f713bb38)
    #6 0x5565ae1ccd9f in zif_gmp_pow /home/dcarlier/Contribs/php-src/ext/gmp/gmp.c:1286
    #7 0x5565aee96ea9 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:1312
    #8 0x5565af144320 in execute_ex /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:56075
    #9 0x5565af160f07 in zend_execute /home/dcarlier/Contribs/php-src/Zend/zend_vm_execute.h:60439
    #10 0x5565aed6fafe in zend_execute_scripts /home/dcarlier/Contribs/php-src/Zend/zend.c:1842
    #11 0x5565aeae70a8 in php_execute_script /home/dcarlier/Contribs/php-src/main/main.c:2578
    #12 0x5565af532f4e in do_cli /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:964
    #13 0x5565af535877 in main /home/dcarlier/Contribs/php-src/sapi/cli/php_cli.c:1334
    #14 0x7faf6c633d67 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #15 0x7faf6c633e24 in __libc_start_main_impl ../csu/libc-start.c:360
    #16 0x5565adc04040 in _start (/home/dcarlier/Contribs/php-src/sapi/cli/php+0x2604040) (BuildId: 949049955bdf8b7197390b1978a1dfc3ef6fdf38)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE nptl/pthread_kill.c:44 in __pthread_kill_implementation
==286922==ABORTING
```

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

Successfully merging this pull request may close these issues.

6 participants