From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.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 C0D304582EA for ; Fri, 14 Aug 2026 11:02:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705331; cv=none; b=dYsVq2FBvBYB8nZTEvnRCqhvBragGbO94FH/xvWjg2So7Zb8S/tE5+FpY55uj5HgiFUvjM0Eub9rXQeucWiMAAwJqc8l5fkUEP0Qf8Mq4UhHMd+sm2GS8HVJy1ulecB33ccj1rkfSi4fhY7N6IHb2V+E9Lcv8zjVKg/LJSp3qp4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786705331; c=relaxed/simple; bh=+bWiNOik+q50L+Rqo4L0aat23qr7vzWhlqwMS6QFHZ8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=aFpZpHWS35bfg6Gc4hz+1oHt5516nrOV0mnhy5ioN137KsgxrRzeqF+Rwrpskw5UNkku2179tgKTouO5J4GQ+18NR2PeUNS3ClVcn6O4QBUFcjNQ98uqB69qbcwOjRml8n3Mn7adlSpoXTjwK7nnf/wAewhL9fwyZSCMLq7BQQs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=doyensec.com; spf=pass smtp.mailfrom=doyensec.com; dkim=pass (2048-bit key) header.d=doyensec.com header.i=@doyensec.com header.b=P6HhFqwP; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=doyensec.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=doyensec.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=doyensec.com header.i=@doyensec.com header.b="P6HhFqwP" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4980dc26022so9289405e9.1 for ; Fri, 14 Aug 2026 04:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=doyensec.com; s=google; t=1786705323; x=1787310123; darn=vger.kernel.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:from:to:cc :subject:date:message-id:reply-to:content-type; bh=+gRbGCV0XxLdSaF9vYVqo8y9b5Wisj9Pp825VEoZ6Mw=; b=P6HhFqwPciepmA87l8MnANTlMFqBizlX/AdJjhmjqeEnVcHABgd5vMuuYAYPTQgSUJ hQSypaVHw6bAzkTs/wA53kIKCk6WsQeloxMNQJkmHWYfmeCEOB39Y57+6SBVJb1U7AFo axuNFbibpeXAwQfLS+xNx66DSGqccwpELiCLoEfziUraWRfqt2vX4/vvapVt6+fXDI7u 4fqvAmC1nqMYkQg6qK8YqwxgaRCtskxCi2z1sSVhn1RhLGJn1HbgYYYD2Md1HVtPcL/g SwacYOf3EafwUF5pj1nwSnpkIss5F/yo/B0ZzKWe8RthQeeR0xW2Hki+ghMsoxt4W3YG CrvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786705323; x=1787310123; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:content-type:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+gRbGCV0XxLdSaF9vYVqo8y9b5Wisj9Pp825VEoZ6Mw=; b=jIeQQu6xWDb+jVvzU1wyFGmUSz49JNUUU12x48hSam2Scc4Gwq2nifZ73LtK9DWY2q VuN9GVFlZ5qFqkjhimT/66+EuE1SdmkHwle3HR2d+WaIds7BZOHhuXXsW3UHP9iS8yvD h/uHhuLNPDatMc7LDmxIwqHr2Zi3lX97BKkBlUAMz1sjfazQXmGHm3e5OZiF6PCmso4s 4YyXMk64x7Dp1DqiZKMzkaK56MNELq9eeLR+jHdLwOMmhgNHg2lUEoXYa9DlypmGumh9 SuX7I0unvu4LcecUMcLnU7UZbA8k1Cb7r48QAGm+kctaf/YKkFHSAsjNBJY1ge76Fwzg MjXw== X-Forwarded-Encrypted: i=1; AHgh+RrMlrXMk52tulZwvf4CpfHnsKVCf/woxo4bEIpdsQiYSRZC5EwourwWNPDJuqFZD69dUec9bNVD1e6ms6U=@vger.kernel.org X-Gm-Message-State: AOJu0Yw6YyXg/KsyYYfQqB2qNtfMBKnJ3lvy983q3lXvsZ4lIxfxWRrS vk+P9H0ZafdrUNC7N6abGfFwAdXYrjvK/VaG74XW/1Yee3TBaEMOe4zGUa1ehtr8nBI= X-Gm-Gg: AR+sD13srUDUpMq1JUT0HV9zQBVSYxUvSYxtZ0ZqD3OxSZbiHx5Dc5TEA9TpUmmd6mQ GTi0/nHcBRmKgcq+Us+YeJXPwrnyiAoIL6zpnaWmxlJRHsyqZJNDQMIsM1eEh6iZJoV88JQ2vKw 1CzxbpbqRQ978GC1DjtU/Ibr6DNRsNgrjyJfhQE/6RNEzJZq7SzexiviRgRyzO/4YtT/IachQbf uauUuqp3wxxXO+xIxXcj4JxZ8Dl+pRN1TbqxfqjIp9Ab3f+gVKi0fZyhH3ui8PVP5OEDoVwgQgi a7jGb+LUfyH/QrBnA7dxJxdBEcBLOoYSy0zN6oJrb88kfscdNtw+P71L1NlFIsPF5J1hnEpVCoC lnHyDa+UXLojslfJmeW39NvctdevyjiKNIyfQG/kctY5Maq2Z0U+hg7Q3T26IaLjtf26qSJg8Qs xXT+Um0qh9rBDTrjTETVIC9XZeuL+fOa/eh2cZl0ANmY5r3WYTIgqk8KsEpReJiq+3V6fWSLXZF MqgLIm+q+CqFQYKKMtKi4HKy9p0dQlvg/HQE4YvqENv+dg52aGHzb8z9nuMTWdQzlAsGRHXgArt ow47WQ/ptpSoOWFb X-Received: by 2002:a05:600c:1395:b0:499:872b:abd4 with SMTP id 5b1f17b1804b1-4998797684cmr58239365e9.6.1786705322547; Fri, 14 Aug 2026 04:02:02 -0700 (PDT) Received: from smtpclient.apple (ip-88-212-19-42.antik.sk. [88.212.19.42]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499899afa39sm24363595e9.2.2026.08.14.04.02.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2026 04:02:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81.1.4\)) Subject: Re: [PATCH net 1/2] openvswitch: only skb_tx_error() a packet we are about to drop From: Norbert Szetei In-Reply-To: Date: Fri, 14 Aug 2026 13:01:50 +0200 Cc: netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Aaron Conole , Eelco Chaudron , Steffen Klassert , Kuan-Ting Chen , Zoltan Kiss , dev@openvswitch.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <741D4072-50EE-437B-BFC3-CDFE94C93F8A@doyensec.com> References: <8063260C-05C9-4997-B9B6-2135063C4858@doyensec.com> To: Ilya Maximets X-Mailer: Apple Mail (2.3826.700.81.1.4) Thanks for the review. Sashiko flagged that the moved call may still be reachable through the RECIRC action, and I confirmed dynamically that it = is. With 1/2 applied, a flow matching recirc_id 0 exactly, with actions RECIRC(1), OUTPUT(0) instead of USERSPACE(unbound), OUTPUT(0), = reproduces the same issue. So please hold off on 1/2. Moving the call to the "default" branch assumes that branch only sees a packet the datapath owns. For a non-last OVS_ACTION_ATTR_RECIRC, clone_execute() does skb =3D last ? skb : skb_clone(skb, GFP_ATOMIC); ... ovs_dp_process_packet(skb, clone); so a clone lands there while do_execute_actions() carries on with the original. The clone shares skb_shinfo() exactly for the skbs this series = is about, since skb_clone() -> skb_orphan_frags() returns early on SKBFL_DONT_ORPHAN and does not copy the frags - so settling the uarg through the clone clears SKBFL_SHARED_FRAG for the skb still being forwarded. Removing the call, as I originally suggested, does fix this in my = testing. If you would still rather keep it, how would you prefer to solve this? Thanks, Norbert > On Aug 13, 2026, at 12:00, Ilya Maximets wrote: >=20 > On 8/13/26 7:47 AM, Norbert Szetei wrote: >> queue_userspace_packet() borrows the packet skb -- it only copies it = into >> a private netlink message (user_skb) and does not own it; on return >> do_execute_actions() keeps forwarding it through the flow's remaining >> actions. Its error path nevertheless calls skb_tx_error(skb), which = via >> skb_zcopy_clear() does skb_shinfo(skb)->flags &=3D = ~SKBFL_ALL_ZEROCOPY, >> stripping SKBFL_SHARED_FRAG from that live skb (skb_tx_error()'s = kerneldoc >> says "skb must be freed afterwards"). >>=20 >> For a MSG_ZEROCOPY skb carrying page-cache frags, SKBFL_SHARED_FRAG = is >> what makes esp_input() skb_cow_data() before in-place AEAD; once it = is >> stripped a later local ESP-in-UDP delivery decrypts in place over = pages >> the sender does not own -- an unprivileged page-cache write (the >> "Fragnesia" primitive). >> do_execute_actions() ignores output_userspace()'s return value, so = any >> action after a failed USERSPACE upcall inherits the stripped skb. >>=20 >> Move the skb_tx_error() to the flow-miss drop path - the "default" >> branch of ovs_dp_process_packet()'s switch(error), before = kfree_skb(). >>=20 >> The call has been here since commit 36d5fe6a0007 ("core, nfqueue, >> openvswitch: Orphan frags in skb_zerocopy and handle errors") but was >> harmless until esp_input() began relying on SKBFL_SHARED_FRAG to gate >> in-place decrypt; only then did stripping it on a still-forwarded skb >> become a page-cache write primitive. >>=20 >> Fixes: 36d5fe6a0007 ("core, nfqueue, openvswitch: Orphan frags in = skb_zerocopy and handle errors") >> Fixes: f4c50a4034e6 ("xfrm: esp: avoid in-place decrypt on shared skb = frags") >> Cc: stable@vger.kernel.org >> Assisted-by: Claude:claude-opus-5 >> Signed-off-by: Norbert Szetei >> --- > Reviewed-by: Ilya Maximets