From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a6-smtp.messagingengine.com (fout-a6-smtp.messagingengine.com [103.168.172.149]) (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 13F6C53E2E6 for ; Wed, 14 Oct 2026 14:10:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.149 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791987058; cv=none; b=I9ay1DH7oB/BW1EPA20rFEKjMlU2M9+Dx8omAoFdgUnxV7ICxBs75hV3KV4JErfhjc7mvrxE0U9IYQBzLmysO65GNdDmz7TCfGdbE2ehh7HR/g7NCyYoTfQeMWpGPE7HHagFWHlIzQD0nB/0N+9VY4VIl0MY45Sa1UAxh73YWnw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791987058; c=relaxed/simple; bh=kO7lS1SXEhALyFoG03L01lJuVSSoUeXxVu2mGJefl38=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=apgSCbWciGSxvq03tzWzTJN4gsFZJauVT1MZlad4ARwFccrLFdAiI5IDQ5dLDm6BkEsxMN5Sm9LABDLpyz+oPrEniiDRhcT4TDFpoi04MC0tfMnMuSHMPlsVKvvKdA9yRYm1b/tf9O8kJexJqAmv1Y3nL5AmcKnEAQk1ToTIYy0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net; spf=pass smtp.mailfrom=queasysnail.net; dkim=pass (2048-bit key) header.d=queasysnail.net header.i=@queasysnail.net header.b=Ez0GIFIu; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=SEXbQ2op; arc=none smtp.client-ip=103.168.172.149 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=queasysnail.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=queasysnail.net header.i=@queasysnail.net header.b="Ez0GIFIu"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="SEXbQ2op" Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfout.phl.internal (Postfix) with ESMTP id 05C4AEC0247 for ; Wed, 14 Oct 2026 10:10:50 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Wed, 14 Oct 2026 10:10:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=queasysnail.net; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:subject:subject:to:to; s=fm3; t=1791987049; x=1792073449; bh=/+JI/P15xtoRWwZftZOJXqbX3O80Oe58 eo1xQXdfSmQ=; b=Ez0GIFIuvQ4uSFb3yoWwSsbtTHnfVx9V0BJDJrKfytHzb/AF bblNo9J7+Jt1SxOhSHe9bClfYBU1p4eayKDVRPu0k4kAuPgGHAzoBElXC7/NdSnb 3U8elGixGAoGS0vzFl9MYclAitW+mt8cafmDRVN0XOeHttWo2rVUgAQ3AsGLsHjF fPaca0mSsQatlOz3vBz4LRUYv6kVPnr6eS9CtHUVBHUwKMyjpSbBj/Bo+vLnW9cc wFvzwECUrSZwCNCY5NUepqeQWk6uXitcdGQbGvkfnflaSzsHghiyyC6srZTsFUKF nGvsHe6/YzD+2W1xJVEMwD6x9mgPiAiM6lDawA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1791987049; x= 1792073449; bh=/+JI/P15xtoRWwZftZOJXqbX3O80Oe58eo1xQXdfSmQ=; b=S EXbQ2opjT6F6SRve/YrGvbu1mGzGa5jBpGZvIwU/X4HL6t/QtN5Y/YKBbmJgYSu6 8dm8OB1Jn3zty+rU3/AtzNdTzdQ+9ebIwqFMRUTnGvF/35alrnNLM0Imut1xuvzB Kh2C36EIk6gP1I1PdbaoX3QAMs0Idd0170q+ys76E61JuKYpT78201V34aDhfokE abz/nMOnwpnf4aQkxfLzyKNiw6VyTpljkO+j8pJ3VcpgekvWbiRntT8VHTCX39mK He01zv6EP7iCztTxtkwEbkBs+4/cgX6b5XRjkk+stRgEoIhX9NznTjk89lz6HZ9U c65gqbvn/Bx/Hyc0nVKcw== X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=sign d=queasysnail.net a=rsa-sha256; DKIM2-Signature: i=1; m=1; t=1791987049; d=queasysnail.net; mf=PHNkQHF1ZWFzeXNuYWlsLm5ldD4=; rt=PG5ldGRldkB2Z2VyLmtlcm5lbC5vcmc+; s=fm3:rsa-sha256:QxYmII6QW7Ik5byjDDo2yhsHwnkRfzSDcs2jKbwMF9R7eN9 ONAOV+tZcVaQZ0NcFEUwPmphCV/Y/PlC2Iw9k+7pA9nGDT7xKjj2XzLJrC5Otgfq /I81ZgwzNbUVYAKKmO5JEdRZgAlK1zkiBZA7EPrHqEk1aCk29yVlCehju2uMB5Tp bPy1nF8rqxmhWpO/AsEb2ToW3gIVtANPRvMLohGOuVCNGGfa+/zDiKO5r1/kZC84 671MEHril3vF5Yh2ES5hLFUrCuz2WSfnEPTuwrmq6EX4emir0HCf/IDNrWkXzH5l PwwU9aDURrGx8wgvHS4dThGn9032raYcHhhfzmg==; X-DKIM2-Info: draft=ietf-dkim-dkim2-spec-06; repo=github.com/dkim2wg/interop; date=2026-10-04; sw=lmtpprox; action=mi-m=1; hc=13; hn=cc,content-disposition,content-transfer-encoding, content-type,date,feedback-id,from,in-reply-to,message-id, mime-version,references,subject,to; Message-Instance: m=1; h=sha256:STCi2E8jXWRLDUCuCW9p3S/VP98I0v7EaMpPXS1GU7U=:kO7lS1SXEhALyFoG03L01lJuVSSoUeXxVu2mGJefl38=; X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGYMSs3CFqigZbaBLa2eIXfCu/3WqZRg0HZEdFOJt3hYa0TpHT8Z+w00uZvZceQdX qN1Sz2rc17MbyarCihZSadaYzDKIlkaigX0sens0l2o4h57mQ+w4vs2uqtmZGN9cgtMKNN hQLp0HqRoljRuSinF63wdJzJRgGzxPe1s5gWsk3CjKKo2eAzKu9vxlz7QegXCOFM42tP9i hT3aQe4My0iSp9ZjnzZRc4sg7UjRST9Lm/OqzSduh2oG1/Xng/xwFfUhj4O8YBXGbESEjw z7nezSkdWThG3cHen0Hf8wIioUfL3JBcdXBl4ZOzVCAOwV5++/uPo4LAOc2nhIgBuIQgDu Na/Ohbg+Ca4/HNFfQAUmPBkYCrOvAGilhuuSQNc8d7unrLzC4M09VsIvmZsPVyVNYfutbx dGMRf6KvnHMu4UQGWis5VxgeSTakCW8sTDOhrrjYVFRQAY/IT/azUrDFzVGaJROYhPTOWT D0LwCv0iURxjKGJ7SqbJxviylnnwi5SeP6UtWIcTmSScPP/srrzvJzfmDrFddtt6t/qrZM R/Q9HYWd+2l7LEJcOfzFoBAoEBlbKwT7fYPu6pZ+VDxbraf7VrTXi0g18VIFhrzLY9JP0I gQUfuzRK7//IulGszVRcw9uAB/5eT86U5oqrVQhpUcrVaY6++LqJyA3VvHtA X-ME-Proxy: Feedback-ID: i934648bf:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 14 Oct 2026 10:10:47 -0400 (EDT) Date: Wed, 14 Oct 2026 16:10:44 +0200 From: Sabrina Dubroca To: =?utf-8?B?SsOpcsOpbXk=?= Jean Cc: Steffen Klassert , Herbert Xu , "David S . Miller" , Saeed Mahameed , Leon Romanovsky , Tariq Toukan , Mark Bloch , Boris Pismenny , netdev@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH ipsec 4/7] xfrm: prevent AES-GCM nonce reuse after early GSO Message-ID: References: <20260930144523.435271-2-Jeremy.Jean@oss.cyber.gouv.fr> <20260930144523.435271-6-Jeremy.Jean@oss.cyber.gouv.fr> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Jérémy, sorry for the delay. 2026-10-01, 23:07:55 +0200, Jérémy Jean wrote: > On 2026-10-01 15:31, Sabrina Dubroca wrote: > > 2026-09-30, 14:45:21 +0000, Jérémy Jean wrote: > > > In the software ESP offload path, xfrm_output_gso() leaves its > > > segments > > > sharing a secpath extension. Each segment gets its own ESP sequence > > > number, but stores it in the same xo->seq field for IV generation. > > > > > > If encryption is delayed, later segments overwrite the value needed by > > > earlier ones: esp*_xmit() can then encrypt several packets with the > > > same > > > AES-GCM nonce, despite their distinct ESP sequence numbers. > > > > Here again, your commit message could describe much more precisely > > what actually happens. > > > > I'm guessing you mean something that starts like > > > > xfrm_output_gso > > segs = skb0,skb1... all with the same xo > > ... > > xfrm_output_one(skb0) > > xfrm_replay_overflow(skb0) xo->seq = N > > xfrm_output_one(skb1) > > xfrm_replay_overflow(skb1) xo->seq = N+1 > > ... > > > > [and then some more stuff happens that gives them the right > > esph->seq_no but wrong 64b seqno used for the IV] > > > > But please help reviewers trace the codepath you've already gone down, > > without having to guess what you mean. You don't need to give the full > > call graph with the state of each variable, but there needs to be more > > than just the very beginning and the very end. > > Here is a more verbose changelog I wrote for that patch: > > --- > With software ESP offload, xfrm_output() attaches a secpath before > calling xfrm_output_gso() for an encapsulated GSO packet, but > skb_gso_segment() leaves the splitted skbs sharing the same secpath, > including xo->seq. > > For the i-th splitted segment, xfrm_output_gso() reaches > xfrm_replay_overflow() through xfrm_output_one(), which allocates > sequence number N+i to that segment, and then incorrectly overwrites > the shared xo->seq with N+i. If encryption is delayed until all t > segments have been processed, xo->seq ends up with value N+t-1 for all > segments. When validate_xmit_xfrm() calls esp*_xmit() for each > segment, the IV is constructed from the same value N+t-1, causing > nonce reuse in AES-GCM. Yet, each ESP header correctly keeps using > value N+i from its private XFRM_SKB_CB. > > Call secpath_set() for each offloaded segment before xfrm_output2(), > so sequence allocation writes to private metadata that cannot be > overwritten by later segments. > --- Thanks, this is much more helpful. The comment in the diff could be dropped (git blame will guide the reader to the commit message), or extended with "and stores it in the secpath". -- Sabrina