Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp935914ybg; Wed, 29 Jul 2020 01:19:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVweokkevhptnxmc2vU/KwH6I9E86eGVVKdELlObiPMW5/O5CikvNrRT78QrdBqtIMf/a5 X-Received: by 2002:a17:906:ca11:: with SMTP id jt17mr10249827ejb.148.1596010778171; Wed, 29 Jul 2020 01:19:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596010778; cv=none; d=google.com; s=arc-20160816; b=oLFLaZ2iBGydRVWrnM6v5hR1nEHm5rA8TcbXvdkqKPX3Lk5utizFtpi0XaKgM2a3bh CGk2AsQ8x5A/AoFQq1TOm8dGZwbodU9WTIhgLUIPYs0kfi3T1/mrhWEuuoT/hfxRogrt Aig9n/UGi9JWrCZ/6prLXu5elO5TzhS32ABHrASy5R038TKgsJiB2jXfOp4V72V1vSWU jkAEvPvuoMFJ4yvXefNirorNGoKIJDNGenkyleH/wbZi+yAOsSuzhCN/eIEyxQNVTnQ7 JTUl8AhtIMX4/twYq5V5NW1z6E6U/z2stZKWGSnPlxEeVP3WnlcB50skZ5mY00RIK7uS wXwg== 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=uGI4csuNiLS6fTAVR1vQNcVBEWSJTSk1oAgwrrB5NsI=; b=foMpoHvlSI4S88ECh1zSl3StH8yXlgvCHCytuSqcbSEszf+Of91m2BzOqQZVjggg+Y 384l8CfZfIzqUv1VGELa/Vn6ThVfpi1XYbKdvUaUYB/4GGI1E3nK53adcpeVftYovzRI QDG+x4GvXyX1fxx3JGx5Xy602Y4jhp9EuHZLcozwDJUE+PpqYlyWkQIlfmT6/5dmTsTu U3H98M3Qt3XZXSc+1ThOE/1lIc29PMC76GiPhLmHEWN5vWEzCVswoQoTVUVUVJMd+qai GL6cTIQ0PRmIK1iqDhJI3HzkB17fXoIwxBQKQKrqrVE+Rg4Iqyhr7XmQS8K0qgQbyXUV HYnw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ffwll.ch header.s=google header.b=e+s6DHmg; 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 a14si972472eda.58.2020.07.29.01.19.15; Wed, 29 Jul 2020 01:19:38 -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=e+s6DHmg; 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 S1728040AbgG2ISZ (ORCPT + 99 others); Wed, 29 Jul 2020 04:18:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726336AbgG2ISZ (ORCPT ); Wed, 29 Jul 2020 04:18:25 -0400 Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8049C061794 for ; Wed, 29 Jul 2020 01:18:24 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id o72so11326597ota.11 for ; Wed, 29 Jul 2020 01:18:24 -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=uGI4csuNiLS6fTAVR1vQNcVBEWSJTSk1oAgwrrB5NsI=; b=e+s6DHmgRnUm69dvY6m2+wPD1X7mXvPZP0fswGknSPRvoHeYYGhzmpEn1hRP36juI+ V7TLksSzFpiPGZ8iBtvuXY677+7945nVOo6cGw3h1DxW9Egpg1lITwCjHofkkZSgWJco 0eO2GF3rPRG9tVA7CqAt0TGLANGNbH2HvhkYU= 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=uGI4csuNiLS6fTAVR1vQNcVBEWSJTSk1oAgwrrB5NsI=; b=lkJ4ux5ngcP5UAn2FZe/5dCytRArPO9o5S2UatQPomxmgOhxxMVpzg/lDeD/M9Q+mo 3dO6rEW1nJ31w8Wmu4po5Vn01cpOGc8vOgwswFi205C/mMYF8pxCwywXC/pmBN7JiicY 5faM0hXuyzpVbb8L1UQ6grAPnkfk/Sju9eZaQS0IKWE9kC4qctRX9KFiLgZqBaSWwOdQ wwKB+Hbe/PvB6dIROvGYWcTqPsEEmJEpF/sOJWU2DjZto2p73aXKjGp/lk/5OysCaBA7 JAfkTQyLrbdpHWuZnAXuae1Gwc2pz0s/CIEVOU/YuEg5wceAAJfuHyzazeJywaRQrbbV zFnA== X-Gm-Message-State: AOAM530RFX6gU9gZb4c7wZ/dTifLD8JqsQxFXjV+tya2pii56KQpmyhc u8RTR1hGQ4cAQn3y0sKr09J8gWM//423Siuo9yoZIA== X-Received: by 2002:a9d:6052:: with SMTP id v18mr2509589otj.303.1596010704124; Wed, 29 Jul 2020 01:18:24 -0700 (PDT) MIME-Version: 1.0 References: <1596000620-4075-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> In-Reply-To: <1596000620-4075-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp> From: Daniel Vetter Date: Wed, 29 Jul 2020 10:18:12 +0200 Message-ID: Subject: Re: [PATCH] vt: Handle recursion in vc_do_resize(). To: Tetsuo Handa Cc: Greg Kroah-Hartman , Jiri Slaby , Linux Fbdev development list , Bartlomiej Zolnierkiewicz , Linux Kernel Mailing List , dri-devel , syzbot 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 Wed, Jul 29, 2020 at 8:58 AM Tetsuo Handa wrote: > > syzbot is reporting OOB read bug in vc_do_resize() [1] caused by memcpy() > based on outdated old_{rows,row_size} values, for resize_screen() can > recurse into vc_do_resize() which changes vc->vc_{cols,rows} that outdates > old_{rows,row_size} values which were read before calling resize_screen(). > > Minimal fix might be to read vc->vc_{rows,size_row} after resize_screen(). > A different fix might be to forbid recursive vc_do_resize() request. > I can't tell which fix is the better. > > But since I guess that new_cols == vc->vc_cols && new_rows == vc->vc_rows > check could become true after returning from resize_screen(), and I assume > that not calling clear_selection() when resize_screen() will return error > is harmless, let's redo the check by moving resize_screen() earlier. > > [1] https://syzkaller.appspot.com/bug?id=c70c88cfd16dcf6e1d3c7f0ab8648b3144b5b25e > > Reported-by: syzbot > Signed-off-by: Tetsuo Handa Ok, I have actual insight on this one here, and I'm pretty sure this isn't the fix. Looking at the syzkaller splat we have a recursion of the form fb_ioctl -> fb_set_var -> fbcon_update_vcs -> fbcon_resize -> fb_set_var Which isn't supposed to be happening. I've dug around recently in fbcon code, and this is a fairly common issue: You can update fbcon state both from fb_ioctl, but also from the vc side. To avoid the above recursion problems the code is using FBINFO_MISC_USEREVENT, and should only set that from fb_ioctl entry points. That's all fairly fragile, so I've done a bit of reworking, e.g. commit de29ae5c092bd9a5360cfabf174b0f783248d278 Author: Daniel Vetter Date: Tue May 28 11:02:56 2019 +0200 fbmem: pull fbcon_fb_blanked out of fb_blank as an example. I think doing the same for fb_set_var, i.e. only calling fbcon_update_vcs for the 3 callers that want it, should fix this recursion. I think that's the much more robust fix instead of trying to paper over the fallout of this recursion here and everywhere else. Can you look into reworking your patch like that? Cheers, Daniel > --- > drivers/tty/vt/vt.c | 24 +++++++++++++++++------- > 1 file changed, 17 insertions(+), 7 deletions(-) > > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c > index 42d8c67..952a067 100644 > --- a/drivers/tty/vt/vt.c > +++ b/drivers/tty/vt/vt.c > @@ -1217,7 +1217,24 @@ static int vc_do_resize(struct tty_struct *tty, struct vc_data *vc, > > if (new_cols == vc->vc_cols && new_rows == vc->vc_rows) > return 0; > + if (new_screen_size > KMALLOC_MAX_SIZE || !new_screen_size) > + return -EINVAL; > > + /* > + * Since fbcon_resize() from resize_screen() can recurse into > + * this function via fb_set_var(), handle recursion now. > + */ > + err = resize_screen(vc, new_cols, new_rows, user); > + if (err) > + return err; > + /* Reload values in case recursion changed vc->vc_{cols,rows}. */ > + new_cols = (cols ? cols : vc->vc_cols); > + new_rows = (lines ? lines : vc->vc_rows); > + new_row_size = new_cols << 1; > + new_screen_size = new_row_size * new_rows; > + > + if (new_cols == vc->vc_cols && new_rows == vc->vc_rows) > + return 0; > if (new_screen_size > KMALLOC_MAX_SIZE || !new_screen_size) > return -EINVAL; > newscreen = kzalloc(new_screen_size, GFP_USER); > @@ -1238,13 +1255,6 @@ static int vc_do_resize(struct tty_struct *tty, struct vc_data *vc, > old_rows = vc->vc_rows; > old_row_size = vc->vc_size_row; > > - err = resize_screen(vc, new_cols, new_rows, user); > - if (err) { > - kfree(newscreen); > - vc_uniscr_free(new_uniscr); > - return err; > - } > - > vc->vc_rows = new_rows; > vc->vc_cols = new_cols; > vc->vc_size_row = new_row_size; > -- > 1.8.3.1 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch