From nobody Sun Feb 8 05:59:02 2026 Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C0AC478857 for ; Wed, 21 Jan 2026 09:19:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768987182; cv=none; b=Zi3Bvyjcj5qpqyh3z6yoVZqwzh5mYAw82fBfsidEgLJs6irk8+gVRc/Sq/4kL17dWMouyUZEynWDNDL+YCiuy/vAhBFLjYZpfyIgNjgWgHpsDksoRiOVHlSJ5Nc3b5MqBdeY7E29xp/a6yU2eYjoUl2ACbnB3Yd4FMhfHAcsQYE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768987182; c=relaxed/simple; bh=4IOfkFMFIGvsvpaqgBlaUzsYYethKFQA2Xe7ZO8rkXA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=G7sQV353ZoqpA3dJslePkc53ssieTxEApl36jS+1BCE9raUOZ0vO3qFF50Fd091jsDrfCWxVkCW668xy7a7q2satfHDSLERaoBzrSG7/bsk4n0uuUqjrA7nEo/+yM2qkhZZ/uL9yCZ0kGwvq9PT2AhWoGbMw0F9NLoFlQiuVSMM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=EmrKtvPP; arc=none smtp.client-ip=209.85.210.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EmrKtvPP" Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-81f3fba4a11so6062169b3a.1 for ; Wed, 21 Jan 2026 01:19:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768987180; x=1769591980; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=Hba5N0XT4kz2okXqzmo7xWvP0YP9wd2FNtkfwLzHXNI=; b=EmrKtvPPfve8mAikAT+CeLBPxMjQ20aAKVyL7zgmX1Kqaf8ThnW0JD3VZmdr8ow6PV 2WYqziMcTtU7AwUM0XTdPLXB1tJe0hUbA28l+TBZmZK8UbiPW9YvX3jF0V0s19zVp99X 5AKssEhJSmw1kVHz+MBnKxmfQ50kj869FE5KRpbPNbRkEds+h4LCauAe28cNZGuQOTX8 Hk44GgAk++7FXfYlzJgFSneuyzkPxBc2jqVm9w6NCmVXBhUt6pq/eGs6ZPcYuz4QFTN8 V6nFvguIfy0CZP9JdhPJ7kLFU2JyV/IH4/LzSwr71sWcbGOQmWKEivcZR59Mik00u5jn zdqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768987180; x=1769591980; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Hba5N0XT4kz2okXqzmo7xWvP0YP9wd2FNtkfwLzHXNI=; b=bgCsX+4CDVnEckbxQMEXsg0PQ9N4jQKL3B95AlohQsgJ0aH5xTtGv87f9k9aZC+8Wb YOheLtZ5i3ECty94ExWIRuOZJIXhEJnyBV9lSNHJPt/ROKZRrRJAS7KZwUIkVezDs618 FpEWR628L98m9L6ZjrOCwseLGOcElOZYvZINis3Sp2fDvY7kNwg8hmYhWPlj7Erhx4T1 qgn8DXR/q/Z2iVN0+qLDzs2iqG4L68AfA06z5hPIvtrK9cj5Heosv6bnVc5Z0yPwI7tM KHyqxIoGxYav2zeg/4e8hvTa8AbFnhnMjwC0U6IaTsYuLhloOBknqWsxjAO7BjMhnBlX 1lmg== X-Forwarded-Encrypted: i=1; AJvYcCX/sf6/7rFI+FD3DJlFzogH2sROEgpU3SkhqKl5Jzy6uiUhf15uxW/KuIDmOhUElY9+ZxZwvZ6nr6e6Rdo=@vger.kernel.org X-Gm-Message-State: AOJu0YwlDNC2f7yWrau4gBgHFtfEX4GWnSyRPLF23H9LsqyI+YMF9uhw cIiOIFh9NXzPsHt929qL4+9pFVyXWlgwzRqohqBawCYXrHd2Er+pdkCtOWExqEo3LLnC8FI= X-Gm-Gg: AZuq6aJaFpfoTyJMlZTEjQit47zG1XuEjZIje2PSQMPLP2b8cPSs17jHEY1Gk82WfDT Mxgdh6J/TBCtp9BQHDsdzlR2NBDtaTHl88RtgCCNnuGjdMfFH8nJfIvPuHQ/IA7kLdpJUHpunpt w70XDTm8Rv7r8u30I5EsfYETgiDmSEH+YuISpC0X9d5Om8KhxHYwR7dE2Hd8W+0yC9jqPcSNmXW aQ0pbXQTVY/uU9B7Jt2OnwUOJLqEXgOOGbHBMaONLrq+zofB5GjbnN3wFusGmvUTXxjQ84/M3fI 2Gcj7afzuZbE/D9799JBvphowLXm1xglpWI+sOAbr+GKZuRmrfriA6qPHt7jZXR4M9IwTCCN6ZC uITodDg5dS2c1fLvq/3ztqFiuXLacmg/XgjsbZ9bQW4cg/+P9M1oWb8rESpkLsmbD/DrMp1Pl2O TLtHRdypCugunbH+o= X-Received: by 2002:a05:6a21:6088:b0:366:14b0:1a30 with SMTP id adf61e73a8af0-38e45e6ade8mr3970675637.62.1768987179757; Wed, 21 Jan 2026 01:19:39 -0800 (PST) Received: from DESKTOP-BKIPFGN ([38.76.140.13]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c5edf37a7b0sm11594603a12.33.2026.01.21.01.19.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 01:19:39 -0800 (PST) From: Kery Qi To: chandrashekar.devegowda@intel.com, loic.poulain@oss.qualcomm.com, ryazanov.s.a@gmail.com, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com Cc: chiranjeevi.rapolu@linux.intel.com, haijun.liu@mediatek.com, ricardo.martinez@linux.intel.com, johannes@sipsolutions.net, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Kery Qi Subject: [PATCH] net: wwan: t7xx: fix potential skb->frags overflow in RX path Date: Wed, 21 Jan 2026 17:18:54 +0800 Message-ID: <20260121091853.1758-2-qikeyu2017@gmail.com> X-Mailer: git-send-email 2.50.1.windows.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" When receiving data in the DPMAIF RX path, the t7xx_dpmaif_set_frag_to_skb() function adds page fragments to an skb without checking if the number of fragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow in skb_shinfo(skb)->frags[] array, corrupting adjacent memory and potentially causing kernel crashes or other undefined behavior. This issue was identified through static code analysis by comparing with a similar vulnerability fixed in the mt76 driver commit b102f0c522cf ("mt76: fix array overflow on receiving too many fragments for a packet"). The vulnerability could be triggered if the modem firmware sends packets with excessive fragments. While under normal protocol conditions (MTU 3080 bytes, BAT buffer 3584 bytes), a single packet should not require additional fragments, the kernel should not blindly trust firmware behavior. Malicious, buggy, or compromised firmware could potentially craft packets with more fragments than the kernel expects. Fix this by adding a bounds check before calling skb_add_rx_frag() to ensure nr_frags does not exceed MAX_SKB_FRAGS. Fixes: d642b012df70a ("net: wwan: t7xx: Add data path interface") Signed-off-by: Kery Qi --- drivers/net/wwan/t7xx/t7xx_hif_dpmaif_rx.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/wwan/t7xx/t7xx_hif_dpmaif_rx.c b/drivers/net/wwan/= t7xx/t7xx_hif_dpmaif_rx.c index b76bea6ab2d7..b041e6f48732 100644 --- a/drivers/net/wwan/t7xx/t7xx_hif_dpmaif_rx.c +++ b/drivers/net/wwan/t7xx/t7xx_hif_dpmaif_rx.c @@ -395,6 +395,7 @@ static int t7xx_dpmaif_set_frag_to_skb(const struct dpm= aif_rx_queue *rxq, struct sk_buff *skb) { unsigned long long data_bus_addr, data_base_addr; + struct skb_shared_info *shinfo =3D skb_shinfo(skb); struct device *dev =3D rxq->dpmaif_ctrl->dev; struct dpmaif_bat_page *page_info; unsigned int data_len; @@ -407,13 +408,16 @@ static int t7xx_dpmaif_set_frag_to_skb(const struct d= pmaif_rx_queue *rxq, if (!page_info->page) return -EINVAL; =20 + if (shinfo->nr_frags >=3D MAX_SKB_FRAGS) + return -EINVAL; + data_bus_addr =3D le32_to_cpu(pkt_info->pd.data_addr_h); data_bus_addr =3D (data_bus_addr << 32) + le32_to_cpu(pkt_info->pd.data_a= ddr_l); data_base_addr =3D page_info->data_bus_addr; data_offset =3D data_bus_addr - data_base_addr; data_offset +=3D page_info->offset; data_len =3D FIELD_GET(PD_PIT_DATA_LEN, le32_to_cpu(pkt_info->header)); - skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page_info->page, + skb_add_rx_frag(skb, shinfo->nr_frags, page_info->page, data_offset, data_len, page_info->data_len); =20 page_info->page =3D NULL; --=20 2.34.1