Most of functions for GNU Mp related have the same problem.

Take this function （gmp_scan0) as an example
test script
<?php
ini_set('memory_limit',-1);
$a=str_repeat("1",0xffffffff);
gmp_scan0($a,0xffffffff);
--------------------------------------------------------
crash information：
root@mhn:~# /usr/local/php/bin/php test.php 
GNU MP: Cannot allocate memory (size=4294967312)
Aborted (core dumped)
--------------------------------------------------------
root@mhn:~# gdb -q --args ./php-7.1.3/sapi/cli/php -n test.php
Reading symbols from ./php-7.1.3/sapi/cli/php...done.
(gdb) r
Starting program: /root/php-7.1.3/sapi/cli/php -n test.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
GNU MP: Cannot allocate memory (size=4294967312)

Program received signal SIGABRT, Aborted.
0x00007ffff5720c37 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff5720c37 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff5724028 in __GI_abort () at abort.c:89
#2  0x00007ffff75072a5 in __gmp_default_allocate ()
   from /usr/lib/x86_64-linux-gnu/libgmp.so.10
#3  0x00007ffff7507b89 in __gmp_tmp_reentrant_alloc ()
   from /usr/lib/x86_64-linux-gnu/libgmp.so.10
#4  0x00007ffff751d76f in __gmpz_set_str () from /usr/lib/x86_64-linux-gnu/libgmp.so.10
#5  0x00000000005e9ada in convert_to_gmp (gmpnumber=0x7fffffffad70, 
    val=<optimized out>, base=<optimized out>) at /root/php-7.1.3/ext/gmp/gmp.c:738
#6  0x00000000005ea4c8 in zif_gmp_scan0 (execute_data=<optimized out>, 
    return_value=0x7fffffffadc0) at /root/php-7.1.3/ext/gmp/gmp.c:2050
#7  0x00000000008bd1bd in ZEND_DO_ICALL_SPEC_RETVAL_UNUSED_HANDLER ()
    at /root/php-7.1.3/Zend/zend_vm_execute.h:628
#8  0x00000000008abe73 in execute_ex (ex=<optimized out>)
    at /root/php-7.1.3/Zend/zend_vm_execute.h:429
#9  0x0000000000907edb in zend_execute (op_array=<optimized out>, 
    return_value=<optimized out>) at /root/php-7.1.3/Zend/zend_vm_execute.h:474
#10 0x0000000000861d47 in zend_execute_scripts (type=type@entry=8, 
    retval=retval@entry=0x0, file_count=file_count@entry=3)
    at /root/php-7.1.3/Zend/zend.c:1476
#11 0x00000000007f2010 in php_execute_script (
    primary_file=primary_file@entry=0x7fffffffd290) at /root/php-7.1.3/main/main.c:2537
#12 0x000000000090a355 in do_cli (argc=3, argv=0x11f8a30)
    at /root/php-7.1.3/sapi/cli/php_cli.c:993
#13 0x0000000000440d3a in main (argc=3, argv=0x11f8a30)
---Type <return> to continue, or q <return> to quit---
    at /root/php-7.1.3/sapi/cli/php_cli.c:1381

Is there anyone dealing with the problem?

I don't think we're going to fix OOM issues in GMP. It is not possible for us to replace the GMP allocator functions due to conflicts with other libraries using GMP (we used to do this, it does not work robustly).

There is no security issue here, because GMP safely aborts in case of an OOM condition. The only attack vector here is denial of service. However, if you allow attacker-controlled, unbounded allocations you have a DOS vector regardless of GMPs OOM behavior.

I venture to ask who should deal with the problem.

Fixing OOM issues for GMP is essentially a “wouldn't it be nice” thing. Unless and until GMP is baked into the core language as a data type, rather than an optional extension, it's probably not going to be fixed.