From owner-freebsd-net@freebsd.org Fri Jul 20 21:26:03 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D590C1052EF7 for ; Fri, 20 Jul 2018 21:26:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 66EE88DCE6 for ; Fri, 20 Jul 2018 21:26:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 26E1D1052EF6; Fri, 20 Jul 2018 21:26:02 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0200C1052EF5 for ; Fri, 20 Jul 2018 21:26:02 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 922738DCDF for ; Fri, 20 Jul 2018 21:26:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id E7AFF8D13 for ; Fri, 20 Jul 2018 21:26:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6KLQ0tD056712 for ; Fri, 20 Jul 2018 21:26:00 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6KLQ0u0056711 for net@FreeBSD.org; Fri, 20 Jul 2018 21:26:00 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: net@FreeBSD.org Subject: [Bug 181741] [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2)) Date: Fri, 20 Jul 2018 21:26:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jilles@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 21:26:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D181741 Jilles Tjoelker changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jilles@FreeBSD.org --- Comment #15 from Jilles Tjoelker --- I consider the issue brought up in comments 11 and 12 a blocker. The patch "[PATCH 3/4] uipc_finalizecontrol: read-lock the unp link" introd= uces a change not mentioned in the commit message: datagram sockets always behav= e as if the LOCAL_CREDS socket option (UNP_WANTCRED flag in the kernel) is set on them. That change seems a bad idea to me. Apart from the general problems with sending unsolicited control messages (full buffers, code that examines only= the first control message if only one is expected), the specifics of SCM_CREDS = make this even more dangerous. A strange thing about SCM_CREDS is that there are= two flavours of it: one containing a struct cmsgcred, generated when the sender explicitly attaches an SCM_CREDS message, and one containing a struct sockc= red, generated under certain conditions when the receiver has enabled the LOCAL_CREDS socket option. If a struct sockcred is attached, a struct cmsgc= red (if any) is removed. The two flavours have incompatible fields, but are not reliably distinguishable in the general case (if the application programmer even knows about this problem). Therefore, behaving as if LOCAL_CREDS is set when it is not may cause applications to receive a struct sockcred and interpret it as a struct cmsgcred. For example, an application trying to read cmcred_uid for the real UID will get the effective UID from sc_euid. This is likely to allow an easy attack since a plain write(2) from a setuid root program (such as an error message) will have the struct sockcred attached to it. The patchset does seem to fix the bug that adding a struct sockcred for LOCAL_CREDS silently does nothing if m_get() or m_getcl() with M_NOWAIT fai= ls, possibly leaving a struct cmsgcred from the sender. The patch "[PATCH 3/4] uipc_finalizecontrol: read-lock the unp link" also a= dds a comment about a bug that UNP_WANTCRED may be cleared by a failing send, so that no struct sockcred is ever sent on the connection. Since this only aff= ects stream and seqpacket sockets, I think it is best fixed on the application s= ide, by using getpeereid(3) or LOCAL_PEERCRED instead of LOCAL_CREDS; this also simplifies the application code and makes the credentials more reliable (si= nce they are from connect(2)/listen(2) time instead of from the write). Related, if UNP_WANTCRED is cleared then struct cmsgcred from the sender wi= ll get through, which might lead to a struct cmsgcred being interpreted as a struct sockcred. --=20 You are receiving this mail because: You are the assignee for the bug.=