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,NICE_REPLY_A,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 68B73C433B4 for ; Sat, 15 May 2021 00:45:46 +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 EB9E061444 for ; Sat, 15 May 2021 00:45:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB9E061444 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=i-love.sakura.ne.jp 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 1AD966F4CA; Sat, 15 May 2021 00:45:45 +0000 (UTC) Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by gabe.freedesktop.org (Postfix) with ESMTPS id E33926F4CA for ; Sat, 15 May 2021 00:45:43 +0000 (UTC) Received: from fsav303.sakura.ne.jp (fsav303.sakura.ne.jp [153.120.85.134]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 14F0jFEm090525; Sat, 15 May 2021 09:45:15 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav303.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav303.sakura.ne.jp); Sat, 15 May 2021 09:45:15 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav303.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 14F0jFti090520 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Sat, 15 May 2021 09:45:15 +0900 (JST) (envelope-from penguin-kernel@i-love.sakura.ne.jp) Subject: Re: [PATCH] video: fbdev: vga16fb: fix OOB write in vga16fb_imageblit() To: "Maciej W. Rozycki" , Linus Torvalds 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> From: Tetsuo Handa Message-ID: <543ead9f-08d2-cc9d-e569-78a479378e62@i-love.sakura.ne.jp> Date: Sat, 15 May 2021 09:45:11 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 , Jani Nikula , Greg Kroah-Hartman , syzkaller-bugs , Linux Kernel Mailing List , dri-devel , Colin King , Jiri Slaby , syzbot Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On 2021/05/15 5:25, Maciej W. Rozycki wrote: > 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. fbcon_update_vcs() from FBIOPUT_VSCREENINFO is no-op if vc->vc_mode != KD_TEXT (which is equivalent to "if vc->vc_mode == KD_GRAPHICS" because KD_TEXT0/KD_TEXT1 are treated as KD_TEXT). Then, maybe it is OK to let resize_screen() return -EINVAL in order to make vc_do_resize() request fail if vc->vc_mode == KD_GRAPHICS. > 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. Since syzbot does not trigger this problem with Linus's patch, I think we can try Linus's patch with pr_info_once("Resizing text console while in graphical mode is ignored. Please report if you need this.\n"); added in order to see if somebody wants "only store the settings for a future use".