Skip to content

Fix GH-14643 ext/standard: segfault on user shutdown function release. #14656

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

Merged
merged 4 commits into from
Jun 25, 2024

Conversation

devnexen
Copy link
Member

No description provided.

Comment on lines 1585 to 1590
zend_fcall_info *fci = &shutdown_function_entry->fci;

zend_fcall_info_args_clear(&shutdown_function_entry->fci, true);
fci_release(&shutdown_function_entry->fci, &shutdown_function_entry->fci_cache);
if (fci) {
zend_fcall_info_args_clear(fci, true);
fci_release(fci, &shutdown_function_entry->fci_cache);
}
Copy link
Member

Choose a reason for hiding this comment

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

This seems to point to a bug elsewhere it should not be possible to not have an FCI here.

Copy link
Member

Choose a reason for hiding this comment

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

Furthermore, the patch also doesn't really make sense: fci is address-taken from a struct member of shutdown_function_entry, so it can only be NULL if shutdown_function_entry is NULL, but in that case it's undefined behaviour because you aren't allowed to do pointer math on NULL...
I think we should all run our development tools with ASAN + UBSAN enabled.

Copy link
Member

Choose a reason for hiding this comment

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

Agreed that we should check shutdown_function_entry here, and not shutdown_function_entry->fci.

My understanding of the issue is that we OOM here when registering a new shutdown function:

Z_PTR_P(zv) = pemalloc(size, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT);

as a consequence, Z_PTR_P(zv) remains NULL (it is initialized to NULL above), so shutdown_function_entry is NULL here:
php_shutdown_function_entry *shutdown_function_entry = Z_PTR_P(zv);

So the root cause is zend_hash_next_index_insert_mem(). We should probably change this function so that it doesn't leave NULL entries in case of allocation failure. We could move the malloc/memcpy before the insert, initialize tmp to that, and free when insert fails. WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

I think moving the allocation before the insert is the right approach.

Copy link
Member Author

@devnexen devnexen Jun 25, 2024

Choose a reason for hiding this comment

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

Thanks all for your feedback, just trying to take care of "day to day" stuff as much as I can :) but at least I get better understanding of the internals.

@arnaud-lb arnaud-lb self-requested a review June 25, 2024 16:01
Zend/zend_hash.h Outdated
memcpy(Z_PTR_P(zv), pData, size);
return Z_PTR_P(zv);
void *p = pemalloc(size, GC_FLAGS(ht) & IS_ARRAY_PERSISTENT);
if (!p) {
Copy link
Member

Choose a reason for hiding this comment

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

pemalloc can't fail because either it's using the request allocator which can't fail, or it's using the persistent allocator __zend_malloc which has a check:

php-src/Zend/zend_alloc.c

Lines 3320 to 3323 in 4f450b6

if (EXPECTED(tmp || !len)) {
return tmp;
}
zend_out_of_memory();

Zend/zend_hash.h Outdated

memcpy(p, pData, size);
ZVAL_PTR(&tmp, p);
if (!(zv = zend_hash_next_index_insert(ht, &tmp))) {
Copy link
Member

Choose a reason for hiding this comment

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

I wouldn't assign the return value but I'd simply return p at the end.

Copy link
Member Author

Choose a reason for hiding this comment

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

thx simpler indeed.

Copy link
Member

@arnaud-lb arnaud-lb left a comment

Choose a reason for hiding this comment

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

LGTM!

@devnexen devnexen marked this pull request as ready for review June 25, 2024 19:35
@devnexen devnexen requested review from dstogov and bukka as code owners June 25, 2024 19:35
Copy link
Member

@nielsdos nielsdos left a comment

Choose a reason for hiding this comment

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

Patch looks right.
I'd still prefer a cleaner test (e.g. the var_fusion function no longer exists so you can remove that at least). And the for loop at the end could be a while(true) loop which would also get rid of that script1_dataflow variable etc

@devnexen devnexen merged commit bc585cd into php:master Jun 25, 2024
9 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants