From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CE169C33CAD for ; Mon, 13 Jan 2020 12:49:53 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AD6EC21556 for ; Mon, 13 Jan 2020 12:49:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD6EC21556 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 12C0389E36; Mon, 13 Jan 2020 12:49:53 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6CDD289E36 for ; Mon, 13 Jan 2020 12:49:50 +0000 (UTC) Received: from mail-qt1-f175.google.com ([209.85.160.175]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MtO06-1jf6TS3SQg-00uqWp for ; Mon, 13 Jan 2020 13:49:49 +0100 Received: by mail-qt1-f175.google.com with SMTP id g1so8905263qtr.13 for ; Mon, 13 Jan 2020 04:49:48 -0800 (PST) X-Gm-Message-State: APjAAAVV0tby+L1dpG6lLnlueC6RVJ1v9AIG03lMSnfe9oeYWeiLpMqj i47Z7pTMwATYrsD7x8ChskvrSP+4ZHPTc6d2QVI= X-Google-Smtp-Source: APXvYqzFNee6oMqlwdnJFaK96+kqQeTvX1mVko2+fsSOjGGm7mJkzAnLuZGtaJ8nkF1quBL2liWsixLifYLOWUujuDc= X-Received: by 2002:ac8:709a:: with SMTP id y26mr13837250qto.304.1578919787752; Mon, 13 Jan 2020 04:49:47 -0800 (PST) MIME-Version: 1.0 References: <20191029182320.GA17569@mwanda> <87zhhjjryk.fsf@x220.int.ebiederm.org> In-Reply-To: From: Arnd Bergmann Date: Mon, 13 Jan 2020 13:49:30 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] fbdev: potential information leak in do_fb_ioctl() To: Bartlomiej Zolnierkiewicz X-Provags-ID: V03:K1:8fdrcuQ+1Ivcgam6LzqNpcEXrfYQs/uhkB0FxAskpIjVsqK+qoV BtCVrMcMjAHXXtD25hmM/uVTuV8h6HoOwShA02P+WS/3cj+w69scG+ixIXrit03mukiWX2W tUkkbBEii54WCw5qk+bES1ip8t6Kq2xhPgBBme6DjO4OZ+y3vtGzkLlO65Erpdw1zj1fQFa M1pzATxC4WWaniCk71mEQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:7XrP/BptEp0=:KT+iYU+aQk2MAWWeNKIKRz kg0NMALvnRKyDsOoAZ46oB6P/ruuCRTKy/45H/ji+0rbjH2nAbLw13mT+OiVfFdA5jJzpU2Um yDUw+igZMb5JfFeffrPYvNInvdvHCIZ33DqoONQoIhwbwpQl0CpiWejAIZ/KYRk9aZvae1GOq Rnxw5fOuJfIfehlQJW1MykVTlDKm9JIQNj5nJXIQkJ8ehBu0y7PcyPnsUNXlsRzYxBZZSWpOS cj0qYRuEnx76IjP+SNNGVND5pAu/MOcKWZz2xSSN4nJDL3mOgUci4lVWjSlYsFXmYxxfMVItl xzJZZyhOm9S0MlOiUZeGiwQlQJosN9Z0bYzrva1qgeldL46ZqRv2OceEp3/r3ZSTG5G/i/xOR P6nZkRM3zv5iI9OvxOOjG914TiXCMrYl6vPKiJtbDMc1SAfuV9Z9fhilylorKxXZzIH9Cd4gu B5O+u1C3jyGWbYJWh56Aj175Jm9rW601OYi7EMtKGAFbN7L+JMAFgBkHVBSvv66DtlhBZGV5D XF2fkxlyiNMMeeSW8nchMBbjgP4RX8APxdXwxBbG5/EmqunJhyECH1PMSk6h+6w+SSvHsrp52 y/zUOEgG2F5oItjhjGgj308Lmes6niye9LR1YWcDsVp7gwMh4vDeQVJKm8/i6m/l4VDLVlMO/ bEsVCm+cns+cjt0acQzlyAXCgGCTjVS8kRruJnha3z6yWpctEJqAdKzOruAzecy20yuTlFv+O RRf70qRtgl71iYt461sE6aRfrn+9R7E8MMJJdSkr9Wn2xox4WEWidL8Dg7JkPvU8dvRMwl9Mu txqP3jcAdC44gZ1l2C+o8ZUYtAf9XS1DUdgvCvuEkgGRXXxrKgGvR6w3Xq8wMuUzTa02Ss45n B38XBjIGprDoGUk039hA== X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux Fbdev development list , security@kernel.org, Gerd Hoffmann , Kees Cook , kernel-janitors@vger.kernel.org, Daniel Vetter , "linux-kernel@vger.kernel.org" , dri-devel , Julia Lawall , "Eric W. Biederman" , Joe Perches , Sam Ravnborg , Peter Rosin , Dan Carpenter , Andrea Righi Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Jan 3, 2020 at 2:09 PM Bartlomiej Zolnierkiewicz wrote: > On 10/29/19 8:02 PM, Eric W. Biederman wrote: > > > > The goal is to avoid memory that has values of the previous users of > > that memory region from leaking to userspace. Which depending on who > > the previous user of that memory region is could tell userspace > > information about what the kernel is doing that it should not be allowed > > to find out. > > > > I tried to trace through where "info" and thus presumably "info->fix" is > > coming from and only made it as far as register_framebuffer. Given > > "info" (and thus "info->fix") comes from framebuffer_alloc() (which is > called by fbdev device drivers prior to registering "info" with > register_framebuffer()). framebuffer_alloc() does kzalloc() on "info". > > Therefore shouldn't memcpy() (as suggested by Jeo Perches) be enough? Is it guaranteed that all drivers call framebuffer_alloc() rather than open-coding it somewhere? Here is a list of all files that call register_framebuffer() without first calling framebuffer_alloc: $ git grep -wl register_framebuffer | xargs grep -L framebuffer_alloc Documentation/fb/framebuffer.rst drivers/media/pci/ivtv/ivtvfb.c drivers/media/platform/vivid/vivid-osd.c drivers/video/fbdev/68328fb.c drivers/video/fbdev/acornfb.c drivers/video/fbdev/amba-clcd.c drivers/video/fbdev/atafb.c drivers/video/fbdev/au1100fb.c drivers/video/fbdev/controlfb.c drivers/video/fbdev/core/fbmem.c drivers/video/fbdev/cyber2000fb.c drivers/video/fbdev/fsl-diu-fb.c drivers/video/fbdev/g364fb.c drivers/video/fbdev/goldfishfb.c drivers/video/fbdev/hpfb.c drivers/video/fbdev/macfb.c drivers/video/fbdev/matrox/matroxfb_base.c drivers/video/fbdev/matrox/matroxfb_crtc2.c drivers/video/fbdev/maxinefb.c drivers/video/fbdev/ocfb.c drivers/video/fbdev/pxafb.c drivers/video/fbdev/sa1100fb.c drivers/video/fbdev/stifb.c drivers/video/fbdev/valkyriefb.c drivers/video/fbdev/vermilion/vermilion.c drivers/video/fbdev/vt8500lcdfb.c drivers/video/fbdev/wm8505fb.c drivers/video/fbdev/xilinxfb.c It's possible (even likely, the ones I looked at are fine) that they all correctly zero out the fb_info structure first, but it seems hard to guarantee, so Eric's suggestion would possibly still be the safer choice. Arnd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel