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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 72951C4320E for ; Tue, 31 Aug 2021 16:20:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5CA54610C9 for ; Tue, 31 Aug 2021 16:20:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239968AbhHaQVR (ORCPT ); Tue, 31 Aug 2021 12:21:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35322 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239136AbhHaQVQ (ORCPT ); Tue, 31 Aug 2021 12:21:16 -0400 Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D0368C061575 for ; Tue, 31 Aug 2021 09:20:20 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id l7-20020a0568302b0700b0051c0181deebso23450119otv.12 for ; Tue, 31 Aug 2021 09:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Nxjd5f4FQP+iuJdlCMMXyBCT1vbYwVqlZ+8XK9fwdQ=; b=J72jUYPDy5vSnEPtLJff6zOJWiJ8rBr7sxb0kJeX18yOKAaIgyhAtBo/RdbLgqvVbT +NJL+5U10HnPXrjROQSfIq3yQ6aZ5hP7SRh9gkLZO6vO2kx9nWceTIE8S2OJrVUDTDvy XSY+zI9ptht4vdGw7GKMLV5oX50v6/cjMOekM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Nxjd5f4FQP+iuJdlCMMXyBCT1vbYwVqlZ+8XK9fwdQ=; b=He/YXowIhelSi/1KdgUAbQKB355h/K1CWRsmPP5SIvw90DIZGRQt+KisqNj8HT3XfZ NZ5WPjm/PJSIWfPcjlUvqNyHKNR7roDqUAip5lkPoNF7IUWYImQibaLYjj+2Mk6dxrFJ sv9lJGXf0Oiz8ag/6lIeSY72Whesxhd4jEWyRBpwuY36FqaktJaF26FBLduN4c7TDUAJ Tg6JFwKzVh0pi+OCL7/YrA1/dz4TVBjKl34GClp4Qz9hF8AJucMlDnKjTHpYijX7o/3Z x+J6wySluwuTitRGwHARY1dHbIjPwwTkiU9DynX2LXBwBPycbN6fXM4Cw7ufNKiytYW2 w4zw== X-Gm-Message-State: AOAM530SJJ8E1IMXORJ87KI6TzChkyWoMz/1GWpEPa5im8k9HqYGaiO5 8ODRDi+ar7JaR7yKEZuq929q5yz0E5HMiU7CXStmCA== X-Google-Smtp-Source: ABdhPJwStM5dJA6wjR+VVbKMzJ3V+gw9bRn26N055U5GnWbinAi7zEmvwJCmKgB5Hcu7VTrZr/ZjSHHRE3i3ciIrmVE= X-Received: by 2002:a9d:65da:: with SMTP id z26mr24499621oth.303.1630426820214; Tue, 31 Aug 2021 09:20:20 -0700 (PDT) MIME-Version: 1.0 References: <000000000000815b9605c70e74f8@google.com> <131b24e5-ee31-6f7b-42b4-c34583711913@infradead.org> <2fccb5d3-191c-924e-159f-1c9d423e282f@i-love.sakura.ne.jp> <339bfb21-8e80-c7d9-46dd-c416f87c50c0@infradead.org> <535e404d-03bf-8e7a-b296-132a2a98c599@i-love.sakura.ne.jp> <5c6d2b95-31d7-0d59-5e62-2593d9a0e1fe@i-love.sakura.ne.jp> In-Reply-To: <5c6d2b95-31d7-0d59-5e62-2593d9a0e1fe@i-love.sakura.ne.jp> From: Daniel Vetter Date: Tue, 31 Aug 2021 18:20:09 +0200 Message-ID: Subject: Re: [PATCH] fbmem: don't allow too huge resolutions To: Tetsuo Handa Cc: Geert Uytterhoeven , syzbot , Andrew Morton , Bartlomiej Zolnierkiewicz , Colin King , DRI Development , Linux Fbdev development list , Linux Kernel Mailing List , Masahiro Yamada , syzkaller-bugs , Randy Dunlap Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 31, 2021 at 5:24 PM Tetsuo Handa wrote: > On 2021/08/31 15:48, Geert Uytterhoeven wrote: > > Furthermore, this restricts the virtual frame buffer size on 64-bit, > > too, while graphics cards can have much more than 4 GiB of RAM. > > Excuse me, but do you mean that some hardware allows allocating more than > UINT_MAX bytes of memory for kernel frame buffer drivers? > > > IMHO that should be fixed in vga16fb, too. > > According to https://elixir.bootlin.com/linux/v5.14/A/ident/fb_check_var , > there are 89 files. Randomly picking up drivers/video/fbdev/udlfb.c as > an example. dlfb_is_valid_mode() from dlfb_ops_check_var() is doing > > if (mode->xres * mode->yres > dlfb->sku_pixel_limit) > return 0; > return 1; > > where max dlfb->sku_pixel_limit seems to be 2048 * 1152 but I think we need > same overflow check. I want to avoid patching individual modules if possible. > That depends on whether some hardware needs to allocate more than UINT_MAX > bytes of memory. Yeah basic input validation makes no sense to push into each driver. That's just asking that most of the fbdev drivers will never be fixed. Same for not-so-basic input validation, if there's no driver that actually needs the flexibility (like the virtual vs physical size thing that's floating around maybe). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch 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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 90B9FC43214 for ; Tue, 31 Aug 2021 16:20:23 +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 B1261610CB for ; Tue, 31 Aug 2021 16:20:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B1261610CB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 99B3F6E029; Tue, 31 Aug 2021 16:20:21 +0000 (UTC) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by gabe.freedesktop.org (Postfix) with ESMTPS id 03B6D6E029 for ; Tue, 31 Aug 2021 16:20:20 +0000 (UTC) Received: by mail-ot1-x32e.google.com with SMTP id g66-20020a9d12c8000000b0051aeba607f1so23492239otg.11 for ; Tue, 31 Aug 2021 09:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Nxjd5f4FQP+iuJdlCMMXyBCT1vbYwVqlZ+8XK9fwdQ=; b=J72jUYPDy5vSnEPtLJff6zOJWiJ8rBr7sxb0kJeX18yOKAaIgyhAtBo/RdbLgqvVbT +NJL+5U10HnPXrjROQSfIq3yQ6aZ5hP7SRh9gkLZO6vO2kx9nWceTIE8S2OJrVUDTDvy XSY+zI9ptht4vdGw7GKMLV5oX50v6/cjMOekM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Nxjd5f4FQP+iuJdlCMMXyBCT1vbYwVqlZ+8XK9fwdQ=; b=LVkoH5f91D2lPqklmXlepUvFDIpXbkMGmvN9cz7GfbnnOELAJoWdy+ASyXcVifi2jM uqZaP/7O8P9X4sYJ5w48Fv/XTA+V92TKLVWiHajb+LbYI8gLY38nng9PuiDV3EBpAI9u zV0hqQW1kMCmP4GSppPbAKU2nKlg+YiFasXyvd2NkBnjSMcV25DoONRgzryUc6bUyeku mJvuHc+oLzumAySmbbldzpJ5WfTdyMwUBPW3TwaKpJLNPuKhtL42wirgZ0NCjDKyHHph ww8oWPPnWMGFKEIMn8h7hB98sRrUgSZSXDKZfUr53kmj1pwLLwK2RaT0KWf6v/naylUS tz3g== X-Gm-Message-State: AOAM530Cd29BKA2eY4TTuxFGK4dPfIR6qHbSww334eB/9lTGHDYHrner 6HLmiCeg0xBXOrwKwNVSMdx7TCRJPpcpm67NQXWH8A== X-Google-Smtp-Source: ABdhPJwStM5dJA6wjR+VVbKMzJ3V+gw9bRn26N055U5GnWbinAi7zEmvwJCmKgB5Hcu7VTrZr/ZjSHHRE3i3ciIrmVE= X-Received: by 2002:a9d:65da:: with SMTP id z26mr24499621oth.303.1630426820214; Tue, 31 Aug 2021 09:20:20 -0700 (PDT) MIME-Version: 1.0 References: <000000000000815b9605c70e74f8@google.com> <131b24e5-ee31-6f7b-42b4-c34583711913@infradead.org> <2fccb5d3-191c-924e-159f-1c9d423e282f@i-love.sakura.ne.jp> <339bfb21-8e80-c7d9-46dd-c416f87c50c0@infradead.org> <535e404d-03bf-8e7a-b296-132a2a98c599@i-love.sakura.ne.jp> <5c6d2b95-31d7-0d59-5e62-2593d9a0e1fe@i-love.sakura.ne.jp> In-Reply-To: <5c6d2b95-31d7-0d59-5e62-2593d9a0e1fe@i-love.sakura.ne.jp> From: Daniel Vetter Date: Tue, 31 Aug 2021 18:20:09 +0200 Message-ID: Subject: Re: [PATCH] fbmem: don't allow too huge resolutions To: Tetsuo Handa Cc: Geert Uytterhoeven , syzbot , Andrew Morton , Bartlomiej Zolnierkiewicz , Colin King , DRI Development , Linux Fbdev development list , Linux Kernel Mailing List , Masahiro Yamada , syzkaller-bugs , Randy Dunlap Content-Type: text/plain; charset="UTF-8" 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: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Aug 31, 2021 at 5:24 PM Tetsuo Handa wrote: > On 2021/08/31 15:48, Geert Uytterhoeven wrote: > > Furthermore, this restricts the virtual frame buffer size on 64-bit, > > too, while graphics cards can have much more than 4 GiB of RAM. > > Excuse me, but do you mean that some hardware allows allocating more than > UINT_MAX bytes of memory for kernel frame buffer drivers? > > > IMHO that should be fixed in vga16fb, too. > > According to https://elixir.bootlin.com/linux/v5.14/A/ident/fb_check_var , > there are 89 files. Randomly picking up drivers/video/fbdev/udlfb.c as > an example. dlfb_is_valid_mode() from dlfb_ops_check_var() is doing > > if (mode->xres * mode->yres > dlfb->sku_pixel_limit) > return 0; > return 1; > > where max dlfb->sku_pixel_limit seems to be 2048 * 1152 but I think we need > same overflow check. I want to avoid patching individual modules if possible. > That depends on whether some hardware needs to allocate more than UINT_MAX > bytes of memory. Yeah basic input validation makes no sense to push into each driver. That's just asking that most of the fbdev drivers will never be fixed. Same for not-so-basic input validation, if there's no driver that actually needs the flexibility (like the virtual vs physical size thing that's floating around maybe). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch