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=-9.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 94D31C2D0A3 for ; Tue, 3 Nov 2020 20:03:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4312120E65 for ; Tue, 3 Nov 2020 20:03:09 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="V8kSaHMw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729634AbgKCUDI (ORCPT ); Tue, 3 Nov 2020 15:03:08 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:20084 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725997AbgKCUDH (ORCPT ); Tue, 3 Nov 2020 15:03:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1604433785; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=hs/zXGHlz9vLFkghpxlnSjQMAlQ6jTL7a/WUuTWkQUQ=; b=V8kSaHMw/xDs7HKMnAitNiYBTIHRM8pJeLEq9+tYTs+cScZbAvUQ8C73BtkLhKKssfHUfR xDkNkIAR0cI+XsLZQThIXWZUii1L57SGhlgm9wStW7sPoeEOeOoWGfd+zNsczEZUOVYGj5 sLU15tkUok1gEVVBFowBS9srBT1q0Sk= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-223-QmF2bu4SMemwnoMi8hTSbw-1; Tue, 03 Nov 2020 15:03:04 -0500 X-MC-Unique: QmF2bu4SMemwnoMi8hTSbw-1 Received: by mail-qv1-f72.google.com with SMTP id s9so8416184qvt.13 for ; Tue, 03 Nov 2020 12:03:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:user-agent:mime-version :content-transfer-encoding; bh=hs/zXGHlz9vLFkghpxlnSjQMAlQ6jTL7a/WUuTWkQUQ=; b=ndAYcIc4wIS6mKcDKbHVvqxZAqU6PXimXUXF/JK7wzXjSCZ7XkN05+3oJl+aVfvtJ0 L4DasWELkO8UxNzfD5mH8T9F/u6AmFOJ2upTpleU1yiiUgfgY3fOGWDPvldxwcUZfx7X uJRR5JLQRp+hQCYbasNyk2Kr7gCRUA1n/NyMLs8ntbjP7C6hW+wyeoH+CChIfNxZmsPK dbzlDdyaEfq0fnrqWnb5UWLjWBTLSGRrg5eVyY5mqVk1PveU0ECzDqcuoicwYFReQTpb /tpZ1/trJEB0Q0IV8G8Iz+v0AdyjaiOOOGwkQA//Ym4wm74Rb7NYKkD/fFBMzk53TXAY NuHw== X-Gm-Message-State: AOAM532klyuLzusTT0BA224SMSbqerUsWklwk4jRbnXI/XbJawQ8q4Hi ht7nIsU956utiCVgduf/Lu+Qs8Jy35tvRi095LRZwwvzgQdrRYuztGPbh+dSSFqfwRhdPhYccuw W91PNbV/NYadH+gc4FC2RO6n7 X-Received: by 2002:a05:620a:1193:: with SMTP id b19mr8991536qkk.42.1604433784110; Tue, 03 Nov 2020 12:03:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJz3Uif/P5KpG7c3Wmsy5fgC5l2WzpKVRev2cYaqxmHthv/mJZZ6oxzAqBLM1VOiN/jiyFC7lg== X-Received: by 2002:a05:620a:1193:: with SMTP id b19mr8991516qkk.42.1604433783827; Tue, 03 Nov 2020 12:03:03 -0800 (PST) Received: from Whitewolf.lyude.net (pool-108-49-102-102.bstnma.fios.verizon.net. [108.49.102.102]) by smtp.gmail.com with ESMTPSA id o21sm206002qko.9.2020.11.03.12.03.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Nov 2020 12:03:03 -0800 (PST) Message-ID: Subject: Re: [PATCH] drm/edid: Fix uninitialized variable in drm_cvt_modes() From: Lyude Paul Reply-To: lyude@redhat.com To: Ilia Mirkin Cc: dri-devel , Leon Romanovsky , David Airlie , Chao Yu , open list , Jason Gunthorpe , "# 3.9+" , Thomas Zimmermann , Kalle Valo , Kees Cook Date: Tue, 03 Nov 2020 15:03:01 -0500 In-Reply-To: References: <20201022165450.682571-1-lyude@redhat.com> <8d15a513bd38a01b3607e5c75b5754cc599fe33c.camel@redhat.com> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.1 (3.38.1-1.fc33) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-11-03 at 14:53 -0500, Ilia Mirkin wrote: > On Tue, Nov 3, 2020 at 2:47 PM Lyude Paul wrote: > > > > Sorry! Thought I had responded to this but apparently not, comments down > > below > > > > On Thu, 2020-10-22 at 14:04 -0400, Ilia Mirkin wrote: > > > On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote: > > > > > > > > Noticed this when trying to compile with -Wall on a kernel fork. We > > > > potentially > > > > don't set width here, which causes the compiler to complain about width > > > > potentially being uninitialized in drm_cvt_modes(). So, let's fix that. > > > > > > > > Signed-off-by: Lyude Paul > > > > > > > > Cc: # v5.9+ > > > > Fixes: 3f649ab728cd ("treewide: Remove uninitialized_var() usage") > > > > Signed-off-by: Lyude Paul > > > > --- > > > >  drivers/gpu/drm/drm_edid.c | 8 +++++++- > > > >  1 file changed, 7 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > > > > index 631125b46e04..2da158ffed8e 100644 > > > > --- a/drivers/gpu/drm/drm_edid.c > > > > +++ b/drivers/gpu/drm/drm_edid.c > > > > @@ -3094,6 +3094,7 @@ static int drm_cvt_modes(struct drm_connector > > > > *connector, > > > > > > > >         for (i = 0; i < 4; i++) { > > > >                 int width, height; > > > > +               u8 cvt_aspect_ratio; > > > > > > > >                 cvt = &(timing->data.other_data.data.cvt[i]); > > > > > > > > @@ -3101,7 +3102,8 @@ static int drm_cvt_modes(struct drm_connector > > > > *connector, > > > >                         continue; > > > > > > > >                 height = (cvt->code[0] + ((cvt->code[1] & 0xf0) << 4) + > > > > 1) * > > > > 2; > > > > -               switch (cvt->code[1] & 0x0c) { > > > > +               cvt_aspect_ratio = cvt->code[1] & 0x0c; > > > > +               switch (cvt_aspect_ratio) { > > > >                 case 0x00: > > > >                         width = height * 4 / 3; > > > >                         break; > > > > @@ -3114,6 +3116,10 @@ static int drm_cvt_modes(struct drm_connector > > > > *connector, > > > >                 case 0x0c: > > > >                         width = height * 15 / 9; > > > >                         break; > > > > +               default: > > > > > > What value would cvt->code[1] have such that this gets hit? > > > > > > Or is this a "compiler is broken, so let's add more code" situation? > > > If so, perhaps the code added could just be enough to silence the > > > compiler (unreachable, etc)? > > > > I mean, this information comes from the EDID which inherently means it's > > coming > > from an untrusted source so the value could be literally anything as long as > > the > > EDID has a valid checksum. Note (assuming I'm understanding this code > > correctly): > > > > drm_add_edid_modes() → add_cvt_modes() → drm_for_each_detailed_block() → > > do_cvt_mode() → drm_cvt_modes() > > > > So afaict this isn't a broken compiler but a legitimate uninitialized > > variable. > > The value can be anything, but it has to be something. The switch is > on "unknown & 0x0c", so only 4 cases are possible, which are > enumerated in the switch. oops, you're completely right lol. will figure out what the unreachable macro in the kernel is and use that in a respin of this patch > >   -ilia > -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've asked me a question, are waiting for a review/merge on a patch, etc. and I haven't responded in a while, please feel free to send me another email to check on my status. I don't bite!