From nobody Mon Jun 8 22:51:23 2026 Received: from mail-yx1-f48.google.com (mail-yx1-f48.google.com [74.125.224.48]) (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 8314431355D for ; Tue, 26 May 2026 02:52:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.48 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779763931; cv=none; b=VjTxBoO29HlzwXI0yRJH57qlAQaBZhL3yl0AvRxZgfhBcv81V86OMfTP4hoA2nJz444N0h0A+dsXGy14sODo31hyrbyeUbD4XjgS+KrI4iFJF5n6/ewPDSZP1RcScpw2D0u+WTR1T83ctk9xjZLicSQBbQjKcFk+Ss2c8OAvris= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779763931; c=relaxed/simple; bh=o9wMTxhYiDKmflOFYsWj2G5+KhuWu2fGjh/QrAEnzwA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=DMyXhLABs8bVFukKnuVMUdGIh00j60C2PnHya/MipdeJcDBMeIsJZCSOR5FgQ7h03MrDw1np3JcIImN6xZ9FVb+NW+k1bFojC3bhEbb8YQd+zzXJt3CmLmueUhPaGXd8pQO6u2Rqq8of/01TsnAP2vQ2zR4pn7T2zG8Huuuxwfw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=northecho.dev; spf=none smtp.mailfrom=northecho.dev; dkim=pass (2048-bit key) header.d=northecho-dev.20251104.gappssmtp.com header.i=@northecho-dev.20251104.gappssmtp.com header.b=TEbOSmrq; arc=none smtp.client-ip=74.125.224.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=northecho.dev Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=northecho.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=northecho-dev.20251104.gappssmtp.com header.i=@northecho-dev.20251104.gappssmtp.com header.b="TEbOSmrq" Received: by mail-yx1-f48.google.com with SMTP id 956f58d0204a3-65c30aabe8dso914957d50.3 for ; Mon, 25 May 2026 19:52:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=northecho-dev.20251104.gappssmtp.com; s=20251104; t=1779763928; x=1780368728; 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=naGseeLsZOt5/A5Mc1MGjXdOC/ihUE1Cs3gNHn6WygY=; b=TEbOSmrqKq3smUDcMdEMyNVgqupAbh3DDq0dAoGy9owBXUAEFgnpDhtzgn5FbS062k Ks+Ha2gHno4vvvrvN1o2Fwle9wjNrpSOasnJ6UVdCeMtV3dNDNqrs3BpYn9oqvpmKaZ3 PY3MJ+ItyQ+Z+miQU6l3S3HFbDklKhxRVoh/6CjB/QA0boj4eFh19/k4pPZW7AI877BJ RvCwnXWzkO8FG5ZvKLwk04dxb3LX+CRk7ifKP28TIXv/BuW8G5RNzgB5yRTRoMkhYkoY XquAleCLQ8+Hods1tjYaHw/tALUfDRh1MCb8QwWjlCskWWQKH69foWgSDGtHWCKXwBeT DlbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779763928; x=1780368728; 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=naGseeLsZOt5/A5Mc1MGjXdOC/ihUE1Cs3gNHn6WygY=; b=f16u/BN/2GIl/4YVL0GB744s5RHK+5GI6VbInv4csKjqfCB8ES9Q5hW+UE5n+Gv9hv FHjp5pIki2EXKgegG/pj8mSi8yXbC0PlUc1o32G+IMNboA3jEVkrdVE332RNyKpmnaw5 DoW7PH2fMYFfYUn+JavnfgB2VFTuJYOhTRw/kMd3xWba3ByKQ3RXuZpiXdZ33pZWIMCP O9NhU+9kZXySTlmDevWtsFq3iEqohu4+9NaNV+Ri35t0xpg9MITh2XwnDxgfTIKy2lSN E+O0R+4BGypqF5+Fjo4ShYNyw658VfX3yv5qlQYpFJiiZi0eganMGvyIMddWAljfy3E5 i3Sw== X-Forwarded-Encrypted: i=1; AFNElJ98nHHrJBgk4KzO7B7YhjK+HeoFPQuMvx//FtqqwE0K/+rP6Pb2ZdZhl1VEG2WAFcg60EGc94bKqFXJ66M=@vger.kernel.org X-Gm-Message-State: AOJu0YyWGEBLlos8myJdZqLZ4D0qZw36o+kT7ziA9/hjpLI6iyVORs2p OmdPAkuyUTSY0yHYUZU+ZKuvmG6XY27mkSJ2JfjrTdkadldAvSzZBBx8QW9TkRdeGKsV X-Gm-Gg: Acq92OHjvu0o8/ToaYNBLbjweJuqMa53zXZpiT7kr56bP+6zVLZV5e1gkpiHa/SUWxq qsbQfvM+Feo/RFhxLcNdTNPqWlN1RkpjBpuMdTlnapBFBW65Ki+4c4kshCUgQqZJVAPNfyTk2Y4 mpdwcYR5Jwc+3Zvry9b3RcDqB6WaYeISbymNiZ6VoV4u5/EepTzV0aK9tUN2FSg3Z0K59xnVbtY cmtsHdqq/Nh5ST/C9VfUlievL/T28h+hniffWITTKHMIblPfAtZets4UZwWY5mBV9v7ZlDI66vb xVzoMvMmHKkz9+Qj8SnMd0yPpSCqeOWOE1X16zIYlZDLt7LvfhDr3ti2/d434tvY4kvIBhwW7D9 eZ8P0Uh22IxtQ+Izg0zlYfptqnKIdyL0JS7/ImYniMOpkqAfeMNXSe4lYhL44R25ZaRDwvHcgNN 2qYF0gD/CxlXIOFqiG0x78ukq4nn2+pep9NydCJOhgJb9JuCG8SXgMMz4R4AeIEQs+l8CX8PMl2 P7oSBXUzZKv/sc= X-Received: by 2002:a05:690c:f:b0:79a:8e00:a5bf with SMTP id 00721157ae682-7d3373a7a95mr124613927b3.1.1779763928408; Mon, 25 May 2026 19:52:08 -0700 (PDT) Received: from kelso.tail8e61da.ts.net (99-10-92-174.lightspeed.rlghnc.sbcglobal.net. [99.10.92.174]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7d38c33c935sm54938797b3.36.2026.05.25.19.52.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2026 19:52:07 -0700 (PDT) From: Christopher Lusk To: Jakub Kicinski Cc: John Fastabend , Sabrina Dubroca , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Alexei Starovoitov , Daniel Borkmann , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH net v3] net: tls: use sync AEAD for sk_msg BPF sockets Date: Mon, 25 May 2026 22:51:54 -0400 Message-ID: <20260526025154.60607-1-clusk@northecho.dev> X-Mailer: git-send-email 2.54.0 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" The kTLS TX path can hand an open record to a sk_msg verdict program before encryption. If the verdict applies fewer bytes than the open record contains, tls_push_record() splits ctx->open_rec into the record being encrypted and a remainder. The synchronous path reattaches that remainder before continuing. With an async AEAD provider, crypto_aead_encrypt() can return -EINPROGRESS after ctx->open_rec has been unhooked but before the split remainder is reattached. The remainder is no longer reachable through ctx->open_rec or ctx->tx_list, silently dropping transmitted data and leaking the unreachable tls_rec. The same composition also entangles the user-page zerocopy lifetime rules with an async completion path. A sockmap cannot be attached to a socket after an inet ULP is installed: sk_psock_init() returns -EINVAL when inet_csk_has_ulp() is true. So the supported ordering for sockmap + kTLS TX is sockmap first, TLS_TX setup second. When TLS_TX setup sees an existing sk_psock, allocate the AEAD with CRYPTO_ALG_ASYNC masked out and latch the TX zerocopy gate (sw_ctx_tx->async_capable) so the buggy composition becomes structurally unreachable. Ordinary kTLS sockets without sk_msg BPF attached are unaffected and continue to use async-capable providers. Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Cc: stable@vger.kernel.org # 4.20+ Signed-off-by: Christopher Lusk Assisted-by: Codex:gpt-5.5 Assisted-by: Claude:claude-opus-4-7 --- Changes since v2 [1]: - Per netdev maintainer guidance [2], replace the Option-C drain-on-error fix with a setup-time surface narrowing in tls_set_sw_offload(): when a sockmap is already attached at TLS_TX setup, request a synchronous AEAD (CRYPTO_ALG_ASYNC in the allocation mask) and set sw_ctx_tx->async_capable =3D 1. Both moves are needed: latching async_capable alone disables zerocopy but tls_do_encryption() can still return -EINPROGRESS on the copy path; selecting a sync provider removes that return path for sk_msg-attached sockets. - Drop the selftest from the series per Jakub's note that the existing sockmap + TLS coverage at tools/testing/selftests/bpf/prog_tests/sockmap_ktls.c exercises this configuration [3]. That suite covers sockmap + kTLS policy paths broadly; the specific async-pcrypt pass-then-drop failure mode from the v2 reproducer was validated for v3 on QEMU/KVM with a KASAN+LOCKDEP-instrumented kernel against net base 2156a29aecff before send. - Single-patch series. Changes since v1: - v1's remainder-rooting fix was incomplete; Sashiko AI review surfaced a real UAF in the v2 follow-up that John Fastabend endorsed on the v1 thread [4]. The surface-narrowing approach in v3 makes both failure modes unreachable by avoiding the async + sk_msg composition entirely rather than patching each continuation point. [1] https://lore.kernel.org/all/20260521025840.976378-1-clusk@northecho.dev/ [2] https://lore.kernel.org/all/20260525133028.58494274@kernel.org/ [3] https://lore.kernel.org/all/20260525133048.2dc6d8d3@kernel.org/ [4] https://lore.kernel.org/all/huduxtn6parzgiaf5cyiyrrvjjvx6jsdedowvrd4nkw= muyeind@j6migjgofh2i/ net/tls/tls_sw.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 964ebc268..0000000 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -2867,7 +2867,20 @@ int tls_set_sw_offload(struct sock *sk, int tx, rec_seq =3D crypto_info_rec_seq(src_crypto_info, cipher_desc); if (!*aead) { - *aead =3D crypto_alloc_aead(cipher_desc->cipher_name, 0, 0); + u32 mask =3D 0; + + if (tx) { + struct sk_psock *psock; + + psock =3D sk_psock_get(sk); + if (psock) { + mask =3D CRYPTO_ALG_ASYNC; + sw_ctx_tx->async_capable =3D 1; + sk_psock_put(sk, psock); + } + } + + *aead =3D crypto_alloc_aead(cipher_desc->cipher_name, 0, mask); if (IS_ERR(*aead)) { rc =3D PTR_ERR(*aead); *aead =3D NULL; -- 2.54.0