mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Qihang <q.h.hack.winter@gmail.com>
To: netdev@vger.kernel.org
Cc: steffen.klassert@secunet.com, chopps@labn.net,
	herbert@gondor.apana.org.au, davem@davemloft.net,
	edumazet@kernel.org, kuba@kernel.org, pabeni@redhat.com,
	horms@kernel.org, dsahern@kernel.org, idosch@nvidia.com,
	linux-kernel@vger.kernel.org
Subject: [PATCH net v8 2/3] xfrm: iptfs: hand the drop timer back to the reorder window
Date: Sat, 31 Oct 2026 10:07:03 +0800	[thread overview]
Message-ID: <20261107111617.21347-3-q.h.hack.winter@gmail.com> (raw)
In-Reply-To: <20261107111617.21347-1-q.h.hack.winter@gmail.com>

__iptfs_reassem_done() cancels the drop timer whenever an in-progress
packet finishes reassembly, even if the reorder window still holds
out-of-order packets.  Those packets were saved with a drop time of their
own and the same timer is what ages them out.

If the missing packet never arrives, the window is never drained: the
queued packets are not delivered, and each one keeps the xfrm_state
reference it took from its secpath, so the state cannot be destroyed.
Nothing re-arms the timer to clean that up.  iptfs_set_window_drop_times()
only starts it when the walk back through the window reaches the empty
slot 0, and an occupied slot 0 stops the walk.

Cancel the timer as before and, if the window has entries, arm it again
for the drop time of slot 0.  Leaving the queued timer in place instead
would keep the expiry of the reassembly that just finished, which is
earlier than the window's own deadline; a reassembly started in between
would then not arm its timer and could be dropped before its budget ran
out.  Arming it for slot 0 keeps what iptfs_drop_timer() expects, one
deadline that belongs to the window.

Fixes: 6be02e3e4f376 ("xfrm: iptfs: handle reordering of received packets")
Reported-by: Lilly Aronleigh <lilly@aronleigh.au>
Link: https://lore.kernel.org/netdev/20260824072851.301644-3-lilly@aronleigh.au/
Cc: stable@vger.kernel.org
Signed-off-by: Qihang <q.h.hack.winter@gmail.com>
---
 net/xfrm/xfrm_iptfs.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/net/xfrm/xfrm_iptfs.c b/net/xfrm/xfrm_iptfs.c
index 0313a43aa..5ea3e77dd 100644
--- a/net/xfrm/xfrm_iptfs.c
+++ b/net/xfrm/xfrm_iptfs.c
@@ -708,6 +708,15 @@ static void __iptfs_reassem_done(struct xfrm_iptfs_data *xtfs, bool free)
 
 	/* We don't care if it works locking takes care of things */
 	hrtimer_try_to_cancel(&xtfs->drop_timer);
+	/* The timer also ages out the reorder window, if it has any entries. */
+	if (xtfs->w_savedlen) {
+		time64_t now = ktime_get_raw_fast_ns();
+
+		hrtimer_start(&xtfs->drop_timer,
+			      xtfs->w_saved[0].drop_time - now,
+			      IPTFS_HRTIMER_MODE);
+	}
+
 	if (free)
 		kfree_skb(xtfs->ra_newskb);
 	xtfs->ra_newskb = NULL;
-- 
2.54.0 (Apple Git-157)



  parent reply	other threads:[~2026-11-07  3:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-06  1:57 [PATCH net v8 0/3] xfrm: fix vti tunnel device use-after-free across async crypto resumption Qihang
2026-10-14 13:17 ` [PATCH net v8 1/3] xfrm: use skb->dev before dropping the reference held across async Qihang
2026-10-31  2:07 ` Qihang [this message]
2026-10-31  2:09 ` [PATCH net v8 3/3] xfrm: hold the tunnel device reference across the input path Qihang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261107111617.21347-3-q.h.hack.winter@gmail.com \
    --to=q.h.hack.winter@gmail.com \
    --cc=chopps@labn.net \
    --cc=davem@davemloft.net \
    --cc=dsahern@kernel.org \
    --cc=edumazet@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=steffen.klassert@secunet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®