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 74670C33CB1 for ; Wed, 15 Jan 2020 13:17:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4FC6E2084D for ; Wed, 15 Jan 2020 13:17:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729035AbgAONRR (ORCPT ); Wed, 15 Jan 2020 08:17:17 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:36177 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726220AbgAONRR (ORCPT ); Wed, 15 Jan 2020 08:17:17 -0500 Received: from mail-qv1-f43.google.com ([209.85.219.43]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MiaLn-1jKiZI1H5b-00flU9; Wed, 15 Jan 2020 14:17:15 +0100 Received: by mail-qv1-f43.google.com with SMTP id t6so7303531qvs.5; Wed, 15 Jan 2020 05:17:14 -0800 (PST) X-Gm-Message-State: APjAAAXUF7uwoly5PxRtodJvMfrQEtLMn876yokffdjv5Z92xD2YsrMs c19fuO+ci0nHeozC9yNB8N9sC/9w4k8HpbXx2DA= X-Google-Smtp-Source: APXvYqw6NIFS97lqecGyqkucJJ9eR92lH8OkYLUR/9zn7Yxt/NLRzeCcRu106nWrGyp9+B+UV4pv/9O/RYpLvGnJKEc= X-Received: by 2002:a0c:d788:: with SMTP id z8mr20666215qvi.211.1579094234004; Wed, 15 Jan 2020 05:17:14 -0800 (PST) MIME-Version: 1.0 References: <20191029182320.GA17569@mwanda> <87zhhjjryk.fsf@x220.int.ebiederm.org> <6ed59903-afe7-d5b2-73eb-ca626616dd6f@samsung.com> In-Reply-To: <6ed59903-afe7-d5b2-73eb-ca626616dd6f@samsung.com> From: Arnd Bergmann Date: Wed, 15 Jan 2020 14:16:57 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] fbdev: potential information leak in do_fb_ioctl() To: Bartlomiej Zolnierkiewicz Cc: "Eric W. Biederman" , Joe Perches , Dan Carpenter , Andrea Righi , Daniel Vetter , Sam Ravnborg , Maarten Lankhorst , Peter Rosin , Gerd Hoffmann , dri-devel , Linux Fbdev development list , "linux-kernel@vger.kernel.org" , kernel-janitors@vger.kernel.org, security@kernel.org, Kees Cook , Julia Lawall Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:1sZUHtYS3cZfWONjHXH49q7U5+XCF6+oSN6oebSYZOEBhyv73Nn aNx9K6/QRsO9neZCDKSRMl07IFzzQc/w/Fdnehy5ik5KIPepjzza0OcSMjK+nAR5uOqoz2T w6keQbGUudpbjWs5YZ3sFz4/AMHKdXbKGtCqRXPb8ncQyTIdpuU+/B+Fs+Cw8s3/IvVXb3N 6sPchdumTQIm2NCMDkSbA== X-UI-Out-Filterresults: notjunk:1;V03:K0:w/HC8ctDI9w=:xkndOO9xTeXLhIPWKCAj3O WoNMR1LjTrtESui2PCxFOtDk1ct9dNYL7U5+wucEQoPiPdv6aKNamiGMqE+qYQNTY6/7legFA OefH5d37/wBgdZkU5PDT60rixIQ2RvuD6XH6YXscGh8nYzPyRFVojEiKR7RVnJAog7uG/XcaM jxS+Y1T87cal/GLkPMnHvkj8fhBfnXl6047/kU81oE26SgL9JVHG/qqDDQmVdTIxYCc/SZ/j2 J2NwQfVNG+x5oeLpKO4n/pzwyuDkvEa55BJm0BSIjUQ0kryoI3kCCDxmdOXZYPq9gYR11fgXu ll5oR51j+NyMPl4EpO0SfJmfIUaxK6Q+0OXxtVjFawVjrqgfQ4tBQJ/7CQARMjIBx9YKl1BVx UZpfr6GHks9qPEgcEMLbqjbDo43ufeIKZXQ8Rfcdrcjf0gXsWuw+8FfKUOFbhLgMChXSVsaoC qkImbG9QA/KxJwrjwq+fOAfo2hdmnh0SW6OKPfLrZNiJ1qRTNb+DoSudv1kBOiTd/77TlHAW3 v+bLtf3Zzu/WbJfUJ0TsFlNV3OwXjVHWMTKbCIGJzDGDT7zAUcrtJSHkDUbne9J9RJFUpnHcx R8k1WWyhjnCQr8T+qPmQLK1gwxtQC10ZXVOBHJ9ylP9G6XFgGaC7XCnovAdO9Tmy/I5wQEsWw Gm33J4FXM5ddKjzeEH5ufbS9193/bwxe7oQQA1JcaWouo7RHaPaSp0FBqEQ995k6X46RLpaTP j5nEPC5Fh4xhGViW7RbV7ThYVCCAjRHQ81hxuG/k3E2+3Qaw7NC5ITQ2LZy1LzZ+4yW4VgPjm qkCvWv98W4JtGtJcxm1Uvl763jvdY79h8FqImGRKqeakomU8x6HSYRfqLbOZHWpA0z3QcOfmn rmuhMycZkbdP4tn/Bv7A== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 15, 2020 at 2:09 PM Bartlomiej Zolnierkiewicz wrote: > > $ 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. > > I've audited all above instances and they are all fine. They either > use the fb_info structure embedded in a driver specific structure > (which is zeroed out) or (in case of some m68k specific drivers) use > a static fb_info instance. > > Since fbdev is closed for new drivers it should be now fine to use > the simpler approach (just use memcpy()). Yes, let's do that then. The complex approach seems more likely to introduce a bug than one of the existing drivers to stop initializing the structure correctly. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Date: Wed, 15 Jan 2020 13:16:57 +0000 Subject: Re: [PATCH] fbdev: potential information leak in do_fb_ioctl() Message-Id: List-Id: References: <20191029182320.GA17569@mwanda> <87zhhjjryk.fsf@x220.int.ebiederm.org> <6ed59903-afe7-d5b2-73eb-ca626616dd6f@samsung.com> In-Reply-To: <6ed59903-afe7-d5b2-73eb-ca626616dd6f@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Bartlomiej Zolnierkiewicz 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 On Wed, Jan 15, 2020 at 2:09 PM Bartlomiej Zolnierkiewicz wrote: > > $ 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. > > I've audited all above instances and they are all fine. They either > use the fb_info structure embedded in a driver specific structure > (which is zeroed out) or (in case of some m68k specific drivers) use > a static fb_info instance. > > Since fbdev is closed for new drivers it should be now fine to use > the simpler approach (just use memcpy()). Yes, let's do that then. The complex approach seems more likely to introduce a bug than one of the existing drivers to stop initializing the structure correctly. Arnd 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 441C9C33CB3 for ; Wed, 15 Jan 2020 13:17:22 +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 225EA2084D for ; Wed, 15 Jan 2020 13:17:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 225EA2084D 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 396146E9CC; Wed, 15 Jan 2020 13:17:20 +0000 (UTC) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5FE526E9CC for ; Wed, 15 Jan 2020 13:17:18 +0000 (UTC) Received: from mail-qv1-f51.google.com ([209.85.219.51]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MgzWP-1jJ4fh0Hcb-00hR8R for ; Wed, 15 Jan 2020 14:17:16 +0100 Received: by mail-qv1-f51.google.com with SMTP id l14so7296348qvu.12 for ; Wed, 15 Jan 2020 05:17:14 -0800 (PST) X-Gm-Message-State: APjAAAWS2xsqXe4YxPenMBli3q7JkKKmcELon5EeK1PG61q/dmWwDuWn dyVvJ0mW+LVgha5MFambiHIFpjyjdXML7jBZkcY= X-Google-Smtp-Source: APXvYqw6NIFS97lqecGyqkucJJ9eR92lH8OkYLUR/9zn7Yxt/NLRzeCcRu106nWrGyp9+B+UV4pv/9O/RYpLvGnJKEc= X-Received: by 2002:a0c:d788:: with SMTP id z8mr20666215qvi.211.1579094234004; Wed, 15 Jan 2020 05:17:14 -0800 (PST) MIME-Version: 1.0 References: <20191029182320.GA17569@mwanda> <87zhhjjryk.fsf@x220.int.ebiederm.org> <6ed59903-afe7-d5b2-73eb-ca626616dd6f@samsung.com> In-Reply-To: <6ed59903-afe7-d5b2-73eb-ca626616dd6f@samsung.com> From: Arnd Bergmann Date: Wed, 15 Jan 2020 14:16:57 +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:2Aj6vF/QtQP6DLVRPDSkZ3d6Ev3Gl5ZIzQNYLkU+mJiGreYknTs sD3wiO5PdbwU02u3j1vhvZIgqlV0/tpW2S19BrXo7jHgqhRYmRoGrUswSZ3t3Mc/lhAs8IT gWKFkEW4LIY56G9Efd5ihaWQUo7D6pvf6A8SQ/G0fn1iGARqU0fRALB8VtkM6R8ht4z0n7X y7xkZOw8enf5TdCscFpIw== X-UI-Out-Filterresults: notjunk:1;V03:K0:hHAfE38rQAc=:bUgdVuiPwnzAUAPRciKWlF L2TCL50cYLvsE6hXPkXA6zkaPmTR/VY+YuwB98WXyv8+XEVYKv/Sicm/7V5aerjOA9UHjoxWX pf13LFsHhiYFOetQuUsOf47Uo7Ihu4gey77lPngXT+D/lnBOf6nbKvWpTxWE3dEAnBVSen3c5 vSfGkroPNJR/bTYXvqX+gKThEezeq9gXtFmXrl/tx1CCszs75Kbbq2jrY94mFTv8JDxcrqSLI ZoEYUiqIzKxaBIzfExQI8Cg3f7sewmhIvGQAjf2tlC/1UspxuvMUcI4rs11wMxvogqdQgBQLM SHGyhMi5eOhQH8ip3lAgbrjZxGVXpGZ/7boz45N7gqQjmzCzHPHnvvGfFwiUPj2avkn8f0xym TDgd9L7SF8xfOh6ywYsUcgHi2sXp4ZeFHEaX+f8VTDGui89lSg9mUk5P6TUDnn8/6EWdriKJm 1K7PDB2wG9FrqbhC+peV+1EB3Iz0mCrg9xMe6yxVP10TN7t5T8Zdvp70EkNwF6ySUJPGvWQHP 7TrTsFyg4uKHtM8C7dMrSM4j+Pwt8F+ss9xs6ucayUBuTMavtWTQWSBeBWjsmRzupMCdrRVI7 4ySUATXR8FRrsrivbFgMzQKU8SSd/KMyYIzUkqlEdTNhfKZrrkqrqzrZrv93oBPPqUCXZJy0J zEyPrAeTfnCpfcapM+ZsHaFYOqBAR+/kzhY43Ok5ab0mPu2TBx3uL/85cmUFmsioPSupGpGen i7nv0+euHBkC6IQ79IJm0Ms8sc4BYVgiyL86tn3tpPfD4Ww5JQ1VnBm8lAYU1XTT2lmXSabBE 0mKRAF9A1CLAB+lGfOtPjlEiArCEnOrk7rkk7NImL6IdtHBcKBgznPKSbnPgCgtvJGFu5SALZ 0uHZZkhIVH6progD+rlg== 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 Wed, Jan 15, 2020 at 2:09 PM Bartlomiej Zolnierkiewicz wrote: > > $ 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. > > I've audited all above instances and they are all fine. They either > use the fb_info structure embedded in a driver specific structure > (which is zeroed out) or (in case of some m68k specific drivers) use > a static fb_info instance. > > Since fbdev is closed for new drivers it should be now fine to use > the simpler approach (just use memcpy()). Yes, let's do that then. The complex approach seems more likely to introduce a bug than one of the existing drivers to stop initializing the structure correctly. Arnd _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel