Received: by 10.223.185.111 with SMTP id b44csp914948wrg; Fri, 9 Mar 2018 16:45:23 -0800 (PST) X-Google-Smtp-Source: AG47ELttifIbZ7I2uYtriTIMy/kpAHBr2KfsGnJzNtA8z01/s3GCGnJcSsGVVWqM7ATcY4IZr75V X-Received: by 2002:a17:902:8a92:: with SMTP id p18-v6mr371302plo.286.1520642723489; Fri, 09 Mar 2018 16:45:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520642723; cv=none; d=google.com; s=arc-20160816; b=R2bRxK5cVhroVLqyywvY02ct3fxDZR5IGUXnfYXXwf9T6Ema06BZsEqtTmAlreqFFs Yeoni0RIR5B+iiWchhxpe1vpK7RmPdVefB1mKBE7bDBYJAwZfUvr12tAmvmlUT9qQYOT LKJZ4ANA5fGRb4pmIuxL9Ie9zY5u1cxrtpfNrCxTfMIP6fJKDVzPPzBBMp7si+zrJMri UxuXb3vhvGbWIhHTHuPe+YSmUBUFOEK1iPqj86DeoCVBGR8CD2RjqtG2ek4GSQB7wsLY Ig5i8wrnBvJH5a/hDSzZfCNe2T5gSHv26bf+c/OH3vTM2lrmlZAd8THo4iGglezitlJj LMAA== 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=S2kFmgmgNaEDsKm7i1bsRqW4lgUx+q5wiYYQBXtQs1U=; b=w9CY4EWrdMg2hAzdvhVdGjV+4XML82AJ5x6af5+kxVQA5P/YwcRxBOjKkDcCUZYCyT 5r0BonW/qeOcPni2iozb2fmLmlFC1DZzGpvkvS3+pJhY26E3OhZzIMCoGlfgBHb3bKcf STiyQI37q20PgZ9NGRtCOyvq6yNzFiSXJb8cjuczy6f8qTfu1GSzV3Ly010NF91YBBqd kRjwyKSSXxoLtZiQC+2QxEdr1VGSKTwnXfjp6tTMuRqSHLVklalvtzKlLLASFUYKpc0l WT57NAPV2lRP3KFhM77rMPNW/Zc5GRS46PrlTRZTUJCdYImyZHQ7oAyMQfw6vA/TvGwf fEtA== 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 p11si1480986pgs.537.2018.03.09.16.45.09; Fri, 09 Mar 2018 16:45:23 -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 S933439AbeCJAUb (ORCPT + 99 others); Fri, 9 Mar 2018 19:20:31 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:39170 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933138AbeCJAU3 (ORCPT ); Fri, 9 Mar 2018 19:20:29 -0500 Received: from localhost (unknown [185.236.200.248]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id B6BF6F4D; Sat, 10 Mar 2018 00:20:28 +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.4 25/36] ppp: prevent unregistered channels from connecting to PPP units Date: Fri, 9 Mar 2018 16:18:41 -0800 Message-Id: <20180310001808.741475823@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180310001807.213987241@linuxfoundation.org> References: <20180310001807.213987241@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.4-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 @@ -2952,6 +2952,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 */