Received: by 10.223.185.116 with SMTP id b49csp5460264wrg; Wed, 7 Mar 2018 12:08:21 -0800 (PST) X-Google-Smtp-Source: AG47ELu6GHTO2b0e+6pWH2V2AHkmctlibQLMOgY8ii5y687rzDjvm2SR1ELlKmD+Lj/m0qgQm+CL X-Received: by 10.98.117.139 with SMTP id q133mr23569673pfc.64.1520453301574; Wed, 07 Mar 2018 12:08:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520453301; cv=none; d=google.com; s=arc-20160816; b=pDsGHAScnp/wtu/w3RMepVCVvWx6yDm0Pgw1fF1tIcg2CsC+p8FTo3C6rwIfEk8/Cp 1SOWKXbdcIYhMnmsxYqKmRHD2mDHa0LQReAkteNpb3t3eyG1Hw4EdKFzbaETh8vv8oON ynmVnjVKWab044SDQrcK94+c892GgEszlqjfpTtmZ3aaTKvO25DCltyoLBk+/w5J8yEe Fu8+6pyGhu8lYo2royBu2tI1crIKiT8E7gN6hAFO+lqSsjFpeScz2WyKs6fh3lIwyiSy XR3aP3tlJkHEYX9MV/gj5guULAi8VLpzDJ5jVdBAKTXyP6+BnzWhUAKJUyNPRdQ29C4K J2uQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=+WSOGJefO0/L0SceZWQpa3/rHUyJ23Qfrvvn/Vye/18=; b=Qn1ExVAVX44weRi+PqTt6ydDAHXo2aSXQOowRYSFkpOwls3cvHDR3k3niUAliqycIn 9yXXK6A7MubFSYvPfGr30B4W9GNw0vw/uxLaSvdORf3DCoNkZY2hmIqXGaqyIQ7vSctP nDTEMROtxe/2sX9dCInIV6llHXEflIzMrdl2UxZDo3dtMgfzRuhAYMzv10tOL3xSfAHu lojg0ILnS5bfJV0u6SiocVPF9BMGzoMExAQrp8cBFSDo5WxGt0O4E8S1qyi7WtnScttL 8n1jb6YRZLK7DUASXSQznIq4L+n0X1FHLR6zaHkZIM1X7bylD9bwRX+cj2GR/zKeKYMU 6+1Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d2si11858366pgc.758.2018.03.07.12.08.06; Wed, 07 Mar 2018 12:08:21 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965433AbeCGTp6 (ORCPT + 99 others); Wed, 7 Mar 2018 14:45:58 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:44356 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965391AbeCGTpx (ORCPT ); Wed, 7 Mar 2018 14:45:53 -0500 Received: from localhost (unknown [185.236.200.248]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 6278FF78; Wed, 7 Mar 2018 19:45:52 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guillaume Nault , "David S. Miller" Subject: [PATCH 4.14 044/110] ppp: prevent unregistered channels from connecting to PPP units Date: Wed, 7 Mar 2018 11:38:27 -0800 Message-Id: <20180307191045.355009414@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180307191039.748351103@linuxfoundation.org> References: <20180307191039.748351103@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Guillaume Nault [ Upstream commit 77f840e3e5f09c6d7d727e85e6e08276dd813d11 ] PPP units don't hold any reference on the channels connected to it. It is the channel's responsibility to ensure that it disconnects from its unit before being destroyed. In practice, this is ensured by ppp_unregister_channel() disconnecting the channel from the unit before dropping a reference on the channel. However, it is possible for an unregistered channel to connect to a PPP unit: register a channel with ppp_register_net_channel(), attach a /dev/ppp file to it with ioctl(PPPIOCATTCHAN), unregister the channel with ppp_unregister_channel() and finally connect the /dev/ppp file to a PPP unit with ioctl(PPPIOCCONNECT). Once in this situation, the channel is only held by the /dev/ppp file, which can be released at anytime and free the channel without letting the parent PPP unit know. Then the ppp structure ends up with dangling pointers in its ->channels list. Prevent this scenario by forbidding unregistered channels from connecting to PPP units. This maintains the code logic by keeping ppp_unregister_channel() responsible from disconnecting the channel if necessary and avoids modification on the reference counting mechanism. This issue seems to predate git history (successfully reproduced on Linux 2.6.26 and earlier PPP commits are unrelated). Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- drivers/net/ppp/ppp_generic.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -3158,6 +3158,15 @@ ppp_connect_channel(struct channel *pch, goto outl; ppp_lock(ppp); + spin_lock_bh(&pch->downl); + if (!pch->chan) { + /* Don't connect unregistered channels */ + spin_unlock_bh(&pch->downl); + ppp_unlock(ppp); + ret = -ENOTCONN; + goto outl; + } + spin_unlock_bh(&pch->downl); if (pch->file.hdrlen > ppp->file.hdrlen) ppp->file.hdrlen = pch->file.hdrlen; hdrlen = pch->file.hdrlen + 2; /* for protocol bytes */