Skip to content

Fix uninitialized variable accesses in sockets/conversions #10966

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 1 commit into from

Conversation

nielsdos
Copy link
Member

This was first pointed out in GH-10959.
The from_zval_... functions don't always write to the pointer, in particular it is necessary to check for an error before using the value. Otherwise we can access an uninitialized value and that's UB (and dangerous).

Note: this does NOT get rid of the compiler warning. Even though there is error checking now, the compiler isn't smart enough to figure out that the values can not be used uninitialized.

This was first pointed out in phpGH-10959.
The from_zval_... functions don't always write to the pointer, in particular
it is necessary to check for an error before using the value. Otherwise
we can access an uninitialized value and that's UB (and dangerous).

Note: this does *NOT* get rid of the compiler warning. Even though there
is error checking now, the compiler isn't smart enough to figure out
that the values can not be used uninitialized.
Copy link
Member

@devnexen devnexen left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@Girgias Girgias left a comment

Choose a reason for hiding this comment

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

LGTM


if (UNEXPECTED(ctx->err.has_error)) {
return;
}
} else {
family = ctx->sock->type;
Copy link
Member

Choose a reason for hiding this comment

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

Would moving this to be an unconditional set prior to the if branch get rid of the compiler warning?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes. However, then we unconditionally do a memory load in all cases. So I'd prefer to just write a dummy value in the non-else branch and commit that on its own to master (similar for the other warning). WDYT?

Copy link
Member

Choose a reason for hiding this comment

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

Sounds good to me :)

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.

3 participants