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(-)
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 = {
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.
dri-devel@lists.freedesktop.org
-
Andi Shyti -
Andrzej Hajda -
Javier Martinez Canillas -
Lucas De Marchi -
Thomas Zimmermann