Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp10117482imu; Wed, 5 Dec 2018 16:41:44 -0800 (PST) X-Google-Smtp-Source: AFSGD/We+Mp20ro3JKBD/zsUSq/yX1iBSu953yIbagD7kYJncQFx3CndG1gmJWi/PqIv1QvV/9nW X-Received: by 2002:a63:5664:: with SMTP id g36mr22098811pgm.313.1544056904285; Wed, 05 Dec 2018 16:41:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544056904; cv=none; d=google.com; s=arc-20160816; b=yKC2hU+mzaZCiAmf2EhHJWdQzj+syPhNz0qHMyr6G+kdDxx4yRbdsLRRsVGohkYoj5 xVcQpEzKnVfPkeMKYW8NMDQIkm9T7/ROUfu5XtBdsjbAQVK3dUpQlLso7yyb+Z5O6G7c saVUIxuPM3oYq7IEWyDnhZ3HJpaCXzikB05SEgOxCF69nwv2v/c1OyPfAGBCxU4WaoeA soIzHWq+0Bf2WIfDymwIcT2HAOagdUTuBoKBrp1Pxl7q/grZYcp9rv0+CixkMxwBBHVq eeUqaDi1/MuF7fHrDWuj9u2oO0+9jKB0ecjfWr6VPa9iStuJhQdrDvYa1hsyaHU+KEh2 6liw== 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=KiwKGzqqt+AFwO+SDEpAXP1gSa2QVI0d0UKSLTD1gaA=; b=EeJcUekgsfInKNR5lNDISCb043NM2drcQApl3fcHbgB/ihVgPMVy2pQ7c6lk+JzS/Y BSemjpPk5LE9N6pjEcL6QBzfNt2gEI00yQd3SvknARNpns62jFEXcf4GQ7DroK84aKn9 xWcS3VCAey/OveVQ8HluY0tOztr4+WIntQD1sxEH5vX7mxnmC8n4fbt+gSQR2zgkWDQy 1ih7jNzQUaZMyI/dw9Z1AUWTS1z+vxyGcY1xrCFKjHeRE0lJ+boCkrSvquSXY+LqVat9 jot4ro168oRlAtGnmZe+seQAVLnmZmzasIw1iHZqq0PsKbHJUJTYypUjvGkCV36Tk7jk 4u0w== 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 64si21776577ply.372.2018.12.05.16.41.28; Wed, 05 Dec 2018 16:41:44 -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 S1727794AbeLFAkp (ORCPT + 99 others); Wed, 5 Dec 2018 19:40:45 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:57960 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727358AbeLFAkp (ORCPT ); Wed, 5 Dec 2018 19:40:45 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.91 #2 (Red Hat Linux)) id 1gUhiY-00059Q-6c; Thu, 06 Dec 2018 00:40:38 +0000 Date: Thu, 6 Dec 2018 00:40:38 +0000 From: Al Viro To: Todd Kjos Cc: Todd Kjos , Greg Kroah-Hartman , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , "open list:ANDROID DRIVERS" , LKML , Martijn Coenen , joel@joelfernandes.org, Android Kernel Team , Jann Horn , Martijn Coenen Subject: Re: [PATCH v2] binder: fix use-after-free due to fdget() optimization Message-ID: <20181206004037.GY2217@ZenIV.linux.org.uk> References: <20181205211601.75856-1-tkjos@google.com> <20181205220035.GX2217@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 05, 2018 at 04:21:55PM -0800, Todd Kjos wrote: > > How about grabbing the references to all victims (*before* screwing with > > ksys_close()), sticking them into a structure with embedded callback_head > > and using task_work_add() on it, the callback doing those fput()? > > > > The callback would trigger before the return to userland, so observable > > timing of the final close wouldn't be changed. And it would avoid the > > kludges like this. > > I'll rework it according to your suggestion. I had hoped to do this in a way > that doesn't require adding calls to non-exported functions since we are > trying to clean up binder (I hear you snickering) to be a better citizen and > not rely on internal functions that drivers shouldn't be using. I presume > there are no plans to export task_work_add()... Er... Your variant critically depends upon binder being non-modular; if it *was* built as a module, you could * lose the timeslice just after your fput() * have another process hit the final fput() *and* close the struct file * now that module refcount is not pinned by anything, get rmmod remove your module * have the process in binder_ioctl() regain the timeslice and find the code under it gone. That's one of the reasons why such kludges are brittle as hell - normally you are guaranteed that once fdget() has succeeded, the final fput() won't happen until fdput(). With everything that guarantees in terms of code/data not going away under you. This patch relies upon the lack of accesses to anything sensitive after that fput() added into binder_ioctl(). Which is actually true, but only because the driver is not modular... At least this variant (task_work_add()-based) doesn't depend on anything subtle - the lack of exports is the only problem there (IOW, it would've worked in a module if not for that).