Re: [PATCH RFC 05/20] ctlv: Prepare message input handling

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] ctlv: infinite loop in ctlv_attr_next on out-of-bounds error path
--

commit 5ae11d979c8fbb4e21430610d57f8866b9d74025
Author: Jiri Pirko <jiri@resnulli.us>

ctlv: Prepare message input handling
    
This commit introduces wire walking, request indexing, and validated input
accessors for CTLV generated family readers. It keeps CONFIG_CTLV unwired
until module dispatch is complete.

> diff --git a/drivers/ctlv/message.c b/drivers/ctlv/message.c
> new file mode 100644
> index 0000000000000..7e5742ba8f708
> --- /dev/null
> +++ b/drivers/ctlv/message.c

[ ... ]

> +void ctlv_attr_next(struct ctlv_cursor *cursor)
> +{
> +	const struct ctlv_message_input_slot *slot;
> +	const struct ctlv_message_input_scope *scope;
> +	const struct ctlv_node_schema *node;
> +	const struct ctlv_attr *next;
> +	u32 next_nest;
> +	u32 next_offset;
> +
> +	slot = ctlv_message_cursor_index(cursor);
> +	if (!slot || WARN_ON_ONCE(!cursor->attr))
> +		return;
> +	next = (const void *)((const u8 *)cursor->attr +
> +			      ALIGN((size_t)cursor->attr->len, CTLV_ALIGNTO));
> +	next_offset = ctlv_message_offset(cursor->msg, next);
> +	if (next_offset == slot->end_offset) {
> +		cursor->attr = NULL;
> +		cursor->index_nest_scope = CTLV_MESSAGE_INPUT_INDEX_NONE;
> +		return;
> +	}
> +	if (WARN_ON_ONCE(next_offset > slot->end_offset))
> +		return;

[Severity: High]
Does this error path fail to invalidate the cursor, leading to an
inescapable infinite loop during attribute iteration?

In ctlv_attr_next(), if the computed next_offset exceeds slot->end_offset,
the function triggers a WARN_ON_ONCE and returns early. Because it returns
without clearing cursor->attr (unlike the successful termination path which
explicitly sets it to NULL), the cursor's state remains exactly as it was.

When using iterator macros like CTLV_IN_FOR_EACH, the loop continues as long
as ctlv_attr_ok() returns true. Since the cursor state is unmodified, it
evaluates as valid, causing the loop to re-process the exact same state and
hit the error path again, resulting in a hard CPU lockup.

Should the error path explicitly set cursor->attr = NULL before returning
to safely terminate the iteration?

> +	cursor->attr = next;
> +	node = &cursor->tree->node_schemas[cursor->node];
> +	if (node->kind == CTLV_SCHEMA_NEST) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015145053.3664509-1-jiri@resnulli.us?part=5