From nobody Mon May 25 07:55:34 2026 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) (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 23DBE4C0439 for ; Tue, 19 May 2026 10:16:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779185793; cv=none; b=qTkkAbNwrPGq4kr4wGqTDlkbMMrr8vvAeNYIM/KjWp2k354kOA7Ak7/+cOq1+/C2CCg3k5tCJFS6btXBPknwgMIRtlf0iF59sBaEcKMrsOdzDcPlWZFkdTVbOgeXfSAV4U1G6TyR28i10eG78aXUSrF1WLUeInvxIoNfaVf9O54= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779185793; c=relaxed/simple; bh=A8lCk64tyDutpdWygpqGjJXORX5zZQ3IQ4DQQhG5Q8o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qwYLI/vJ6ONh/NuZvDcPLpnI0TkqQR4FgKvCgJTPtKlkgXP6Nhi0zkGrjFsN+df93251uh12SByedpx/5mnBf1z1It1ICfWKVxUkxoCiC+0uo6y7GjZnZTjGu6idm+FY9MBCTCatrHpfyh2qz17w+Tts/SoumbJn7oK8ixayyMM= 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=DAG29ITP; arc=none smtp.client-ip=209.85.216.54 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="DAG29ITP" Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-3665b67ed66so2043353a91.1 for ; Tue, 19 May 2026 03:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779185786; x=1779790586; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=a6PE6oczvQzlzFTW3XERm2G8PX98I8qUZJMdLKZ7oFc=; b=DAG29ITPJ/oltyXTun/ebhMLfI83fqgSN5oYsS8vRj/qE1KkpfXMT5DP39bLfwUYKR A6BsCPu6Q7ejgyDVjPGZzdCTDcGFuJbTDWldnF1AIX7qzyQw1hb4iD6DikwQIAm0hk5I Joa75cPtaN+xi+JdCSK5IEGsGP3hy8FzGGDho8DnGsK1oNn69lBhVSWIg845okyayfgN XwH2LITXECyTa/FmUOZYrrP84s1HQ60j6XeEqRarl27x7qAyK8IXwc6qoRQ0vsFFbI+L W1KzxEBC7kFJYAPkvUiusmzN1FbPmLRmNtF5s8svPufgVbe2VqbgnTtzXMgWxtSxoerD dO6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779185786; x=1779790586; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=a6PE6oczvQzlzFTW3XERm2G8PX98I8qUZJMdLKZ7oFc=; b=cJbRKfn0fuVp5aVMtrquqiEPnsG2uWhAmjKSbAZg3CK+mIOPVnz0hq2zAKxZlwFRyA AS8D2wArHyUUZkHFtVyp3nVC/gJ7rSq8tfgooHBrFctI9Bd/7W0S44MSwZgMVuaQLDns OdY16NQFn6Gi/OxMFXBaztJA1gxDpOYIb1VflkFCd7iK2w59Q3Wr95NuIveJoaIGnL5L DfZA5TqfzVLLjR/U9lOe7/NLCNVlsxgOQHVcU8i3hknEqxubOdHakKl7dHS5xN53vMoJ ++rr8jk8X/i8KVoN5RLzfVDymQnEf/wiq9KGiKShEHKGfksNqdjFjicFMI2pGTEUr377 9Ufw== X-Forwarded-Encrypted: i=1; AFNElJ/YM2XAQ91lIJJxneI+nJj2c1hP9hrdGQaBjE1liPqf1ukz1nIj/MAi477eSFwT4Ue38YHoUFhYuF3eSWY=@vger.kernel.org X-Gm-Message-State: AOJu0YyMAYtr8Q0uuRWKlqYSz5c9Bh5V5Fn5mquhI221KnlJHC7ErKHc PFazNiWO7OJuZBEU4SBIOWLPcRpnD4ZU0baSr7YKMf9ceOvX3WTgiJ1c X-Gm-Gg: Acq92OGUnUGVGj0iHtHinRTaiWVpAjL16cqyK0xDKTGb7w+4kNZtrXfboNlH9jhUKAo f927uupRjEqUcBbJMbdk6InYi5Dn2BitRRQ1jteEt80SD5ffmOCpKP8MwSgWJwkqR81c8FMU9aG H9Ayv4qtMWUHl8ij0rhgU1oXB1DmZCm5j3a9eauqaom+xxs59FqS0q3A7bHJJzWzrYaagb8/D65 PtLky/ySRRCL1RfaFOcXFCM1r4tnJAv+Vjn8YQQbu9al/GBVl4UbFrPZ++iQLUiecTe2ADoeUkr RoE5wMSJBwGyF2IR2kSRlW4HujReRcHQDNxW70sMxXnFg5Awoh1aDl1RlMHDwue3mUp77YYQd/X hl2SlYJcDNFigTPyaWo5Ds7NujTzqYkbJAIiYQk9vu/wLf96lb/qnUtNSFvQb6ounZhWoVY0pK9 WKnVRAw3iVKjDejCcoHXVdriLpHQ== X-Received: by 2002:a17:90b:2742:b0:368:cefe:ddd0 with SMTP id 98e67ed59e1d1-36951b82f8fmr19522119a91.15.1779185785623; Tue, 19 May 2026 03:16:25 -0700 (PDT) Received: from fedora ([171.243.49.69]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2bd5d234540sm177683165ad.79.2026.05.19.03.16.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 03:16:24 -0700 (PDT) From: Minh Nguyen To: pabeni@redhat.com, bryan-bt.tan@broadcom.com Cc: sgarzare@redhat.com, vishnu.dasa@broadcom.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, horms@kernel.org, bcm-kernel-feedback-list@broadcom.com, netdev@vger.kernel.org, virtualization@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH net v3] vsock/vmci: fix UAF when peer resets connection during handshake Date: Tue, 19 May 2026 17:16:10 +0700 Message-ID: <20260519101610.233070-1-minhnguyen.080505@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: References: 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" vmci_transport_recv_connecting_server() returned err =3D 0 for a peer RST in its default switch arm: err =3D pkt->type =3D=3D VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL; That made vmci_transport_recv_listen() skip vsock_remove_pending(), leaving the pending socket on the listener's pending_links with sk_state =3D TCP_CLOSE while destroy: still dropped the explicit reference taken before schedule_delayed_work(). One second later vsock_pending_work() observed is_pending=3Dtrue and performed full cleanup: vsock_remove_pending() then the two trailing sock_put(sk) calls -- the first reached refcount 0 and __sk_freed the socket, and the second wrote into the freed object: BUG: KASAN: slab-use-after-free in refcount_warn_saturate Write of size 4 at addr ffff88800b1cac80 by task kworker Workqueue: events vsock_pending_work Treat peer RST like any other unexpected packet type (err =3D -EINVAL). All destroy: arms now return err < 0, so vmci_transport_recv_listen() removes pending from pending_links synchronously and vsock_pending_work() takes the is_pending=3Dfalse / !rejected branch, dropping only its own work reference. This also closes the multi-packet race Sashiko reported on v2: pending is removed from the list before any subsequent packet can find it. The pre-existing sk_acceptq_removed() gap on the err < 0 path of vmci_transport_recv_listen() that Sashiko also noted is not introduced or changed by this patch. Tested on lts-6.12.79 with KASAN: 52/100 unpatched -> 0/100 patched. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Cc: stable@vger.kernel.org Signed-off-by: Minh Nguyen Assisted-by: Claude:claude-opus-4-7 --- v3: - Different approach to Sashiko/Paolo's "trading UAF for leak" concern: normalize RST to err =3D -EINVAL so all destroy: arms take the same err < 0 cleanup path -- no special case, no multi-packet race. - Sashiko's secondary observation ("while not introduced by this patch, does this error path leak sk_ack_backlog slots on failed handshakes?") is correct: the sk_acceptq_removed() gap on the err < 0 branch of vmci_transport_recv_listen() is pre-existing and is not introduced or changed by this patch. v3 stays focused on the UAF; a separate fix for that gap is needed and would be welcome from anyone closer to that area. v2: https://lore.kernel.org/netdev/20260512025851.189140-1-minhnguyen.08050= 5@gmail.com/ v1 was sent to security@kernel.org on 2026-05-10 (not on lore). net/vmw_vsock/vmci_transport.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c index 4296ca1..ba3a66e 100644 --- a/net/vmw_vsock/vmci_transport.c +++ b/net/vmw_vsock/vmci_transport.c @@ -1161,10 +1161,17 @@ vmci_transport_recv_connecting_server(struct sock *= listener, } break; default: - /* Close and cleanup the connection. */ + /* Close and cleanup the connection. Peer RST is treated like + * any other unexpected packet type in this state so that the + * pending socket follows the same cleanup path as other + * handshake failures, instead of being left on the pending + * list for vsock_pending_work() to find later (which races + * with subsequent packets and was the source of a UAF when + * the cleanup work observed an inconsistent ref count). + */ vmci_transport_send_reset(pending, pkt); skerr =3D EPROTO; - err =3D pkt->type =3D=3D VMCI_TRANSPORT_PACKET_TYPE_RST ? 0 : -EINVAL; + err =3D -EINVAL; goto destroy; } =20 base-commit: be48e5fe51a5864566307998286a699d6b986934 --=20 2.54.0