Received: by 10.223.185.111 with SMTP id b44csp919295wrg; Fri, 9 Mar 2018 16:52:24 -0800 (PST) X-Google-Smtp-Source: AG47ELupPBgKtn3pg9L9kZ0rdPEu9uSMW+wiBA/a96uWVf0iuWzkZHQX1J8x87kYfzxW6e3w5JNa X-Received: by 2002:a17:902:8c97:: with SMTP id t23-v6mr396160plo.372.1520643144591; Fri, 09 Mar 2018 16:52:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520643144; cv=none; d=google.com; s=arc-20160816; b=FNMJuPj69m2zGGqXOP/UN92IORmOY+rDT7rv40JGCQwek0AlVWlD1yZe5YEThRq5wk bqaNiGAIJJpxOFH/QnzRfQ1mEYQdEzhTRRSTwVwBma94ocrtrLQTkrLTK5zxORESLYu/ 4/DFcAYQGZGHA1iESLBXck1IJ2e7m9AxDO5S6ZJaCsaKI/SBjomncTRPGW/qBP0HLWKB OsYX/clf9L9gYCQQ87hBtn/cnd53uP81PfugHDQW4qpB5yu2c4L06BdLWTiF0OLnr17D UUqqKcdT7+z9PcXDKD3F60xFtt4Z/eazgSDgIL8laf/VBDmoNDu9tPI3tVkU2xLviSlM rBtQ== 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=utwtOJmo4blI7nGKrVRrAu20WWLBPsMp76IEUwyiXRU=; b=sF7clJGJxsznUkhiinAWITMmGn91Mzsw+ycFGzOySS4FQnbqQvLxpqvupozfIrht9x Thdq5j/9w4hfAhiWULwfeulil0LUlUQGS/qVGKlBC2UlZrAzAjTp3Iv2HMdvlCPUHHOj 63Qh9VV+332izvHkkBuTrzeh4xKVSBAZ/h4Ms7e8Sr8UmYrGGPVXqwOmyiQutC6YbFsB 6uMtbzcaugoWu8kKTM5/QOgB4v8E6SYVj0tE12xCWeB83q/rqhygtiMPrVdB3Kp7I757 tlM+knC6cqAzeH1o5Vq16+dsPYadI9Tmg9tFez4kI+Z9RD3784M+rdU38+GOaqHixOvF 7AWQ== 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 t8si1541336pgo.118.2018.03.09.16.52.09; Fri, 09 Mar 2018 16:52:24 -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 S932973AbeCJATS (ORCPT + 99 others); Fri, 9 Mar 2018 19:19:18 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:38566 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932771AbeCJATO (ORCPT ); Fri, 9 Mar 2018 19:19:14 -0500 Received: from localhost (unknown [185.236.200.248]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 90615EF8; Sat, 10 Mar 2018 00:19:13 +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 3.18 13/21] ppp: prevent unregistered channels from connecting to PPP units Date: Fri, 9 Mar 2018 16:18:35 -0800 Message-Id: <20180310001801.864075868@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180310001801.045114869@linuxfoundation.org> References: <20180310001801.045114869@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 3.18-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 @@ -2908,6 +2908,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 */