Re: [PATCH RFC v6 4/5] iio: osf: add authenticated stream parser

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Frame Smuggling / Unauthenticated Injection due to dropping only 1 byte on application-level error.
- [Low] The `partial_frames` statistic is defined but never updated.
--

commit c420661e9f0f330fb78aaadf3e5695f6b7ee7947
Author: Jinseob Kim <kimjinseob88@gmail.com>

iio: osf: add authenticated stream parser
    
Add a UART byte-stream parser for Open Sensor Fusion frames.
The parser searches for the OSF0 wire magic, keeps partial frames
buffered, checks header length and payload bounds, and passes complete
candidate frames to the core decoder.

> diff --git a/drivers/iio/opensensorfusion/osf_stream.c b/drivers/iio/opensensorfusion/osf_stream.c
> new file mode 100644
> index 0000000000000..470b4ec1f1370
> --- /dev/null
> +++ b/drivers/iio/opensensorfusion/osf_stream.c
> @@ -0,0 +1,189 @@
[ ... ]
> +		frame_len = OSF_FRAME_HEADER_LEN + payload_len + OSF_FRAME_CRC_LEN;
> +		if (stream->len < frame_len)
> +			break;

[Severity: Low]
Does this code miss updating the partial_frames statistic?

When the stream parser encounters a partial frame here and breaks out of the
processing loop, it appears stream->stats.partial_frames is not incremented.
This will leave it reporting 0 in debug outputs.

> +
> +		ret = osf_core_receive_frame(stream->osf, stream->buf, frame_len);
> +		if (ret) {
> +			if (ret == -EBADMSG)
> +				stream->stats.bad_crc_frames++;
> +
> +			/*
> +			 * Until the decoder accepts the frame, payload_len is
> +			 * untrusted. Drop only the current head and resynchronize.
> +			 */
> +			stream->stats.dropped_bytes++;
> +			osf_stream_drop_invalid_head(stream);

[Severity: High]
Can this lead to an unauthenticated protocol injection if an application-level
handler rejects a valid frame?

If a legitimate frame has a valid CRC but osf_core_receive_frame() returns an
error (like -EPROTO or -EOPNOTSUPP) because the payload is rejected by a
handler, this path drops only the first byte of the outer frame rather than
discarding frame_len bytes.

Could this allow an attacker to embed fake OSF frames within the payload of a
legitimate sensor frame, which would then be parsed as a new frame after the
single-byte drop resynchronizes?

> +			if (!first_err)
> +				first_err = ret;
> +			continue;
> +		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260628191337.937-1-kimjinseob88@gmail.com?part=4