From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) (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 7A6693DCDA2 for ; Fri, 15 May 2026 05:04:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778821493; cv=none; b=dw5hVeCO2KOzWvNIwwsJlcJMW+bnkbL2Peo/IzPQGef7N8Dt524bllW1Y4x6QCsc31oMlfhB1qdNAkLpLJs31rxqH0gX/wWkJObAYG5R0MHp2jTDKjVZOr/u2L/EailmzAxjSqjafy6b2yyyF9ItS77b9gLWublhrdv67Gp1hPU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778821493; c=relaxed/simple; bh=LE8jfo45c+SRwiSVqT2/Y0314N5ZIYQwpVi4AglxEfA=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=GUEej3vYsyN51c38wRoEcCEDxdbjEmz0aTlXyUKvPk19ap0pdtGs9FVE0zxoq/yF9rIv2iTzIx+oJ43XX4M1ePqjewh8KwMVe2jqmfxc6ZydWANh27huWeXqMza5uDL4jHZbSrmsisYxVMEOKII72ttxV96aJG/Atg533OJIfaQ= 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=D4QTrN7P; arc=none smtp.client-ip=209.85.215.193 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="D4QTrN7P" Received: by mail-pg1-f193.google.com with SMTP id 41be03b00d2f7-c6dd5b01e14so4174554a12.0 for ; Thu, 14 May 2026 22:04:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778821492; x=1779426292; 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=MDkpadn+ZjaKcKAsJOyp81emebQ7DUn9DAmh7WWqOus=; b=D4QTrN7PD1+oEKiUNYqxgR6J366MMhDtyJ+JYW0kcNKsWypaLjkETtulk2EdPwf3W9 Q2F2+ijWPXcekrxR31bqYEK4pshu8dL1Ut093yyD0G1+kCbAoF/2DtmgL62gdXGftvO/ 8j/ZFG7RYgTsEKysbLS2v1z359E4rL9GIrIltW8+QIItRK6rEUKSK8CH6Wzj13Q3dQOf M4BhtUd2KBqCfpecKwfCUxkIQo1cUit6aW1sh+ZZuQZ4dj1g6MkzdcSEc7PuiYU22G+d ErVJeNNXdDznoojXLA9fasljsaXnuMUzfFXcVuHanUrOnEtnTuqK5fTO7PQ+iYp3ZcBC Ukuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778821492; x=1779426292; 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=MDkpadn+ZjaKcKAsJOyp81emebQ7DUn9DAmh7WWqOus=; b=YlazdR/7UJ5f4OevFmXrmAZC6+wUNv0NTOrnJlSWB6QDcUhRBuC61FhYF/B0aoDSFg 4QnhO2idAx2RSXg1ff3W5yw54R88hxq4K+TVvb2Cd0aQfKIXN1nA2AOF/l3dp5Tpgot/ 1GGorX3E0rGDU8iwkDLxdlMBVKO6GDScvKECyz+5us3Nj6vYDERWdDQ54NSyricp7cu3 5P/m3cGoIfcAwqLbhLF88Ra3a9UCYNTFudlU0VP+eSs50HxwrK+JxTxm//YY1xnuOJUB 8Wg7SxdphSbVvw6NUDclwadR20o4MwsoGVdw4h0TZJb+YRunmd9GCNrDbK3EutkocXM4 cK1A== X-Forwarded-Encrypted: i=1; AFNElJ/RFFe7KdDBQFDQvPKNWH7Cs4DdNIpOb/3e2UpnX6h3CFDHShT5ioFZ5qq28UrDo258BG4vw7zE9+UPjsc=@vger.kernel.org X-Gm-Message-State: AOJu0YwOU/40HSvpBDbO7871AjrEqMXsHC2z3TDB70jGfYJi8h19c50s 8qrViuvLLr5nfg67TK446E6cn2MI7tUMGJ+LQ9HrpE5iZvj5rj3LzZqWKYagXnLTtp8= X-Gm-Gg: Acq92OHZLqido8yNBp+zWjmmZVAALsFVr0aS26SAU/TyrpYt9sLTLJkRejCB/CL4q/e Q9pey4XAlVJEcxBl7kVk0JLe97KsUleVha12Zj+WaDjHhzkNWbPJzicDn79IgogHME4e5URSJFg K1qOub3ObFG7x6adTy5C3K+WEOHCoWuQpiSAaGX93S4IX6Qv2CgWf2da3Z5VIi4a8lweeLJwXen Vpdh0JLOrAwB/E/vD956FIp9l34I808i07iNibepyqrHdteN50D2F4UVwRa/ouP5UFqnr6qlht3 Ef5BMyvoK7PyLS0U88T77B49bbOtjr2gLXuasBbgBUYuPFYaaQeb0Bs5Loem0coc5lTis5SicQI /k5zWVxWfKAhBDlwY1T04RrlFhCKgIyva7tbzB/BCq63iUXRuRxCj74pVb+z8gm+z55g30Zl+O3 PrI+2hTeGI/fZr+YRxI4OBagFKdEdeAC0= X-Received: by 2002:a17:903:1a8f:b0:2b7:86be:7673 with SMTP id d9443c01a7336-2bd7e85fce5mr27404215ad.6.1778821491625; Thu, 14 May 2026 22:04:51 -0700 (PDT) Received: from localhost ([111.228.63.84]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bd5d234540sm44205615ad.79.2026.05.14.22.04.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 May 2026 22:04:51 -0700 (PDT) From: Zhang Cen To: John Fastabend , Jakub Sitnicki , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, zerocling0077@gmail.com, 2045gemini@gmail.com, Zhang Cen Subject: [PATCH] net: skmsg: pin the delayed-work psock in sk_psock_backlog Date: Fri, 15 May 2026 13:04:37 +0800 Message-Id: <20260515050437.104716-1-rollkingzzc@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit sk_psock_backlog() recovers the psock it operates on from the delayed work item, but it takes its lifetime reference with sk_psock_get(psock->sk). That reloads sk->sk_user_data and can therefore return a replacement psock after the old psock was detached and a new one was attached to the same socket. In that case the worker locks and drains the old psock, but the reference it acquired belongs to the replacement psock. The exit path then puts the detached old psock, which can underflow its refcount after the last unlink while the replacement psock keeps the leaked reference. Take the reference on the delayed-work psock directly with refcount_inc_not_zero(). If that fails, the old psock is already being dropped, so skip the detached backlog instead of processing or putting it. This keeps the worker's get/put pair on the same psock whose work_state, ingress queue and state bits it manipulates. The buggy scenario involves two paths, with each column showing the order within that path: path A label: detach and reattach path path B label: old backlog worker 1. The last unlink drops the old 1. Delayed work resumes from the psock into sk_psock_drop(). old psock embedded in work. 2. sk_psock_drop() clears 2. The worker still sees sk->sk_user_data before the old SK_PSOCK_TX_ENABLED on that TX state is cleared. old psock. 3. A new attach publishes a 3. sk_psock_get(psock->sk) replacement psock on the same reloads sk->sk_user_data and socket. refs the replacement psock. 4. The old psock is still queued for 4. The worker locks, drains and delayed backlog work. finally puts the detached old psock. Sanitizer validation reported: Non-fatal target warning: refcount_t underflow/use-after-free warning from refcount_warn_saturate triggered by sk_psock_backlog putting the detached old psock after last_old_ref_before_put reached 0. use-after-free Signed-off-by: Zhang Cen --- --- a/net/core/skmsg.c +++ b/net/core/skmsg.c @@ -684,12 +684,12 @@ static void sk_psock_backlog(struct work_struct *work) if (!sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED)) return; - /* Increment the psock refcnt to synchronize with close(fd) path in - * sock_map_close(), ensuring we wait for backlog thread completion - * before sk_socket freed. If refcnt increment fails, it indicates - * sock_map_close() completed with sk_socket potentially already freed. + /* Hold the delayed-work psock itself so teardown synchronizes with + * the same object whose work_state, queues and state bits we touch. + * If the refcnt is already zero, this psock is being dropped and its + * detached backlog must no longer run. */ - if (!sk_psock_get(psock->sk)) + if (!refcount_inc_not_zero(&psock->refcnt)) return; mutex_lock(&psock->work_mutex); while ((skb = skb_peek(&psock->ingress_skb))) {