Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Fri, 6 May 2022 17:44:44 +0200
From:   Andi Shyti <andi.shyti@linux.intel.com>
To:     Javier Martinez Canillas <javierm@redhat.com>
Cc:     linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
        Thomas Zimmermann <tzimmermann@suse.de>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
        Peter Jones <pjones@redhat.com>,
        Andrzej Hajda <andrzej.hajda@intel.com>,
        Helge Deller <deller@gmx.de>
Subject: Re: [Intel-gfx] [PATCH] fbdev: efifb: Fix a use-after-free due early
 fb_info cleanup
Message-ID: <YnVCbJJ5DmhkD5WA@intel.intel>
References: <20220506132225.588379-1-javierm@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220506132225.588379-1-javierm@redhat.com>
Precedence: bulk

Hi Javier,

On Fri, May 06, 2022 at 03:22:25PM +0200, Javier Martinez Canillas wrote:
> Commit d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather
> than .remove") attempted to fix a use-after-free error due driver freeing
> the fb_info in the .remove handler instead of doing it in .fb_destroy.
> 
> But ironically that change introduced yet another use-after-free since the
> fb_info was still used after the free.
> 
> This should fix for good by freeing the fb_info at the end of the handler.
> 
> Fixes: d258d00fb9c7 ("fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove")
> Reported-by: Ville Syrj?l? <ville.syrjala@linux.intel.com>
> Reported-by: Andrzej Hajda <andrzej.hajda@intel.com>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>

Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>

Andi