Re: [PATCH net v2] net: wwan: iosm: bound device offsets in the MUX downlink decoder

[Jakub Kicinski]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: wwan: iosm: bound device offsets in the MUX downlink decoder

This patch validates device-supplied offsets and lengths in
mux_dl_adb_decode() and mux_dl_process_dg() against skb->len so that a
modem reporting an index or length past the downlink buffer cannot make
the decoder read out of bounds. The block header, each table header,
the datagram table, and each datagram index and length are now bounded
against skb->len.

> diff --git a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
> index bff46f7ca59f..ff9a4bc52f29 100644
> --- a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
> +++ b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c

[ ... ]

> @@ -606,6 +612,11 @@ static void mux_dl_adb_decode(struct iosm_mux *ipc_mux,
>  
>  	/* Loop through mixed session tables. */
>  	while (adth_index) {
> +		/* The table header must lie within the received skb. */
> +		if (adth_index < sizeof(struct mux_adbh) ||
> +		    adth_index > skb->len - sizeof(struct mux_adth))
> +			goto adb_decode_err;
> +
>  		/* Get the reference to the table header. */
>  		adth = (struct mux_adth *)(block + adth_index);

[High]
The commit message frames the threat model as "A modem that reports an
index or a length past the downlink buffer", and this patch bounds every
device offset against skb->len. Could the same threat model also produce
an infinite loop in this while (adth_index) loop?

The loop continues as long as adth_index is non-zero, and each iteration
sets:

    adth_index = le32_to_cpu(adth->next_table_index);

The new bounds check only requires that adth_index lies within
[sizeof(struct mux_adbh), skb->len - sizeof(struct mux_adth)]. It does
not require forward progress. Can a modem stage two valid struct mux_adth
headers inside one downlink skb (each with the IOSM_AGGR_MUX_SIG_ADTH
signature, a valid if_id, and table_length >= sizeof(struct mux_adth))
where table A's next_table_index points to table B and table B's
next_table_index points back to table A?

Each adth_index passes the new range check, so the loop never terminates.
mux_dl_adb_decode() runs in softirq context via:

    ipc_task_queue_handler()
      ipc_imem_tq_irq_cb()
        ipc_imem_handle_irq()
          ipc_imem_dl_pipe_process()
            ipc_imem_dl_skb_process()
              ipc_mux_dl_decode()
                mux_dl_adb_decode()

If the cycled tables also reference valid datagrams, each pass through
the loop calls mux_dl_process_dg() -> ipc_mux_net_receive() which does
skb_clone() per datagram, so the same skb produces unbounded clones for
as long as the loop runs.

This is not a regression introduced by this patch — the cycle was
reachable before — but since the patch is hardening the decoder against
modem-supplied offsets, would it make sense to also require strictly
increasing next_table_index, cap the iteration count, or otherwise
guarantee forward progress in the same change?

> @@ -629,6 +640,10 @@ static void mux_dl_adb_decode(struct iosm_mux *ipc_mux,
>  		if (le16_to_cpu(adth->table_length) < sizeof(struct mux_adth))
>  			goto adb_decode_err;
>  
> +		/* The whole datagram table must fit in the received skb. */
> +		if (le16_to_cpu(adth->table_length) > skb->len - adth_index)
> +			goto adb_decode_err;
> +
>  		/* Calculate the number of datagrams. */
>  		nr_of_dg = (le16_to_cpu(adth->table_length) -
>  					sizeof(struct mux_adth)) /
-- 
pw-bot: cr