Received: by 10.223.185.111 with SMTP id b44csp909324wrg; Fri, 9 Mar 2018 16:36:12 -0800 (PST) X-Google-Smtp-Source: AG47ELtGcsH8xawfd3Y1Ss3ue7zQdSbKOeUyYSkKQcmQu9u5dO9ASZLYcOywA6HT2Fpoj16n5peO X-Received: by 10.98.28.202 with SMTP id c193mr336418pfc.109.1520642172157; Fri, 09 Mar 2018 16:36:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520642172; cv=none; d=google.com; s=arc-20160816; b=RR8sltDzVJpjk4yUIlxYsK5ufzjJPM8NiO92jDF7Eb/oJirYDWBHv5cYw0n8VZyZ1x nFmiuJZZjBjB+jJTUuHsRzywmwghUGG3Ib/dI9Qbh6thT+AN4z4/dwsM5nf9NZQe51KK X9I3+extc4SpAA5o/zl1I08wG+6Xh2q7OFXEBr1hduZJ+gErjoVCHJ82GOcRb3jrpPAw cshyCzgkYxN392o5lNaYYZhukIpvpJ9dj8+RjOngFl8IgW+XFyWfTtSda/WGJZEKnlnz 3O1Hx7QlhSjLwMUrZ+V/EYjJGzINGUSfH7TZ+NuhVO2G423AyfGSfrfcMFcN8Isj9sjo Ycpw== 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=SGzH0W28TEH7Uc0dNkvzptp+25JvZJBtZift+pOWSAk=; b=Pao4Chy+7Vn0WoL5V/Fsm+d6daYOAFGd6wL1yVw6H+bhNd/DbGX14pxQyqVs9QQz7r Xj3U69KF89Nl6feA0tWHGzgSKI6Mpzf6LfCybTPCiaBkSQ8sAn+3IO7fV0pjsDJLQiI1 Ywh+BjjTv9I2uFTgH2kJwEbU4flHTrkQ+P9Z/XQZOZhxwN+cBE4447RCnuqTDvKj68bW xcKcJj6dK4LAbsdD4cyzMx4bdvSTrptiEbbGlxXJ76Vhelo1yHN6BEmHiyGZ/vn6MRLz X+xh+YdG77oJS/rYgc8HxhAEHcQm1DThei1Vah3Df7xu6aXitovnSnVDgh0APWmQeWJc Cxxg== 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 i66si1476482pgc.445.2018.03.09.16.35.57; Fri, 09 Mar 2018 16:36:12 -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 S933827AbeCJAWF (ORCPT + 99 others); Fri, 9 Mar 2018 19:22:05 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:39842 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933511AbeCJAWD (ORCPT ); Fri, 9 Mar 2018 19:22:03 -0500 Received: from localhost (unknown [185.236.200.248]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id A42D4FE0; Sat, 10 Mar 2018 00:22:02 +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.9 40/65] ppp: prevent unregistered channels from connecting to PPP units Date: Fri, 9 Mar 2018 16:18:40 -0800 Message-Id: <20180310001828.239056622@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180310001824.927996722@linuxfoundation.org> References: <20180310001824.927996722@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.9-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 @@ -3157,6 +3157,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 */