From nobody Wed Oct 29 15:23:09 2025 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4cxWGN74vlz6Dryb for ; Wed, 29 Oct 2025 15:23:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R12" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4cxWGN6RnTz3QVW for ; Wed, 29 Oct 2025 15:23:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1761751388; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=w+k1h4GRqmXTBTy5GSVJVYNa4PvSD+Z/lsSdgEJYWeU=; b=eyJZp4zIIgynxr+Ra/N2b/uC114BMcvnZuLUH/5leFuxGgdvImxE2GoWAS8E+ZPTEfx72a M3UjDLYqH7tRU3TvHbLjUqG4p1PT/G1C/voYE5g4fBncJZKU+JB1hWZB7JowIj2zInprB0 6TJu9r2YNSI+Vp5C5lfu7J0WcyJioi1FWtk2aKpxHsYMc0KK25Po44z8qpeedxwsWb7LOW VtmX7DsfZIL/DD4WXfCMCjSieF8AaRdeehFh/VbDbpRMvQUasgYuPv0W7Os1BMS3KSpCkU 42osdweLvo/3vzEru7Ew+nHYW47QoY6V40llY6uuaHwT2sU6ReDwmHIVKJhtzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1761751388; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=w+k1h4GRqmXTBTy5GSVJVYNa4PvSD+Z/lsSdgEJYWeU=; b=cgnm8SfG30U6iR23JyQm8NhhExYsFKh9s0rMNjDqwrSFXWAOOxFP4x1zsyjLpPTikE6a84 yo1eXib7Kzk1Kwja52RdeEPO7cb8AxyYl1ylQ+xEgQ7Zc87KJEpalaPelAmCKvutEyWIGt Rl+HVtBPvYnhZ0BV1TAorzG28liztijF3x/1uchW5VJZ1JtdL3b82hgQ4VgXDjNY99Sx47 sFu2lnpjLc1qzgY2zbbYfuwvdzoJKD3tA1Yr67FTBlKRtWarw5RsRbBqrg1xfoPfMjKWTl l7bb1GUmErRy6ovSY/kH3Im6asd+7R4uJYvfabUWxn8/ZFbZo0NaDTFGcGMpMQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1761751388; a=rsa-sha256; cv=none; b=Gpe3t1mhsCdxUjdea0XWsIdqyh+pl/EhJYg8K4ehH7WH/QQuD26rrQ0wLciONJ8H1YCKIy CeghJaB5q/Hn5/MKI6jDEZh/z1YVgVb56hGBtYap8Ny776vaRgaFfPgzf9MITBFPbZSn2L vcRWVXf7bfR0xi6pilHrpQIUgkk5kCrfwLhtmmwNjbGjj8+AvuX2kZa4qfeNXvnJbOZ16H juKv6rLjrh2ldbitydRHti1WgkfC9sIyvXbkc2eKYEC+6VaVDS8CnjWO94kx+/BlMwFB/Z yAQVUmZwagUPeP4On4WUIhmtKqVjqOBCnFfLURNcbyqBlf5q1H/Gj71+ZbUkog== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4cxWGN5zF4zjG7 for ; Wed, 29 Oct 2025 15:23:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 59TFN83U046779 for ; Wed, 29 Oct 2025 15:23:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 59TFN8sB046778 for bugs@FreeBSD.org; Wed, 29 Oct 2025 15:23:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 290658] race condition in SOCK_SEQPACKET unix sockets Date: Wed, 29 Oct 2025 15:23:09 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 15.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D290658 Bug ID: 290658 Summary: race condition in SOCK_SEQPACKET unix sockets Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: markj@FreeBSD.org Suppose I try to read from a SEQPACKET PF_LOCAL socket with MSG_PEEK set. = We find the extent of the mbuf chain whose contents we're going to return: 1482 if (m->m_flags & M_EOR) {=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1483 last =3D STAILQ_NEXT(m, m_stailq);=20= =20=20=20=20=20=20=20=20=20=20 1484 lastlen =3D 0;=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1485 flags |=3D MSG_EOR;=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1486 break;=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20 1487 } Later, we loop over mbufs in the socket buffer and stop once we see "last".= =20 The problem is that we drop the rx socket buffer buffer lock before that lo= op.=20 So, if "last" is NULL, and the sender adds new a new record to the buffer before the loop (possible because the socket buffer lock is not held by the receiver), then we will return more than one record's worth of data: 1632 for (m =3D first; m !=3D last; m =3D next) {=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1633 next =3D STAILQ_NEXT(m, m_stailq);=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1634 error =3D uiomove(mtod(m, char *), m->m_len, uio);=20= =20=20=20=20=20=20=20=20=20=20 1635 if (__predict_false(error)) {=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1636 SOCK_IO_RECV_UNLOCK(so);=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1637 if (!peek)=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 1638 for (; m !=3D last; m =3D next) {=20= =20=20=20=20=20=20=20=20=20=20=20=20=20 1639 next =3D STAILQ_NEXT(m, m_stai= lq);=20=20=20 1640 m_free(m);=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1641 }=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 1642 return (error);=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20 1643 }=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 1644 if (!peek)=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 1645 m_free(m);=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20 1646 } That is, the "m !=3D last" check only works as intended if last !=3D NULL or MSG_PEEK is not set. If last =3D=3D NULL, then we will traverse the whole = socket buffer. More generally, this pattern is sketchy: how do we know that some other rou= tine isn't going to free the mbufs out from under us? The recv I/O lock synchronizes with other recv() calls, but there are other uipc functions li= ke uipc_sendfile() which fiddle with the receive buffer without that lock held. --=20 You are receiving this mail because: You are the assignee for the bug.=