| Message ID | 20220506132225.588379-1-javierm@redhat.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | fbdev: efifb: Fix a use-after-free due early fb_info cleanup | expand |
Am 06.05.22 um 15:22 schrieb Javier Martinez Canillas: > 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: Thomas Zimmermann <tzimemrmann@suse.de> > --- > > drivers/video/fbdev/efifb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > index cfa3dc0b4eee..b3d5f884c544 100644 > --- a/drivers/video/fbdev/efifb.c > +++ b/drivers/video/fbdev/efifb.c > @@ -259,12 +259,12 @@ static void efifb_destroy(struct fb_info *info) > memunmap(info->screen_base); > } > > - framebuffer_release(info); > - > if (request_mem_succeeded) > release_mem_region(info->apertures->ranges[0].base, > info->apertures->ranges[0].size); > fb_dealloc_cmap(&info->cmap); > + > + framebuffer_release(info); > } > > static const struct fb_ops efifb_ops = {
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
On 06.05.2022 15:22, 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: Andrzej Hajda <andrzej.hajda@intel.com> Regards Andrzej > > drivers/video/fbdev/efifb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > index cfa3dc0b4eee..b3d5f884c544 100644 > --- a/drivers/video/fbdev/efifb.c > +++ b/drivers/video/fbdev/efifb.c > @@ -259,12 +259,12 @@ static void efifb_destroy(struct fb_info *info) > memunmap(info->screen_base); > } > > - framebuffer_release(info); > - > if (request_mem_succeeded) > release_mem_region(info->apertures->ranges[0].base, > info->apertures->ranges[0].size); > fb_dealloc_cmap(&info->cmap); > + > + framebuffer_release(info); > } > > static const struct fb_ops efifb_ops = {
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") are these patches going through any CI before being applied? Maybe would be a good idea to cc intel-gfx mailing list on these fixes to have Intel CI to pick them up for some tests? pushed to drm-misc-fixes where the previous patch was applied. thanks LUcas De Marchi >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> >--- > > drivers/video/fbdev/efifb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > >diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c >index cfa3dc0b4eee..b3d5f884c544 100644 >--- a/drivers/video/fbdev/efifb.c >+++ b/drivers/video/fbdev/efifb.c >@@ -259,12 +259,12 @@ static void efifb_destroy(struct fb_info *info) > memunmap(info->screen_base); > } > >- framebuffer_release(info); >- > if (request_mem_succeeded) > release_mem_region(info->apertures->ranges[0].base, > info->apertures->ranges[0].size); > fb_dealloc_cmap(&info->cmap); >+ >+ framebuffer_release(info); > } > > static const struct fb_ops efifb_ops = { >-- >2.35.1 >
Hello Lucas, On 5/7/22 18:20, Lucas De Marchi wrote: > 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") > > are these patches going through any CI before being applied? Maybe would > be a good idea to cc intel-gfx mailing list on these fixes to have Intel > CI to pick them up for some tests? > I Cc'ed intel-gfx for this particular patch. I should had done it for the previous patches too, but I wasn't aware that Cc'ing that list would make it run on your CI. I tested locally the offending patch on an EFI platform before applying it and I don't know why it didn't fail there. Sorry all for the inconvenience. > pushed to drm-misc-fixes where the previous patch was applied. > Thanks.
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index cfa3dc0b4eee..b3d5f884c544 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/video/fbdev/efifb.c @@ -259,12 +259,12 @@ static void efifb_destroy(struct fb_info *info) memunmap(info->screen_base); } - framebuffer_release(info); - if (request_mem_succeeded) release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size); fb_dealloc_cmap(&info->cmap); + + framebuffer_release(info); } static const struct fb_ops efifb_ops = {
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> --- drivers/video/fbdev/efifb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)