Skip to content

Avoid crash for reset/end/next/prev() on ffi classes #9716

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

Closed
wants to merge 2 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion ext/ffi/ffi.c
Original file line number Diff line number Diff line change
Expand Up @@ -188,6 +188,10 @@ typedef struct _zend_ffi_ctype {
zend_ffi_type *type;
} zend_ffi_ctype;

/* This is a "mutable" copy of zend_empty_array that prevents asserts in attempts of iteration
* (see https://github.com/php/php-src/issues/9697) */
static HashTable _empty_array;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about ZTS builds? Technically, having multiple parallel threads calling reset() would be writing to this static array simultaneously.

That'd probably be writing the exact same value concurrently if multiple threads concurrently called reset(), which would be safe on most architectures, but may be unsafe in obscure architectures.

A bigger issue would be whether bugs in opcache, PECLs, the engine, or internal functions could actually write properties to this empty array - those would affect not only the given request, but all subsequent requests.

Doing something like ext/session and putting this in the request globals in rinit would limit the effect of bugs

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. You are right. Lets commit your solution.

Also, what's the motivation/context for overriding get_properties - if it's just reducing memory for typical workloads, it should be safe to override get_properties_for (which would keep memory low after var_export/debug_zval_dump/var_dump/json_encode)
Is there anything about FFI specifically that is a reason to avoid populating obj->properties

I think, FFI was developed before get_properties_for was added.
obj->properties for FFI objects just don't make sense.
If you like, you may refactor ext/ffi to use `get_properties_for``


static zend_class_entry *zend_ffi_exception_ce;
static zend_class_entry *zend_ffi_parser_exception_ce;
static zend_class_entry *zend_ffi_ce;
Expand Down Expand Up @@ -4699,7 +4703,7 @@ static ZEND_COLD zend_function *zend_fake_get_method(zend_object **obj_ptr, zend

static HashTable *zend_fake_get_properties(zend_object *obj) /* {{{ */
{
return (HashTable*)&zend_empty_array;
return &_empty_array;
}
/* }}} */

Expand Down Expand Up @@ -4935,6 +4939,10 @@ ZEND_MINIT_FUNCTION(ffi)

REGISTER_INI_ENTRIES();

memcpy(&_empty_array, &zend_empty_array, sizeof(HashTable));
GC_SET_REFCOUNT(&_empty_array, 1);
GC_TYPE_INFO(&_empty_array) = GC_ARRAY;

FFI_G(is_cli) = strcmp(sapi_module.name, "cli") == 0;

INIT_NS_CLASS_ENTRY(ce, "FFI", "Exception", NULL);
Expand Down
20 changes: 20 additions & 0 deletions ext/ffi/tests/gh9697-2.phpt
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
--TEST--
FFI: Test deprecated use of array helper functions on FFI classes doesn't crash
--SKIPIF--
<?php require_once('skipif.inc'); ?>
--INI--
ffi.enable=1
--FILE--
<?php
error_reporting(E_ALL & ~E_DEPRECATED);
$data = FFI::new('int');
var_dump(reset($data));
var_dump(end($data));
var_dump(next($data));
var_dump(prev($data));
?>
--EXPECTF--
bool(false)
bool(false)
bool(false)
bool(false)