Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp527804ybe; Wed, 4 Sep 2019 03:45:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqw2PHJXEjAgYhfpRuqJyY6Pf+SQgLl8GDE1tfn3mBZGHdCrMMALT6yRGH6+ONoV8YO0lizE X-Received: by 2002:a63:5d54:: with SMTP id o20mr34940442pgm.413.1567593953853; Wed, 04 Sep 2019 03:45:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567593953; cv=none; d=google.com; s=arc-20160816; b=Gzzbzm7gkFLuYflyV75jUNLvHo0DsMuIDgjnae2QTudemfk21N6GVrY4HTlhL2sF6q QuB8cM6NiQDzC8jol15WNtEOTiJ0JZ+vBPh/s1mQRjvSQyZjQ4JrenAoqkkoqMPSGVSf F/xqB31qvYF0GPPwOK1gtlWrWw4v7F6VBVTeOsT8/DfQTZ8z9k4FM3zdqCRoxOO9CTe4 oBBYJR6vM/Jf/zj/6trBNzVyEvmCNF4Ppv8xnUAJpNROMSAMa+nSoMxakUC1pdt/ybiR jwlqqH1KS06rZabxKwGKyd1Ngnm0ALDeURFS55jZ5pPlW1KbulByFF/g6RNqON4a5E3u Baeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=tEQAo3P+0n32iJ/x9GmQKgHwl5+RcmP3rVUrGq4IhgA=; b=RVOsa5X9Vl7R79G6Crvt4YG+wn6BGwqVj3S3xQfa5Vg4iX7fy8pVoph3xFtG1CEaD8 I2mjVhSDXLlh/g3zjQhVJSgotrDNY7dqXRmX7ZB2jvpMNdoi7CDyFOwfUYgnjXXAMYIX urMwaPckcRV5rXgwYRcuug1tQSlQchbCVV/8epJznj6DTQRxNkW5ZiEXi2cEFVvrMvUH qDX/OhmxhXdJIKOf6vHusB7ek8jJNgxMBT+sX5KBEeRbQNHgjVL4S9Q3j1L28HLiZkil Al0scAZ/QgULwHWbFpQIiF2pB8Cn0OaBGmy1+gQiGDuVKrhQoslbpjs29lbdbGncbGdX mH1w== 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 k8si16977714pgt.548.2019.09.04.03.45.38; Wed, 04 Sep 2019 03:45:53 -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; 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 S1729709AbfIDKok (ORCPT + 99 others); Wed, 4 Sep 2019 06:44:40 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:49509 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729644AbfIDKok (ORCPT ); Wed, 4 Sep 2019 06:44:40 -0400 Received: from [213.220.153.21] (helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1i5SmA-0001Xk-H3; Wed, 04 Sep 2019 10:44:34 +0000 Date: Wed, 4 Sep 2019 12:44:32 +0200 From: Christian Brauner To: Greg Kroah-Hartman Cc: Hridya Valsaraju , devel@driverdev.osuosl.org, kernel-team@android.com, Todd Kjos , linux-kernel@vger.kernel.org, Arve =?utf-8?B?SGrDuG5uZXbDpWc=?= , Joel Fernandes , Martijn Coenen Subject: Re: [PATCH v3 2/2] binder: Validate the default binderfs device names. Message-ID: <20190904104431.ehzyllugr6fr2vjz@wittgenstein> References: <20190808222727.132744-1-hridya@google.com> <20190808222727.132744-3-hridya@google.com> <20190809145508.GD16262@kroah.com> <20190809181439.qrs2k7l23ot4am4s@wittgenstein> <20190904071929.GA19830@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190904071929.GA19830@kroah.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 04, 2019 at 09:19:29AM +0200, Greg Kroah-Hartman wrote: > On Fri, Aug 09, 2019 at 11:41:12AM -0700, Hridya Valsaraju wrote: > > On Fri, Aug 9, 2019 at 11:14 AM Christian Brauner > > wrote: > > > > > > On Fri, Aug 09, 2019 at 04:55:08PM +0200, Greg Kroah-Hartman wrote: > > > > On Thu, Aug 08, 2019 at 03:27:26PM -0700, Hridya Valsaraju wrote: > > > > > Length of a binderfs device name cannot exceed BINDERFS_MAX_NAME. > > > > > This patch adds a check in binderfs_init() to ensure the same > > > > > for the default binder devices that will be created in every > > > > > binderfs instance. > > > > > > > > > > Co-developed-by: Christian Brauner > > > > > Signed-off-by: Christian Brauner > > > > > Signed-off-by: Hridya Valsaraju > > > > > --- > > > > > drivers/android/binderfs.c | 12 ++++++++++++ > > > > > 1 file changed, 12 insertions(+) > > > > > > > > > > diff --git a/drivers/android/binderfs.c b/drivers/android/binderfs.c > > > > > index aee46dd1be91..55c5adb87585 100644 > > > > > --- a/drivers/android/binderfs.c > > > > > +++ b/drivers/android/binderfs.c > > > > > @@ -570,6 +570,18 @@ static struct file_system_type binder_fs_type = { > > > > > int __init init_binderfs(void) > > > > > { > > > > > int ret; > > > > > + const char *name; > > > > > + size_t len; > > > > > + > > > > > + /* Verify that the default binderfs device names are valid. */ > > > > > > > > And by "valid" you only mean "not bigger than BINDERFS_MAX_NAME, right? > > > > > > > > > + name = binder_devices_param; > > > > > + for (len = strcspn(name, ","); len > 0; len = strcspn(name, ",")) { > > > > > + if (len > BINDERFS_MAX_NAME) > > > > > + return -E2BIG; > > > > > + name += len; > > > > > + if (*name == ',') > > > > > + name++; > > > > > + } > > > > > > > > We already tokenize the binderfs device names in binder_init(), why not > > > > check this there instead? Parsing the same string over and over isn't > > > > the nicest. > > > > > > non-binderfs binder devices do not have their limit set to > > > BINDERFS_NAME_MAX. That's why the check has likely been made specific to > > > binderfs binder devices which do have that limit. > > > > > > Thank you Greg and Christian, for taking another look. Yes, > > non-binderfs binder devices not having this limitation is the reason > > why the check was made specific to binderfs devices. Also, when > > CONFIG_ANDROID_BINDERFS is set, patch 1/2 disabled the same string > > being parsed in binder_init(). > > > > > > > > But, in practice, 255 is the standard path-part limit that no-one really > > > exceeds especially not for stuff such as device nodes which usually have > > > rather standard naming schemes (e.g. binder, vndbinder, hwbinder, etc.). > > > So yes, we can move that check before both the binderfs binder device > > > and non-binderfs binder device parsing code and treat it as a generic > > > check. > > > Then we can also backport that check as you requested in the other mail. > > > Unless Hridya or Todd have objections, of course. > > > > I do not have any objections to adding a generic check in binder_init() instead. > > Was this patchset going to be redone based on this? No, we decided to leave this check specific to binderfs for now because the length limit only applies to binderfs devices. If you really want to have this check in binder we can send a follow-up. I would prefer to take the series as is. Btw, for the two binderfs series from Hridya, do you want me to get a branch ready and send you a PR for both of them together? Christian