Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp10146923imu; Wed, 5 Dec 2018 17:17:45 -0800 (PST) X-Google-Smtp-Source: AFSGD/VfiXXeHM6A3AHcKTIkeSWurUWLNuEzMQHsZBAEkV4TSL6LeBIm9MlojrKYDRNcn1n4t4n7 X-Received: by 2002:a17:902:45:: with SMTP id 63mr25277802pla.272.1544059065563; Wed, 05 Dec 2018 17:17:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544059065; cv=none; d=google.com; s=arc-20160816; b=sUqg+DHy8uvqRKYZc+pcX3xacKB0P1SsEqHgBPV7cqNo26xa3m+47h07PgKvRxyXVT //uijjLhwgFmrQjKcgVcSirAWZqU3MJRttrBkxajnstV5yGPkflVgs6+iP/MMNj7xtU5 BrqN5EMHoh5xwlvfegE++xjqVXlSfyy5JrrW4slxxhstwBxLIhewLTNMwk4IwcjBbnIk jTZuggioUv/1Ze0zwNeXxEcVjKuUAmW0Hg+BZs3to6skCsIYz0dynEWSDcAmM1JYGGxw smQA6tqDqD9ACEbHjAoi1fJmTL75AZepl3qzoR+GPIH+tii9sfGWIn/08a6+CarFiVwl 8MUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=bIARKccRROJyBU5Mh9PmrAjL909xKUQSNocjbfI8E6E=; b=L7Cgvl/WyzlEBUMichkHwF3BjQ1WYLTUONhNVMOAKiZcnNdWZcMMU/JRLal2lblyCs z5DsHWCvEwaK7js2Ky1DH6iBIWSyRJ3W+aVIXjEUtFNatmggS3vrFYWYBYRxnqGpNxUG wEU7BVH/P1Z49WdBfXGafn8P2sOE1W2CkU2Hmpnc5aJRp+jgHdmIdDolbLggL0NaNGel RPQLVaTFRX0BzeNqKIaipSUwgsAxuEdNOUH7NCvPdu6Zlqf4RF8JZokJoZdTGqSLyCQ5 9aXnrFricxH6PKCw3bG6Pr/B8AagwmtCe4cPbJ1o4JguveUkGI4UHTMi9uN/umur8JNH Uqag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iai2qTMt; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id cd2si24257465plb.39.2018.12.05.17.17.30; Wed, 05 Dec 2018 17:17:45 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=iai2qTMt; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728294AbeLFBQy (ORCPT + 99 others); Wed, 5 Dec 2018 20:16:54 -0500 Received: from mail-lj1-f194.google.com ([209.85.208.194]:43793 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727575AbeLFBQx (ORCPT ); Wed, 5 Dec 2018 20:16:53 -0500 Received: by mail-lj1-f194.google.com with SMTP id 83-v6so20120277ljf.10 for ; Wed, 05 Dec 2018 17:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bIARKccRROJyBU5Mh9PmrAjL909xKUQSNocjbfI8E6E=; b=iai2qTMtOM8VOZ7kMdaTQD3Hsu/UFlS16DiPdoN35yz7UjPUzt7t/FcI+M2m9JtvjX YQW1og1PWWwh38b8qJsrKywGewkXHwfHpInp/oqHKlGfW4iiLWmXGeap2Y4zD858x7In KUbDvkbqY0VVV4vr+MN/kijZ6rsNqKa/bh1ISdlQk0pszzl3qApaFOp5WAucRVC+S71H TDfPd7vKZKm7Z2ApMfDqpNlDp9x4VQcfZ+grIrBEA/ksbkbUdNePWpPeTJc+CLacZ9wD erw+0cze30tbUqMtreQAbHoVq9b4ljnsbrXyoNMymEhV9u3hQf0GYUkCdTP9rd+FrKkH ogYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bIARKccRROJyBU5Mh9PmrAjL909xKUQSNocjbfI8E6E=; b=URKEgBe/3Yolnh8wX8g/CNBIFZalr14YZRAFsBmAu4qPEIDF5iKE0W/StR9ZHBJTsS zFUctxj2cc8rwqEvGZaywoKIdOdasuw85btL5UzPbokAiAbSy/M/8jUulody1BV2XAd1 PW8h7973w9G5/flyrma7vUvU8YN99nxovqNJ5C9f1aZdq/ncqN4p0p809gq2RouHBNPx M67yMDV35HIQ7PyR9JJsZv5L3yz23jQqwMJl5c3IgbRv3xFxTuZ6TRt+QbIRhzq2UAwe qfr5+1+sNUMLtxngq53J7hiA2wEwMjn9/yEx6f/4mkyR785cw5KDdTEq4EgTNWW77ezA kXJg== X-Gm-Message-State: AA+aEWaiVmtuukKxOObL8D/VjplYaNnRsfVFmLUCFZ+peXqllD52jJP0 Fy0WZMLRPu1tH6KJzkd98TfU6bpRDY4tuEMy6uNGSA== X-Received: by 2002:a2e:890b:: with SMTP id d11-v6mr16667579lji.113.1544059011201; Wed, 05 Dec 2018 17:16:51 -0800 (PST) MIME-Version: 1.0 References: <20181205211601.75856-1-tkjos@google.com> <20181205220035.GX2217@ZenIV.linux.org.uk> <20181206004037.GY2217@ZenIV.linux.org.uk> In-Reply-To: <20181206004037.GY2217@ZenIV.linux.org.uk> From: Todd Kjos Date: Wed, 5 Dec 2018 17:16:39 -0800 Message-ID: Subject: Re: [PATCH v2] binder: fix use-after-free due to fdget() optimization To: Al Viro Cc: Todd Kjos , Greg Kroah-Hartman , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , "open list:ANDROID DRIVERS" , LKML , Martijn Coenen , joel@joelfernandes.org, Android Kernel Team , Jann Horn , Martijn Coenen 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 On Wed, Dec 5, 2018 at 4:40 PM Al Viro wrote: > > 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). Thanks for the detailed responses. I'll rework it for v3.