Skip to content

[mctp-rs] SmbusEspiMedium::serialize: bounds-check body_wire_len before truncating to byte_count: u8 #846

@dymk

Description

@dymk

From PR #844 review (Copilot):

byte_count is set via body_wire_len as u8 with no bounds check. If a caller writes more than 255 bytes into the body region, this will truncate byte_count and produce an invalid SMBus frame / mismatched PEC. Even if higher layers usually cap this via max_message_body_size(), it's safer for the medium to validate body_wire_len <= u8::MAX and return an error otherwise.

Location: mctp-rs/src/medium/smbus_espi.rs:91

Pre-existing: verified — same as u8 truncation exists at the v0.2.0 baseline (dymk/mctp-rs @ 3d941ba, line is byte_count: body_len as u8). PR #844 only renames body_lenbody_wire_len; behavior unchanged.

SMBus context: the SMBus spec hard-caps a frame's byte_count field to 1 byte (255). The MCTP-over-SMBus layer above should fragment messages so individual packet bodies stay ≤ 255 bytes. Today, the cap is implicit (via max_message_body_size() returning a workspace-wide MTU); a defensive check at the medium boundary would convert silent corruption into an explicit MctpPacketError::MediumError.

Fix sketch:

let byte_count_u8 = u8::try_from(body_wire_len)
    .map_err(|_| MctpPacketError::MediumError("body_wire_len exceeds SMBus byte_count u8 max"))?;

Scope: out of scope for the source-bump PR #844 (pre-existing behavior); follow-up against the in-tree source.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions