Skip to content

Unsound Use of CStr::from_ptr in add_architecture_hint #123

Open
@lwz23

Description

@lwz23

Description
The add_architecture_hint function uses unsafe { CStr::from_ptr(hint) } to interpret a raw C string pointer (*mut c_char) as a CStr. This approach assumes that the pointer is valid, properly aligned, non-null, and null-terminated. If any of these conditions are violated, the program will invoke undefined behavior (UB). The function does not validate the hint pointer or its contents, making it unsound.

pub fn add_architecture_hint(&mut self, cpu: *mut ConfObject, hint: *mut c_char) -> Result<()> {

pub fn add_architecture_hint(&mut self, cpu: *mut ConfObject, hint: *mut c_char) -> Result<()> {
    let hint = unsafe { CStr::from_ptr(hint) }.to_str()?;
    let processor_number = get_processor_number(cpu)?;
    debug!(
        self.as_conf_object(),
        "add_architecture_hint({processor_number}, {hint})"
    );
    self.architecture_hints
        .insert(processor_number, ArchitectureHint::from_str(hint)?);

    Ok(())
}

Problems:
this function is a pub function, so I assume user can control the hint field, it cause some problems.

  1. Unchecked Pointer Validity:
    The function does not verify that hint is a valid pointer. If hint is null, misaligned, or invalid, the call to CStr::from_ptr results in undefined behavior.
  2. Null-Termination Requirement:
    CStr::from_ptr requires the string to be null-terminated. If the input pointer does not point to a null-terminated string, the function will read out of bounds, causing undefined behavior.

The function does not document or enforce safety requirements for the hint parameter, leaving it up to the caller to ensure validity. This violates Rust's safety principles and makes the function unsound.

Suggestion

  1. mark this function as unsafe and provide safety doc.
  2. add some check in the function body.

Additional Context:
This issue arises from the unsafe handling of raw pointers and unchecked assumptions about input validity. Rust's unsafe constructs should only be used when their safety guarantees can be upheld, and all potential invalid states must be handled explicitly.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions