Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp9991518imu; Wed, 5 Dec 2018 14:02:16 -0800 (PST) X-Google-Smtp-Source: AFSGD/VfGvOadhjjoEIJN+VTnilGFVcMw3E49NYttFj0jMy1qhS5RwL2U8zwzHAC9Aqhzk9beqEF X-Received: by 2002:a63:4b60:: with SMTP id k32mr21742916pgl.186.1544047336653; Wed, 05 Dec 2018 14:02:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544047336; cv=none; d=google.com; s=arc-20160816; b=D/JJlCbEj62r4T9+4/1Anr8m8hs9L02hVhWgmW9MqydpisnxWqZXsPinYxt54esNuc YJ8XdpdcyWEcIz4jTUbkRa9zQA6CIaVsOT2KZVfiOiCGt6B+9UorJ3VkaLXTfKaOXZp4 cUufTsDnraodWMf/Mw9ex0P6zUNw67S90B0fG1wdT7jnRiJ/mAi+NtaMcg2Q2ARpBRhd u5rS6Sd9WC8PlwamQ/DDw5y86fre6mPep+wwsCbdBZlvdlYOdF1FMAQBJpnB2QljoBFl rti78J97P/ZAh5DWgxgHGbi+9TGBkILmu68B3D7riB269V2ZlebHQ9j1hN6RhU+cCL+v Oijg== 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=O++9ZjJcspfelEcASPqXEk0hwfsJm4N6Ma1yjNhNMNc=; b=iRwcipSFNi8tcgL5CVxsyonU21iCQs2g9KGhujP3Ou8AZ6ZFbMM8IKgdOwDgqtS0/q 19lmKBOAz+fL2c6veksAOjMkHwh22cWzi240CE8zDuRFlUdDx+vKjOcpFLFs/uz+8gdx 943QVkj2x78jnXufuYOB6yfD7BqN20KokOI7+T8N096xEt1rgbKrUKhLQLFZZSmwBP4G rpibrphEER+xBrbHvBOrjKMYzEw5awumRITFVBM8PiZdSmK3AOJnYcBYrWmD9yMVb91i JNUYSH7N9YIWfULRyDj8c9ZSwd/jxk8YvcP5st4A+u/gfz5uhN2RYYJZNs3GVwhP1YlI gHCA== 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 u7si21915795pfu.270.2018.12.05.14.02.00; Wed, 05 Dec 2018 14:02:16 -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 S1728052AbeLEWAp (ORCPT + 99 others); Wed, 5 Dec 2018 17:00:45 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:56126 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727339AbeLEWAp (ORCPT ); Wed, 5 Dec 2018 17:00:45 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.91 #2 (Red Hat Linux)) id 1gUfDf-0000Zh-TC; Wed, 05 Dec 2018 22:00:36 +0000 Date: Wed, 5 Dec 2018 22:00:35 +0000 From: Al Viro To: Todd Kjos Cc: tkjos@google.com, gregkh@linuxfoundation.org, arve@android.com, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org, maco@google.com, joel@joelfernandes.org, kernel-team@android.com, Jann Horn , Martijn Coenen Subject: Re: [PATCH v2] binder: fix use-after-free due to fdget() optimization Message-ID: <20181205220035.GX2217@ZenIV.linux.org.uk> References: <20181205211601.75856-1-tkjos@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181205211601.75856-1-tkjos@google.com> 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 01:16:01PM -0800, Todd Kjos wrote: > 44d8047f1d87a ("binder: use standard functions to allocate fds") > exposed a pre-existing issue in the binder driver. > > fdget() is used in ksys_ioctl() as a performance optimization. > One of the rules associated with fdget() is that ksys_close() must > not be called between the fdget() and the fdput(). There is a case > where this requirement is not met in the binder driver (and possibly > other drivers) which results in the reference count dropping to 0 > when the device is still in use. This can result in use-after-free > or other issues. > > This was observed with the following sequence of events: > > Task A and task B are connected via binder; task A has /dev/binder open at > file descriptor number X. Both tasks are single-threaded. > > 1. task B sends a binder message with a file descriptor array > (BINDER_TYPE_FDA) containing one file descriptor to task A > 2. task A reads the binder message with the translated file > descriptor number Y > 3. task A uses dup2(X, Y) to overwrite file descriptor Y with > the /dev/binder file > 4. task A unmaps the userspace binder memory mapping; the reference > count on task A's /dev/binder is now 2 > 5. task A closes file descriptor X; the reference count on task > A's /dev/binder is now 1 > 6. task A forks off a child, task C, duplicating the file descriptor > table; the reference count on task A's /dev/binder is now 2 > 7. task A invokes the BC_FREE_BUFFER command on file descriptor X > to release the incoming binder message > 8. fdget() in ksys_ioctl() suppresses the reference count increment, > since the file descriptor table is not shared > 9. the BC_FREE_BUFFER handler removes the file descriptor table > entry for X and decrements the reference count of task A's > /dev/binder file to 1 > 10.task C calls close(X), which drops the reference count of > task A's /dev/binder to 0 and frees it > 11.task A continues processing of the ioctl and accesses some > property of e.g. the binder_proc => KASAN-detectable UAF > > Fixed by using get_file() / fput() in binder_ioctl(). Note that this patch does *not* remove the nasty trap caused by the garbage in question - struct file can be freed before we even return from ->unlocked_ioctl(). Could you describe in details the desired behaviour of this interface? 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. Of course, the proper fix would require TARDIS and set of instruments for treating severe case of retrocranial inversion, so that this "ABI" would've never existed, but...