From nobody Mon Jun 8 14:36:10 2026 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (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 4713C3F0745 for ; Thu, 28 May 2026 16:03:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779984203; cv=none; b=bdFKJCg8ubYp4FrtTobA/lIy8DALGGkXRJICP2lCqCfzc8BkbChGmbWmtBpsQslvE7rell/Bhh0zKH8iwIPB1f0GuGlqs/0vtquBv3bvGDeWiScTEjmDcHX3ap6LokdWjchN6boiwP66QLuS9fazkLZW989iKW9Yf4QiOh6ffZE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779984203; c=relaxed/simple; bh=yCSOHKbwhBjgp5Eie4MpdqNDhpIdZlR1/oBvIklWoBk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=EymOwouB8CFlLdqqKu1eeOio7L/L2r10yTyVPWnGEgsDdIub1ke5JsyByjqnr0OD3+Zr8DBVhQEOsEwe1cUD3CZDA2+Dz1i/05FqkOOuLrYzPy1iCKSRpq4bVwe5IBG4ghOs4dKPsrdKIuNhfLrxMGaHKstRUBEXddms+h/bm1k= 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=kyEYliIr; arc=none smtp.client-ip=209.85.221.50 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="kyEYliIr" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-45ebafde87cso4275345f8f.3 for ; Thu, 28 May 2026 09:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779984201; x=1780589001; 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=NGAJl71mxdY5fzmkNELb/2UlcEcGhUpJvQPIR8eDu/I=; b=kyEYliIruWPP449zRETAHnQa60KjVIzByRMRjmRY+MjWEkTcPA3pvbkogW4dNCvYLd 8HPxeQoMc22q8AT+hagLkm3lW2DfdYNnkRauRverMVHRnJblyhmx9WMkhgVhM7+gLkfA oAHzujiNo2m/aJMlNE5DxeW7F3xK6dVYcnOoY+42GXRbvhLBBYm63qNbV/4DZVf6THTj 7PmANuHKiqGzfyIOIoTz4R+Czg9rbhgu6HuUXxexzKL0+78v8NUXRbDqY8OlNSUPN7Vx ShW3PDERh3ULFDK+hovpY832lvxnLT5DIk9/Nd11vFyILWGREtkUNH7qEj+keRGvv/tB tSAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779984201; x=1780589001; 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=NGAJl71mxdY5fzmkNELb/2UlcEcGhUpJvQPIR8eDu/I=; b=hRfmuFhbgwU+aBtPvinMwLLU5XxF/hH5F53gCyVcP6kQDwzcZ4ZjJ3k3eChjmZrnf7 h60PynR9ZMV/DbL1Xked04dorv8HEchmNkkHDKaRR8FNzLVnOtPeZy8WYyQainOBDZMO mOMIZBIsCO2eVSdsyCVB0FED1PmPSFW9nV91bh20CaosgaRJI0hp/zMJytzKR4/YEeNN 1D2VGRTOMjDrnTSGS4A23UoDUYEQ3M2WP6V+bUPuI5I6nNf7tMh2VZJUlK90DVT4OtQt OgRO/EXynu+Vog4yQDnu5m1nnOV0rn8jbTJEernlF5AK0YJuD/tm+DHWrImSqek5QdnQ i0iA== X-Forwarded-Encrypted: i=1; AFNElJ/PeWm8XwDYdlYpC3eBkfc31tfebgHT4RSQT5CUNEBNNq+Vpr1Xhipp7n5ABR6n86j7qWgcoiT80+ESL4E=@vger.kernel.org X-Gm-Message-State: AOJu0YxInCHubby/8BuD/EtJbZuykJ7zCO9cdrA3JRpmrmz97T193s8f 9W8y+XImFyMG/M6mkvZpVlHmOhPdEk7pMj2ya5ae+gU4MxyXKcoQwGE= X-Gm-Gg: Acq92OEonBwY+yKviAmqM763JDDYHhYsUxrumb3zJMxUOWzcVYHFB96s5D9kutKOymk 67lb3cVT3IaYNSsw1FEuaDwEcPZH7AOrZ6oNMFi5KHImwUA6Fp/9J6QlFj24ihfawtxcI4hPhKZ 5I0EqnMow0lMFubn4N/Ci2YblUPsnzobQ9BZBByOuRIHbnbcUtSLb2nE669KYZsNa6yhhmsMW6X Lswi6y8pMHRGiUV1oPlzyML/cEGblHY6HZmkrG4gjWigTx2XS6b5/mvUTcq/jDD0dL4QvzAVbm0 pOpaos3lT8VFBa1VDlXK0DrhYwym6DiAGPsgmZBbjkn/VasfA+OE2biwX2H4PYroZ947lVQergJ ZbcRAll7tfROAbPUmPtmQHu/tWE3kqgrZMg98gD7oNRVYC1Fa7CwZ0l+Jr8bayiSmXrY2K1HkZG h9JyiMZrpZMOGFbjiI X-Received: by 2002:a05:6000:144c:b0:43b:498f:dceb with SMTP id ffacd0b85a97d-45eb3692577mr45679938f8f.9.1779984200272; Thu, 28 May 2026 09:03:20 -0700 (PDT) Received: from debian.. ([2001:41d0:303:db6b::]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45eeb36c40asm3739691f8f.13.2026.05.28.09.03.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 09:03:19 -0700 (PDT) From: Tristan Madani X-Google-Original-From: Tristan Madani To: Steffen Klassert , Herbert Xu Cc: Christian Hopps , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org, stable@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] xfrm: iptfs: fix ABBA deadlock in iptfs_destroy_state() Date: Thu, 28 May 2026 16:03:18 +0000 Message-ID: <20260528160318.2631699-1-tristan@talencesecurity.com> X-Mailer: git-send-email 2.47.3 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" iptfs_destroy_state() calls hrtimer_cancel() while holding a spinlock that the timer callback also acquires, leading to an ABBA deadlock on SMP systems. For the output timer (iptfs_timer): - iptfs_destroy_state() holds x->lock, calls hrtimer_cancel() - iptfs_delay_timer() callback takes x->lock For the drop timer (drop_timer): - iptfs_destroy_state() holds drop_lock, calls hrtimer_cancel() - iptfs_drop_timer() callback takes drop_lock Both timers use HRTIMER_MODE_REL_SOFT, so their callbacks run in softirq context. When hrtimer_cancel() is called for a soft timer that is currently executing on another CPU, hrtimer_cancel_wait_running() spins on softirq_expiry_lock -- the same lock held by the softirq running the callback. If the callback is blocked waiting for the spinlock held by the caller of hrtimer_cancel(), a circular dependency forms: CPU 0: holds lock_A -> waits for softirq_expiry_lock CPU 1: holds softirq_expiry_lock -> waits for lock_A Fix this by cancelling both timers before acquiring their respective locks. hrtimer_cancel() is safe to call without holding any lock and will wait for any in-progress callback to complete. The locks are still acquired afterwards to synchronize with any in-flight packet processing before tearing down the state. Found by source code audit. Fixes: 4b3faf610cc6 ("xfrm: iptfs: add new iptfs xfrm mode impl") Cc: Christian Hopps Cc: Steffen Klassert Cc: stable@vger.kernel.org Signed-off-by: Tristan Madani --- net/xfrm/xfrm_iptfs.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/xfrm/xfrm_iptfs.c b/net/xfrm/xfrm_iptfs.c index 97bc979e55baf..fd25b2b230793 100644 --- a/net/xfrm/xfrm_iptfs.c +++ b/net/xfrm/xfrm_iptfs.c @@ -2708,8 +2708,9 @@ static void iptfs_destroy_state(struct xfrm_state *x) if (!xtfs) return; =20 - spin_lock_bh(&xtfs->x->lock); hrtimer_cancel(&xtfs->iptfs_timer); + + spin_lock_bh(&xtfs->x->lock); __skb_queue_head_init(&list); skb_queue_splice_init(&xtfs->queue, &list); spin_unlock_bh(&xtfs->x->lock); @@ -2717,8 +2718,9 @@ static void iptfs_destroy_state(struct xfrm_state *x) while ((skb =3D __skb_dequeue(&list))) kfree_skb(skb); =20 - spin_lock_bh(&xtfs->drop_lock); hrtimer_cancel(&xtfs->drop_timer); + + spin_lock_bh(&xtfs->drop_lock); spin_unlock_bh(&xtfs->drop_lock); =20 if (xtfs->ra_newskb) --=20 2.47.3