From nobody Mon Sep 28 15:36:51 2026 Received: from mail-106102.protonmail.ch (mail-106102.protonmail.ch [79.135.106.102]) (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 A66E643B6FE for ; Thu, 20 Aug 2026 12:45:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.102 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787229922; cv=none; b=Hg+VXpV5TCYXwSz+nYOVN3P4EFN2PDQLeyegfEy8Ba7Mo5P8jqHpAmvWpPheUf590E7Xe477WbvDr0unNzVt1yc1EQDv9aEgzOnwJL246l7iIIEScHbCTFw+sCCWtB0hxLgfqozYMqoeo6XsxQkdwoiMnnQyR0xRxEtf63wUw/o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787229922; c=relaxed/simple; bh=AS3sZF4MOHOL/PnrFHGmfd8I3tCjlqKL1VISYbtbo64=; h=Date:To:From:Cc:Subject:Message-ID:MIME-Version:Content-Type; b=jBw4WULklLhjsooZkBavzYTZgxoLUhz2h5H+V+8Rn2NiYX1fe1oy3CVe7na9qSZW8iplrECiF5rEBQbtrF7ksYuhE82Ki2Pw3/H6JZwi/TzHIu+LMtz060SCCFQP9HMr2Dg9pKa3r++f+3czhjCf+gejYTVjPkd08Kt594awEGI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com; spf=pass smtp.mailfrom=protonmail.com; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.b=f30/HuIh; arc=none smtp.client-ip=79.135.106.102 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=protonmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.b="f30/HuIh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1787229912; x=1787489112; bh=AS3sZF4MOHOL/PnrFHGmfd8I3tCjlqKL1VISYbtbo64=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=f30/HuIhgSkLsmObikl71bREAHuLWbsagZhJ6Fy8l/A7wYXljz7OjAhw5hPwqPdnn nR1dK47UD9iHzpEcQxcrxTX4ME7pzpH68fg2V9cdaagzFF+x173CD/l2lRcyMl658m ofw0RhIenIquM2joQ7A8D8ILaRft17Ti5iZiE9PSwcBGHynEoNr4u2YWBYp1oU7st2 4xhktZU1X0zhZiYXrrGIcLwLCTBoejqXbP8aB7dwGWN17Is3bwMZcNKqxDTal0jZxe kKNnIKIQ7c5M++AXd9Yc+JZCMaiciifjVE7984jXcsT9GWvX8SeBHvWWPkXRvL8aKy 7us2bTocPH5KA== Date: Thu, 20 Aug 2026 12:45:01 +0000 To: Felix Fietkau , Lorenzo Bianconi , Ryder Lee , Shayne Chen , Sean Wang , Matthias Brugger , AngeloGioacchino Del Regno From: Ryan Leung Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Ryan Leung Subject: [PATCH mt76] wifi: mt76: fix wcid->pktid corruption in mt76_wcid_cleanup() Message-ID: <20260820-mt76-pktid-idr-race-v1-1-451f176a6495@protonmail.com> Feedback-ID: 184418679:user:proton X-Pm-Message-ID: e3e10a410ba36c1cb116a12f4f84991ddc9ac07f 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" mt76_wcid_cleanup() releases dev->status_lock before calling idr_destroy(&wcid->pktid) to tear down the pktid idr. Meanwhile, mt76_tx_status_skb_add() from tx.c can concurrently insert into that same idr during tx completion handling: spin_lock_bh(&dev->status_lock); pid =3D idr_alloc(&wcid->pktid, skb, MT_PACKET_ID_FIRST, MT_PACKET_ID_MASK, GFP_ATOMIC); Since idr_destroy() runs outside the lock, it can execute concurrently with idr_alloc() on the same idr, corrupting its internal data structures. Because idr nodes are freed through the generic slab allocator, this corruption can resurface later as an unrelated-looking crash anywhere in the kernel that happens to reuse the same freed memory. Fix this by calling idr_destroy() before releasing dev->status_lock, so that the table teardown and any concurrent insertion are mutually exclusive. Closes: https://github.com/openwrt/openwrt/issues/24594 Fixes: bd1e3e7b693c ("mt76: introduce packet_id idr") Signed-off-by: Ryan Leung --- drivers/net/wireless/mediatek/mt76/mac80211.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wi= reless/mediatek/mt76/mac80211.c index abbe65cbcd89..16e53c4593cb 100644 --- a/drivers/net/wireless/mediatek/mt76/mac80211.c +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c @@ -1744,9 +1744,12 @@ void mt76_wcid_cleanup(struct mt76_dev *dev, struct = mt76_wcid *wcid) =20 mt76_tx_status_lock(dev, &list); mt76_tx_status_skb_get(dev, wcid, -1, &list); - mt76_tx_status_unlock(dev, &list); - + /* + * must run under status_lock to avoid racing mt76_tx_status_skb_add() + * in tx.c, which allocates pktid entries via idr_alloc() concurrently. + */ idr_destroy(&wcid->pktid); + mt76_tx_status_unlock(dev, &list); =20 /* Remove from sta_poll_list to prevent list corruption after reset. * Without this, mt76_reset_device() reinitializes sta_poll_list but --- base-commit: ca800a9302764c445de0da0e84d2252400a770ee change-id: 20260820-mt76-pktid-idr-race-29f92c15b089 Best regards, -- =20 Ryan Leung