Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp696544ybl; Fri, 9 Aug 2019 12:17:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqy1rWTWkCGRH00aQ2qahJCbu3Lksa3SG7A/hfht+iBN0iXnYeLD+lNOCkI3OSoAloik+Uc0 X-Received: by 2002:a17:902:20e5:: with SMTP id v34mr17525242plg.136.1565378267104; Fri, 09 Aug 2019 12:17:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565378267; cv=none; d=google.com; s=arc-20160816; b=jdmuiJ1+xiLrfSsziNt6SABRfY1VlqBN3dQBKwKKCsO3Kih6VUAlOcRWgF9WtwXHmy sMtZ6q6oSkjSREv/xyRGaE0M9FXMucgBnwOl0V/VWg3534lG9k+P3Rn7ITvYIacj32J5 KV5I85soSUO4QOdTKKAYzX3k/KiQOa2QOKATZpisHs2esxU2y/wuplyoDtVLURM/5E3+ RB+JL1dH8tynvrcUs4mJUg4oPq62k6hMHKoWvFjzG1IYY05AdEmQDJZv5Q2lhsfdCCgI Jbr2q8EFLGk5X1nYU4ZMoTu7ShpIySynkY4QxutxbzUyjdd9pIUSZ6AQtCe/T7taLKKp AxSw== 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=Ic045yuTMJqNtEvp0UPxfPFxicA8Y/kIgyeG7/K5TD0=; b=KUMiQJaa51+s8tUCrSpfvI7WWcS1zCV9sMsxv47FqQ9yXoFf52M/zfAy7aXdJEJnw8 ufRXcqzf1Mghhav89SMFQLAwcgW75ZyVHBR0YevyMRa+GZ53a8IUdf9Xo+31oEm4RzZb /vQ1VBOrVU2qtzklYQHwAj09rThnDadK1N3OF1XZYqLvOjm7bJJS9XIiJMSbEKdHrIba dmtfmUzKtAaU/dicSG9q8FB7ibkRWVbkIIENECM3HNQ+b5Sz8HiwYPYKlthfVRTUbUjH 34wb5XBLsC4cmtsgZIBEFZh+QGAbzSOWWfA1XW7W0CAh1A7UdHTv3Iwe8WzQS1yUn1Bn drHA== 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 bj12si50065172plb.378.2019.08.09.12.17.31; Fri, 09 Aug 2019 12:17:47 -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 S2437256AbfHISOu (ORCPT + 99 others); Fri, 9 Aug 2019 14:14:50 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:40378 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726601AbfHISOt (ORCPT ); Fri, 9 Aug 2019 14:14:49 -0400 Received: from 96-95-199-68-static.hfc.comcastbusiness.net ([96.95.199.68] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1hw9PZ-0003Wb-Cz; Fri, 09 Aug 2019 18:14:45 +0000 Date: Fri, 9 Aug 2019 20:14:41 +0200 From: Christian Brauner To: Greg Kroah-Hartman Cc: Hridya Valsaraju , Arve =?utf-8?B?SGrDuG5uZXbDpWc=?= , Todd Kjos , Martijn Coenen , Joel Fernandes , devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v3 2/2] binder: Validate the default binderfs device names. Message-ID: <20190809181439.qrs2k7l23ot4am4s@wittgenstein> References: <20190808222727.132744-1-hridya@google.com> <20190808222727.132744-3-hridya@google.com> <20190809145508.GD16262@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190809145508.GD16262@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 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. 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. Christian