Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1348674imm; Wed, 23 May 2018 14:40:13 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoGLyJ9QbYGTN7r+jJCzC9Yme23gHt1J/MzIPqLyrPX4Y67N9BzcECVHYwFDKMR5Bq4jPMV X-Received: by 2002:a65:51c4:: with SMTP id i4-v6mr3558731pgq.190.1527111613096; Wed, 23 May 2018 14:40:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527111613; cv=none; d=google.com; s=arc-20160816; b=GmBdvyyZQxWybtTC83IA+T6xHlICXl1IgXGF+Mo7ieRRU8t5hTthGp9c/q7Cl9vdg+ k5G4YKiH9hscuxSi5t6POwuMoFRnAZ+2l3YsNaYInTqGB63qNkCEmPYbG7Vlp7QZMKBw YGIasR0IHsbwLIx12lK1xFTR8xcJanQ0/9M6oPdhWZj1DB8CUw0218dA3RYx2q8KfIvf xjo7/os+L4JVrhid8BMmliRXXxZs7TULAJfUVFxHhApjAsMz55ULnT/NHgOA15vcvs+C fYOgfyakgBk3qCcQkC7QKQ7d+ToZLre2AeBBlmiwAF9HDaUYikfC/nWI3itg6pnIh3Oi eNaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=VMTZZUEgqHVVzTCuesEIOdmmoVXtNUW1xgyr7giHWgo=; b=qcivwcI1Gthhlde/9Q4Z7RyUFlaopGGg+iZeb89LUhNBsFpUY8gaHs+MRjsXSbujch ZrptThAdqDNAxxW0Fq2o++Va/NNFEuDoxce7/s6qxQvwjZVJaxG1t2qZLSgpJodnEI0Z 5wpcdYfCS0gQRS8IdbFksIVL444m1plXrHNWteYne/EDDlskzTC3ZArTeMYQFlQCt6us G3xoJWUogK/AfAEpGYIA3xW3zqRIdMnZQFBES6oOYQJmt4l7slL8XiG9jiFZqdQY9heQ UFy2EjqgMvmIxNfNrjSYfFlKe9UyoxilH5WbGotFEyrEZmtlsfIgYAjy/AXC2vBra0xU Qbew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hGu9EOl3; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a81-v6si18967883pfj.300.2018.05.23.14.39.57; Wed, 23 May 2018 14:40:13 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hGu9EOl3; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934439AbeEWVjs (ORCPT + 99 others); Wed, 23 May 2018 17:39:48 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:34258 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933066AbeEWVjn (ORCPT ); Wed, 23 May 2018 17:39:43 -0400 Received: by mail-pg0-f67.google.com with SMTP id k2-v6so9998900pgc.1; Wed, 23 May 2018 14:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=VMTZZUEgqHVVzTCuesEIOdmmoVXtNUW1xgyr7giHWgo=; b=hGu9EOl35Df3Ksp3BEnnnf3MNUqd4NzbAFjoE1L6DLv9vKqT3P/rEp6looxkWMKdYb TLxvtKE2lz92J5SlxTa8VrAQUZWJDa4ZW5+Jm3aooemaRSeejSD/ITatn38+0aLZLUIc J7WyHrtL5OMz9KIxqanPmG8rGfVK7MWPoRSoCpUFqIxZgQv7ckiVp+eAghKM6za911FZ CjWdvlCL+G0/PsOBVIqtCOMoA61MQzCFMuQbst3aYAeD7Ro9M6K4M0FdgBvFXwTSt8Xv jLrCuJbmJVYcPgtBA68n6B3HL+Xw3jY7kIdaHFkG2arAtys3XNZH3GfHnJvJDyLplcWV KEyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=VMTZZUEgqHVVzTCuesEIOdmmoVXtNUW1xgyr7giHWgo=; b=SkfPp4xt9ZQpVOWQwzeUlpRfdVu2ND0WiU918dW/2qmDeChT9W3aKgVPS7aHI/bkWf Gba0ObqfkcPS0+J9xhDDvOmh75n1i/k5F9iUrgAx0NOMHT1WekCadohQQclLGofzWkI0 QlTE9a/r3V3sTMoRY5GNiF/lmgv0rj6covWZwuXSvzmVAHW69R5OTAzcPNKEEZ0X3S9E RNQt+3O4dGlus0Vg3C8hqy4+KQK8yxjghJURLJb3oiYonluJwBj5t5pIiMbOsGDSUP8t GaM/Kn/pHCjiybzI425g4hK9T8MmPTg/oLEBcrivHPOeeasGhKgKeEb6cGQ0wCn9Tjen bhRA== X-Gm-Message-State: ALKqPwe1kyUK1e1t/P992tUF7s+vjRwjzzpokvpR3Ct8O1PdpyyWP3rC sHTfdOx6uHoZ0A28ZnJgzJUfZFfR X-Received: by 2002:a65:410d:: with SMTP id w13-v6mr3588729pgp.111.1527111582196; Wed, 23 May 2018 14:39:42 -0700 (PDT) Received: from ebiggers-linuxstation.kir.corp.google.com ([2620:15c:17:3:dc28:5c82:b905:e8a8]) by smtp.gmail.com with ESMTPSA id f17-v6sm25285737pgt.71.2018.05.23.14.39.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 14:39:41 -0700 (PDT) From: Eric Biggers To: linux-ppp@vger.kernel.org, Paul Mackerras Cc: netdev@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Guillaume Nault , syzkaller-bugs@googlegroups.com, Eric Biggers Subject: [PATCH v2] ppp: remove the PPPIOCDETACH ioctl Date: Wed, 23 May 2018 14:37:38 -0700 Message-Id: <20180523213738.146911-1-ebiggers3@gmail.com> X-Mailer: git-send-email 2.17.0.441.gb46fe60e1d-goog In-Reply-To: <20180523035952.25768-1-ebiggers3@gmail.com> References: <20180523035952.25768-1-ebiggers3@gmail.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Eric Biggers The PPPIOCDETACH ioctl effectively tries to "close" the given ppp file before f_count has reached 0, which is fundamentally a bad idea. It does check 'f_count < 2', which excludes concurrent operations on the file since they would only be possible with a shared fd table, in which case each fdget() would take a file reference. However, it fails to account for the fact that even with 'f_count == 1' the file can still be linked into epoll instances. As reported by syzbot, this can trivially be used to cause a use-after-free. Yet, the only known user of PPPIOCDETACH is pppd versions older than ppp-2.4.2, which was released almost 15 years ago (November 2003). Also, PPPIOCDETACH apparently stopped working reliably at around the same time, when the f_count check was added to the kernel, e.g. see https://lkml.org/lkml/2002/12/31/83. Also, the current 'f_count < 2' check makes PPPIOCDETACH only work in single-threaded applications; it always fails if called from a multithreaded application. All pppd versions released in the last 15 years just close() the file descriptor instead. Therefore, instead of hacking around this bug by exporting epoll internals to modules, and probably missing other related bugs, just remove the PPPIOCDETACH ioctl and see if anyone actually notices. Leave a stub in place that prints a one-time warning and returns EINVAL. Reported-by: syzbot+16363c99d4134717c05b@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers --- v2: leave a stub in place, rather than removing the ioctl completely. Documentation/networking/ppp_generic.txt | 6 ------ drivers/net/ppp/ppp_generic.c | 27 +++++------------------- include/uapi/linux/ppp-ioctl.h | 2 +- 3 files changed, 6 insertions(+), 29 deletions(-) diff --git a/Documentation/networking/ppp_generic.txt b/Documentation/networking/ppp_generic.txt index 091d20273dcb..61daf4b39600 100644 --- a/Documentation/networking/ppp_generic.txt +++ b/Documentation/networking/ppp_generic.txt @@ -300,12 +300,6 @@ unattached instance are: The ioctl calls available on an instance of /dev/ppp attached to a channel are: -* PPPIOCDETACH detaches the instance from the channel. This ioctl is - deprecated since the same effect can be achieved by closing the - instance. In order to prevent possible races this ioctl will fail - with an EINVAL error if more than one file descriptor refers to this - instance (i.e. as a result of dup(), dup2() or fork()). - * PPPIOCCONNECT connects this channel to a PPP interface. The argument should point to an int containing the interface unit number. It will return an EINVAL error if the channel is already diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c index dc7c7ec43202..02ad03a2fab7 100644 --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -605,30 +605,13 @@ static long ppp_ioctl(struct file *file, unsigned int cmd, unsigned long arg) if (cmd == PPPIOCDETACH) { /* - * We have to be careful here... if the file descriptor - * has been dup'd, we could have another process in the - * middle of a poll using the same file *, so we had - * better not free the interface data structures - - * instead we fail the ioctl. Even in this case, we - * shut down the interface if we are the owner of it. - * Actually, we should get rid of PPPIOCDETACH, userland - * (i.e. pppd) could achieve the same effect by closing - * this fd and reopening /dev/ppp. + * PPPIOCDETACH is no longer supported as it was heavily broken, + * and is only known to have been used by pppd older than + * ppp-2.4.2 (released November 2003). */ + pr_warn_once("%s (%d) used obsolete PPPIOCDETACH ioctl\n", + current->comm, current->pid); err = -EINVAL; - if (pf->kind == INTERFACE) { - ppp = PF_TO_PPP(pf); - rtnl_lock(); - if (file == ppp->owner) - unregister_netdevice(ppp->dev); - rtnl_unlock(); - } - if (atomic_long_read(&file->f_count) < 2) { - ppp_release(NULL, file); - err = 0; - } else - pr_warn("PPPIOCDETACH file->f_count=%ld\n", - atomic_long_read(&file->f_count)); goto out; } diff --git a/include/uapi/linux/ppp-ioctl.h b/include/uapi/linux/ppp-ioctl.h index b19a9c249b15..784c2e3e572e 100644 --- a/include/uapi/linux/ppp-ioctl.h +++ b/include/uapi/linux/ppp-ioctl.h @@ -106,7 +106,7 @@ struct pppol2tp_ioc_stats { #define PPPIOCGIDLE _IOR('t', 63, struct ppp_idle) /* get idle time */ #define PPPIOCNEWUNIT _IOWR('t', 62, int) /* create new ppp unit */ #define PPPIOCATTACH _IOW('t', 61, int) /* attach to ppp unit */ -#define PPPIOCDETACH _IOW('t', 60, int) /* detach from ppp unit/chan */ +#define PPPIOCDETACH _IOW('t', 60, int) /* obsolete, do not use */ #define PPPIOCSMRRU _IOW('t', 59, int) /* set multilink MRU */ #define PPPIOCCONNECT _IOW('t', 58, int) /* connect channel to unit */ #define PPPIOCDISCONN _IO('t', 57) /* disconnect channel */ -- 2.17.0.441.gb46fe60e1d-goog