From nobody Mon Feb 9 07:39:05 2026 Received: from canpmsgout10.his.huawei.com (canpmsgout10.his.huawei.com [113.46.200.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9486C34CFAF; Thu, 5 Feb 2026 12:18:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.225 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770293923; cv=none; b=Ft3eUPAlam5qKZxsMHcTkivAduUsfEFe7hybiETZDgImCcGF1twbhjWMlJTpoX7K+4znE7yrp1DfMdRukVDcU/7NU7s5hI2muMzYHvn3e5qlpRhSZTGkJnhCekCuRMJj6+RWlgwNE1k6TThrUrIm6rFeMTKbcBFWOW0sh+tTudU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770293923; c=relaxed/simple; bh=ptP2t2pMIYG1ra3PoZzEkp4X0a9shHKVhCPGgyrKwEE=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=m8FOXl1ZeaxtG5rkhnsiDfykK6TqHNPh4l8wKtbEvh61KMViP7yqwBS08Nto7cWnhZiXlmbKwL7157RlBxlXo5eMEug1Y3oFO6Fy5WCdi0gYpc51BbJttrpnkqQysA4NqThD+0P1uDQHXyQAS3KTTudYSGqIJ1F8Spnw5Mdk874= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Nbenqm+z; arc=none smtp.client-ip=113.46.200.225 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Nbenqm+z" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=XCmgJslFgz2pKH+mZm9wj/ooAUI908xgVtyxwrSO2qI=; b=Nbenqm+zaNkhUgMyWxWSbtcrN9znk8UQwyI+dYr9jra8w+i3sNUhE4CcZcGdpFeIeRuwvAM1E H5l2vFZ9S1BQwkIJSptarmQp1DKUg1BzSvggPYGdLNm/GQSagcAV9j9byHsFKo3wRBBQemkdrtd GQ5tnNhYByIFmBsrV/GFFz0= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout10.his.huawei.com (SkyGuard) with ESMTPS id 4f6GNb3Yg9z1K96b; Thu, 5 Feb 2026 20:14:07 +0800 (CST) Received: from kwepemk100013.china.huawei.com (unknown [7.202.194.61]) by mail.maildlp.com (Postfix) with ESMTPS id E849A40565; Thu, 5 Feb 2026 20:18:39 +0800 (CST) Received: from localhost.localdomain (10.90.31.46) by kwepemk100013.china.huawei.com (7.202.194.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Thu, 5 Feb 2026 20:18:39 +0800 From: Jijie Shao To: , , , , , CC: , , , , , , , , , , , Subject: [PATCH V2 net] net: hns3: fix double free issue for tx spare buffer Date: Thu, 5 Feb 2026 20:17:19 +0800 Message-ID: <20260205121719.3285730-1-shaojijie@huawei.com> X-Mailer: git-send-email 2.30.0 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 X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemk100013.china.huawei.com (7.202.194.61) Content-Type: text/plain; charset="utf-8" From: Jian Shen In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory. Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory. The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer. Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new `tx_spare` fails. This ensures the error cleanup path only frees genuinely newly allocated buffers. Fixes: 907676b130711 ("net: hns3: use tx bounce buffer for small packets") Signed-off-by: Jian Shen Signed-off-by: Jijie Shao Reviewed-by: Jacob Keller --- v1 -> v2: - Update this commit message, suggested by Jake and Jakub. v1: https://lore.kernel.org/all/20260202105837.1909444-1-shaojijie@huawei= .com/ --- drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c b/drivers/net/= ethernet/hisilicon/hns3/hns3_enet.c index 7a9573dcab74..e879b04e21b0 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c @@ -1048,13 +1048,13 @@ static void hns3_init_tx_spare_buffer(struct hns3_e= net_ring *ring) int order; =20 if (!alloc_size) - return; + goto not_init; =20 order =3D get_order(alloc_size); if (order > MAX_PAGE_ORDER) { if (net_ratelimit()) dev_warn(ring_to_dev(ring), "failed to allocate tx spare buffer, exceed= to max order\n"); - return; + goto not_init; } =20 tx_spare =3D devm_kzalloc(ring_to_dev(ring), sizeof(*tx_spare), @@ -1092,6 +1092,13 @@ static void hns3_init_tx_spare_buffer(struct hns3_en= et_ring *ring) devm_kfree(ring_to_dev(ring), tx_spare); devm_kzalloc_error: ring->tqp->handle->kinfo.tx_spare_buf_size =3D 0; +not_init: + /* When driver init or reset_init, the ring->tx_spare is always NULL; + * but when called from hns3_set_ringparam, it's usually not NULL, and + * will be restored if hns3_init_all_ring() failed. So it's safe to set + * ring->tx_spare to NULL here. + */ + ring->tx_spare =3D NULL; } =20 /* Use hns3_tx_spare_space() to make sure there is enough buffer --=20 2.33.0