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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 DD0E1C433ED for ; Fri, 14 May 2021 20:26:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BF3456121E for ; Fri, 14 May 2021 20:26:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230157AbhENU1Q (ORCPT ); Fri, 14 May 2021 16:27:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230394AbhENU1J (ORCPT ); Fri, 14 May 2021 16:27:09 -0400 Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::4]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3833BC061574; Fri, 14 May 2021 13:25:57 -0700 (PDT) Received: by angie.orcam.me.uk (Postfix, from userid 500) id F21B192009C; Fri, 14 May 2021 22:25:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id EAA2B92009B; Fri, 14 May 2021 22:25:53 +0200 (CEST) Date: Fri, 14 May 2021 22:25:53 +0200 (CEST) From: "Maciej W. Rozycki" To: Linus Torvalds cc: Tetsuo Handa , dri-devel , Linux Fbdev development list , Linux Kernel Mailing List , Daniel Vetter , syzbot , Bartlomiej Zolnierkiewicz , Colin King , Greg Kroah-Hartman , Jani Nikula , Jiri Slaby , syzkaller-bugs , "Antonino A. Daplas" Subject: Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit() In-Reply-To: Message-ID: References: <0000000000006bbd0c05c14f1b09@google.com> <6e21483c-06f6-404b-4018-e00ee85c456c@i-love.sakura.ne.jp> <87d928e4-b2b9-ad30-f3f0-1dfb8e4e03ed@i-love.sakura.ne.jp> <05acdda8-dc1c-5119-4326-96eed24bea0c@i-love.sakura.ne.jp> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 14 May 2021, Linus Torvalds wrote: > > Currently it is impossible to control upper limit of rows/columns values > > based on amount of memory reserved for the graphical screen, for > > resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not > > already KD_GRAPHICS > > Honestly, the saner approach would seem to be to simply error out if > vc_mode is KD_GRAPHICS. > > Doing VT_RESIZE while in KD_GRAPHICS mode seems _very_ questionable, > and is clearly currently very buggy. I haven't looked into it any further beyond tracking down (again, using the LMO tree) the originating change as the other fix took precedence. It came with: commit 094e0a9cdbdf1e11a28dd756a6cbd750b6303d10 Author: Ralf Baechle Date: Sun Jun 1 12:07:37 2003 +0000 Merge with Linux 2.5.51 along with framebuffer console support: +inline int resize_screen(int currcons, int width, int height) +{ + /* Resizes the resolution of the display adapater */ + int err = 0; + + if (vcmode != KD_GRAPHICS && sw->con_resize) + err = sw->con_resize(vc_cons[currcons].d, width, height); + return err; +} + A handler for fbcon was added shortly afterwards with: commit bab384bdbe279efd7acc2146ef13b0b0395b2a42 Author: Ralf Baechle Date: Tue Jun 3 17:04:10 2003 +0000 Merge with Linux 2.5.59. however vgacon didn't have a handler for it until commit 28254d439b8c ("[PATCH] vga text console and stty cols/rows") two years later only. Overall I think it does make sense to resize the text console at any time, even if the visible console (VT) chosen is in the graphics mode, as my understanding (and experience at least with vgacon) is that resizing the console applies globally across all the VTs. So the intent of the original change appears valid to me, and the choice not to reprogram the visible console and only store the settings for a future use if it's in the graphics mode correct. Which means any bug triggered here needs to be fixed elsewhere rather than by making the request fail. NB for fbcon the usual ioctl to resize the console is FBIOPUT_VSCREENINFO rather than VT_RESIZEX; fbset(8) uses it, and I actually experimented with it and a TGA-like (SFB+) framebuffer when at my lab last time, as Linux is kind enough to know how to fiddle with its clockchip. It works just fine. Maciej 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=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 CA5BBC433B4 for ; Fri, 14 May 2021 20:25:58 +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 72FD8613DF for ; Fri, 14 May 2021 20:25:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 72FD8613DF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk 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 3C29E6E239; Fri, 14 May 2021 20:25:57 +0000 (UTC) Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::4]) by gabe.freedesktop.org (Postfix) with ESMTP id 9FBDB6E239 for ; Fri, 14 May 2021 20:25:55 +0000 (UTC) Received: by angie.orcam.me.uk (Postfix, from userid 500) id F21B192009C; Fri, 14 May 2021 22:25:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id EAA2B92009B; Fri, 14 May 2021 22:25:53 +0200 (CEST) Date: Fri, 14 May 2021 22:25:53 +0200 (CEST) From: "Maciej W. Rozycki" To: Linus Torvalds Subject: Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit() In-Reply-To: Message-ID: References: <0000000000006bbd0c05c14f1b09@google.com> <6e21483c-06f6-404b-4018-e00ee85c456c@i-love.sakura.ne.jp> <87d928e4-b2b9-ad30-f3f0-1dfb8e4e03ed@i-love.sakura.ne.jp> <05acdda8-dc1c-5119-4326-96eed24bea0c@i-love.sakura.ne.jp> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 , Bartlomiej Zolnierkiewicz , Tetsuo Handa , Greg Kroah-Hartman , syzkaller-bugs , Linux Kernel Mailing List , dri-devel , Jani Nikula , Colin King , Jiri Slaby , syzbot Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, 14 May 2021, Linus Torvalds wrote: > > Currently it is impossible to control upper limit of rows/columns values > > based on amount of memory reserved for the graphical screen, for > > resize_screen() calls vc->vc_sw->con_resize() only if vc->vc_mode is not > > already KD_GRAPHICS > > Honestly, the saner approach would seem to be to simply error out if > vc_mode is KD_GRAPHICS. > > Doing VT_RESIZE while in KD_GRAPHICS mode seems _very_ questionable, > and is clearly currently very buggy. I haven't looked into it any further beyond tracking down (again, using the LMO tree) the originating change as the other fix took precedence. It came with: commit 094e0a9cdbdf1e11a28dd756a6cbd750b6303d10 Author: Ralf Baechle Date: Sun Jun 1 12:07:37 2003 +0000 Merge with Linux 2.5.51 along with framebuffer console support: +inline int resize_screen(int currcons, int width, int height) +{ + /* Resizes the resolution of the display adapater */ + int err = 0; + + if (vcmode != KD_GRAPHICS && sw->con_resize) + err = sw->con_resize(vc_cons[currcons].d, width, height); + return err; +} + A handler for fbcon was added shortly afterwards with: commit bab384bdbe279efd7acc2146ef13b0b0395b2a42 Author: Ralf Baechle Date: Tue Jun 3 17:04:10 2003 +0000 Merge with Linux 2.5.59. however vgacon didn't have a handler for it until commit 28254d439b8c ("[PATCH] vga text console and stty cols/rows") two years later only. Overall I think it does make sense to resize the text console at any time, even if the visible console (VT) chosen is in the graphics mode, as my understanding (and experience at least with vgacon) is that resizing the console applies globally across all the VTs. So the intent of the original change appears valid to me, and the choice not to reprogram the visible console and only store the settings for a future use if it's in the graphics mode correct. Which means any bug triggered here needs to be fixed elsewhere rather than by making the request fail. NB for fbcon the usual ioctl to resize the console is FBIOPUT_VSCREENINFO rather than VT_RESIZEX; fbset(8) uses it, and I actually experimented with it and a TGA-like (SFB+) framebuffer when at my lab last time, as Linux is kind enough to know how to fiddle with its clockchip. It works just fine. Maciej