[PATCH] net: wwan: iosm: fix potential skb leak in MUX DL decode

[PATCH] net: wwan: iosm: fix potential skb leak in MUX DL decode

[Fang Xieyan]

ipc_mux_dl_decode() owns the received skb and frees it after
decoding. However, the early return when skb->data is NULL
bypasses the skb cleanup.

Free the skb through ipc_pcie_kfree_skb() before returning
to ensure that both the DMA mapping and skb are released.

Fixes: 3670970dd8c6 ("net: iosm: shared memory IPC interface")
Reviewed-by: Guanglei Zhu <zhugl3@xiaopeng.com>
Signed-off-by: Fang Xieyan <fangxy@xiaopeng.com>
---
 drivers/net/wwan/iosm/iosm_ipc_mux_codec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
index 0bbd41263cc2..61700688eac9 100644
--- a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
+++ b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
@@ -693,8 +693,10 @@ void ipc_mux_dl_decode(struct iosm_mux *ipc_mux, struct sk_buff *skb)
 {
 	u32 signature;
 
-	if (!skb->data)
+	if (!skb->data) {
+		ipc_pcie_kfree_skb(ipc_mux->pcie, skb);
 		return;
+	}
 
 	/* Decode the MUX header type. */
 	signature = le32_to_cpup((__le32 *)skb->data);
-- 
2.50.1

Re: [PATCH] net: wwan: iosm: fix potential skb leak in MUX DL decode

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH] net: wwan: iosm: fix potential skb leak in MUX DL decode

[Loic Poulain]

Hi Fang,

On Mon, Nov 2, 2026 at 9:19 AM Fang Xieyan <fangxy@xiaopeng.com> wrote:
>
> ipc_mux_dl_decode() owns the received skb and frees it after
> decoding. However, the early return when skb->data is NULL
> bypasses the skb cleanup.
>
> Free the skb through ipc_pcie_kfree_skb() before returning
> to ensure that both the DMA mapping and skb are released.
>
> Fixes: 3670970dd8c6 ("net: iosm: shared memory IPC interface")
> Reviewed-by: Guanglei Zhu <zhugl3@xiaopeng.com>
> Signed-off-by: Fang Xieyan <fangxy@xiaopeng.com>
> ---
>  drivers/net/wwan/iosm/iosm_ipc_mux_codec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
> index 0bbd41263cc2..61700688eac9 100644
> --- a/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
> +++ b/drivers/net/wwan/iosm/iosm_ipc_mux_codec.c
> @@ -693,8 +693,10 @@ void ipc_mux_dl_decode(struct iosm_mux *ipc_mux, struct sk_buff *skb)
>  {
>         u32 signature;
>
> -       if (!skb->data)
> +       if (!skb->data) {

Can skb->data ever be NULL in the first place? This looks rather
unusual. If it can happen, please describe what leads to that
situation. Otherwise, the check should simply be removed.

> +               ipc_pcie_kfree_skb(ipc_mux->pcie, skb);
>                 return;
> +       }
>
>         /* Decode the MUX header type. */
>         signature = le32_to_cpup((__le32 *)skb->data);
> --
> 2.50.1
>

Re: [PATCH] net: wwan: iosm: fix potential skb leak in MUX DL decode

[Fang Xieyan]

Hi Loic,

You're right, skb->data cannot be NULL in this path. I traced both the
allocation side and the RX path that feeds ipc_mux_dl_decode(), and the
check can never trigger.

Allocation chain:

  ipc_pcie_alloc_skb()
    +-- ipc_pcie_alloc_local_skb()
          +-- __netdev_alloc_skb()

On success skb->data points into a valid linear buffer; skb_reserve()
only advances skb->data within that buffer and never clears the
pointer. Allocation or DMA mapping failure returns a NULL skb.

The RX path is:

  ipc_imem_dl_pipe_process()
    +-- ipc_protocol_dl_td_process()
    +-- ipc_imem_dl_skb_process()
          +-- if (!skb) return;
          +-- ipc_mux_dl_decode()

The skb is allocated and queued on the DL pipe by
ipc_protocol_dl_td_prepare(). It stores the skb in skbr_start[] only
after a successful allocation; on failure it returns without advancing
the head or publishing the descriptor.

On the RX path, ipc_protocol_dl_td_process() either returns a valid skb
or frees it and returns NULL. ipc_imem_dl_skb_process() checks for NULL
before calling ipc_mux_dl_decode().

The later skb_put() only updates skb->len and the tail; it does not
touch skb->data. DMA writes to the mapped data buffer, not to the skb
metadata.

I couldn't find any code in the IOSM driver that assigns skb->data to
NULL either.

So the check is unreachable: the skb that reaches ipc_mux_dl_decode()
always has a valid data pointer. I'll send a cleanup patch that removes
the redundant check instead.

Thanks.

Fang Xieyan