`hyper_request_set_uri_parts`, `hyper_request_headers`, and `hyper_response_headers` dereference `req`/`resp` before NULL validation

[meng-xu-cs]

Version

master branch

Platform

Linux / Windows

Summary

src/ffi/http_types.rs still has three exported extern "C" entrypoints that create &mut references from hyper_request* / hyper_response* before applying the usual non_null! guard:

• hyper_request_set_uri_parts
• hyper_request_headers
• hyper_response_headers

*unsafe { &mut *req }.0.uri_mut() = u;

hyper_headers::get_or_default(unsafe { &mut *req }.0.extensions_mut())

hyper_headers::get_or_default(unsafe { &mut *resp }.0.extensions_mut())

This looks like a missed follow-up to the earlier NULL-pointer sweep in #2624 / #2620. #2624 says the goal was to check pointer arguments for NULL before trying to use them; these three call sites still violate that invariant. One likely reason is that hyper_request_set_uri_parts itself was added later in #2581.

Code Sample

#include <stdint.h>
#include "hyper.h"

int main(void) {
    /* Case 1: always dereferences req */
    hyper_request_headers(NULL);

    /* Case 2: always dereferences resp */
    hyper_response_headers(NULL);

    /* Case 3: dereferences req on the successful URI-build path */
    hyper_request_set_uri_parts(
        NULL,
        (const uint8_t *)"https", 5,
        (const uint8_t *)"example.com", 11,
        (const uint8_t *)"/", 1
    );

    return 0;
}

Expected Behavior

The request/response handle should be checked before any dereference, matching the rest of the FFI API.

For NULL handles:

• hyper_request_set_uri_parts should return HYPERE_INVALID_ARG
• hyper_request_headers should return NULL
• hyper_response_headers should return NULL

Actual Behavior

These functions form &mut references from raw FFI pointers before validating the handle, so a NULL handle can invoke undefined behavior (for example, a segfault, abort, or other unpredictable behavior) instead of returning the established sentinel failure value.

The surrounding ffi_fn! wrapper does not make this safe: it wraps the body in catch_unwind, but this is not a normal argument-validation path and should be prevented before any dereference.

Additional Context

No response