Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp316263ybh; Wed, 22 Jul 2020 01:07:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwt1+IzVJyM9Mp6ieGznACt/RF7wDRtB6UqTQcr9AQaRrYH43YPO6EuEAAA6geQeI3gFeMr X-Received: by 2002:a05:6402:a43:: with SMTP id bt3mr28943075edb.332.1595405278571; Wed, 22 Jul 2020 01:07:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595405278; cv=none; d=google.com; s=arc-20160816; b=kQVLFHcsUAT1Iwp4ZpajUY+jtLvRMfMIYytbK52cA1geuRpP1tJssBvo/D0cVlYJx4 PGZPbsUbgE+QjrpDExjWz3wrF27C5gXKjmkC4D697ksj2JrEv4jdf2IejBbePAaJW9x1 hH1pXm7cirQs2RV3/yrDaKWKse4cEy8c5iEHApJoGT/ANWFP9S7hgobbEIgk7liasTly 7iH5ip+/5Rjwnpvj1JFiSWPfZcoxRd4ziSwCB22ofgFhMVxiwOywrzlWL6bq8BRwGDSc g89NIJajO+mNRopJpywr0I2WYFFzJiQsG5K08nmd2c0obavoHCfKgDU5GudPNOxhOEhy +5jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=DOy7v3hfT/utQT3C9G3K+8RtCzbiTsBHt7vvQa8xceo=; b=ivYTO2xZFnT9fpqGO9zn8lp12ddUhMDEXNGy+kdlaz/vRIAGFAI6m4bsNwkr0ZxeBg srwf68PB3UO9Pp7Wd9GAX+zNduygD0hUVu20XrHvULEKC4sbJyBrGxrQgcIYwplbJ3u7 A5mvH6u6zPoXpLfXf5meUb+TKOipTqot/gfApSbLamkGhPw6emm3+0d+Wv4eVqnh/BTX BZylAEPFsZbl5ssUaI2b1+burdbBkPe5XMx9xCDwd3/LUs3P1CLH10a+yOj7opPtJFCv Q5BSrCFnDxlYbDr2ELM7P9luy3i+56jIKqP2CWyObyLSEXLN/2sR+ae4w/MwBo6z8tmp 18eA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=JPSVdh9i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p5si13672757ejx.318.2020.07.22.01.07.36; Wed, 22 Jul 2020 01:07:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=JPSVdh9i; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728753AbgGVIHT (ORCPT + 99 others); Wed, 22 Jul 2020 04:07:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726945AbgGVIHS (ORCPT ); Wed, 22 Jul 2020 04:07:18 -0400 Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B991C0619DE for ; Wed, 22 Jul 2020 01:07:18 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id k6so1097703oij.11 for ; Wed, 22 Jul 2020 01:07:18 -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=DOy7v3hfT/utQT3C9G3K+8RtCzbiTsBHt7vvQa8xceo=; b=JPSVdh9idiN0Up4ibzccMsoV86w485WS4bmMB7o8cngcTQKmUWXuOg45HnkCXh7Z9m rJ2EnrDrVQMzeE2+3r2zS6sZClAZKnxbEr4gf4Bk2cBwL+KmikN4Zwd3oAeSvowgW33C cqwu0LUPOLEili0aFnDflsr7HDOO9Q/+g0zMM= 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=DOy7v3hfT/utQT3C9G3K+8RtCzbiTsBHt7vvQa8xceo=; b=a6yNIGmvjXFXAx6+vTMPzvNaDUfB0Iesgtqr6OOzFg4KQ+KmgwMp4khXTSztbNW/Qa oUWneqOX9pOIibtOdI+ELNWaqDnoCK5tZC/C7KqIE08ZD/vCW1Bi8QIM7/NKKt5EydMg Vqn2ZS+Jlbn0q27o0/pf8YwzYyNQ8NjImY/bYsyFarsHEMbumm4LapsJU8nElwoBfVto YPL7S+Qdn7Foga5JWApueon3U24FLFt/Q55VJtUOPQB9Ry+s1fS3C6vxxc6ZWQ3Ho0iU oaY8kMTatS0QGdDLzdSnBlRLxdNzaMMH9gLm5d6z12FhjfiK5kwOwILtLhNhrDkVZj8p gB+A== X-Gm-Message-State: AOAM5300wJdzzmbAGwt11UyRnkCPmjJ9bt6GeWfnThK+WrpJKmk/F6UC MJN2Z3Xa1F9NPNGLduSKW0M1kq0dNpXgIkjuT3BSdg== X-Received: by 2002:aca:cc8e:: with SMTP id c136mr6219460oig.128.1595405237785; Wed, 22 Jul 2020 01:07:17 -0700 (PDT) MIME-Version: 1.0 References: <20200715015102.3814-1-penguin-kernel@I-love.SAKURA.ne.jp> <20200715094836.GD2571@kadam> <9e6eac10-c5c3-f518-36cc-9ea32fb5d7fe@i-love.sakura.ne.jp> <20200715151220.GE2571@kadam> <20200716100006.GN3278063@phenom.ffwll.local> <20200721160836.GA2109047@kroah.com> In-Reply-To: <20200721160836.GA2109047@kroah.com> From: Daniel Vetter Date: Wed, 22 Jul 2020 10:07:06 +0200 Message-ID: Subject: Re: [PATCH v2] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins. To: Greg Kroah-Hartman Cc: Tetsuo Handa , Dan Carpenter , Linux Fbdev development list , Bartlomiej Zolnierkiewicz , syzbot , Linux Kernel Mailing List , dri-devel , George Kennedy , Jiri Slaby , Dmitry Vyukov Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 21, 2020 at 6:08 PM Greg Kroah-Hartman wrote: > > On Thu, Jul 16, 2020 at 08:27:21PM +0900, Tetsuo Handa wrote: > > On 2020/07/16 19:00, Daniel Vetter wrote: > > > On Thu, Jul 16, 2020 at 12:29:00AM +0900, Tetsuo Handa wrote: > > >> On 2020/07/16 0:12, Dan Carpenter wrote: > > >>> I've complained about integer overflows in fbdev for a long time... > > >>> > > >>> What I'd like to see is something like the following maybe. I don't > > >>> know how to get the vc_data in fbmem.c so it doesn't include your checks > > >>> for negative. > > >> > > >> Yes. Like I said "Thus, I consider that we need more sanity/constraints checks." at > > >> https://lore.kernel.org/lkml/b1e7dd6a-fc22-bba8-0abb-d3e779329bce@i-love.sakura.ne.jp/ , > > >> we want basic checks. That's a task for fbdev people who should be familiar with > > >> necessary constraints. > > > > > > I think the worldwide supply of people who understand fbdev and willing to > > > work on it is roughly 0. So if someone wants to fix this mess properly > > > (which likely means adding tons of over/underflow checks at entry points, > > > since you're never going to catch the driver bugs, there's too many and > > > not enough people who care) they need to fix this themselves. > > > > But I think we can enforce reasonable constraint which is much stricter than Dan's basic_checks() > > (which used INT_MAX). For example, do we need to accept var->{xres,yres} >= 1048576, for > > "32768 rows or cols" * "32 pixels per character" = 1045876 and vc_do_resize() accepts only > > rows and cols < 32768 ? > > > > > > > > Just to avoid confusion here. > > > > > >> Anyway, my two patches are small and low cost; can we apply these patches regardless > > >> of basic checks? > > > > > > Which two patches where? > > > > [PATCH v3] vt: Reject zero-sized screen buffer size. > > from https://lkml.kernel.org/r/20200712111013.11881-1-penguin-kernel@I-love.SAKURA.ne.jp > > This is now in my tree. > > > [PATCH v2] fbdev: Detect integer underflow at "struct fbcon_ops"->clear_margins. > > from https://lkml.kernel.org/r/20200715015102.3814-1-penguin-kernel@I-love.SAKURA.ne.jp > > That should be taken by the fbdev maintainer, but I can take it too if > people want. Just missed this weeks pull request train and feeling like not worth making this an exception (it's been broken forever after all), so maybe best if you just add this to vt. Acked-by: Daniel Vetter Also this avoids the impression I know what's going on in fbdev code, maybe with sufficient abandon from my side someone will pop up who cares an fixes the bazillion of syzkaller issues we seem to have around console/vt and everything related. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch