| Message ID | 20110524215917.4b01df45@neptune.home (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | a50d28de8d5085e0f34f96088a45cc156d022021 |
| Headers | show |
Hi Paul, On Tue, 24 May 2011 Bruno Prémont <bonbons@linux-vserver.org> wrote: > Since fb_info is now refcounted and thus may get freed at any time it > gets unregistered module unloading will try to unregister framebuffer > as stored in platform data on probe though this pointer may > be stale. > > Cleanup platform data on framebuffer release. > > CC: stable@kernel.org > Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org> > --- > This should also go into 2.6.39 stable as it didn't make it into 2.6.39 > with the rest of fb_info refcounting work. > > This comes from > [2.6.39-rc2, framebuffer] use after free oops > ... > [PATCH 0/2] fbcon sanity > thread Any chance of applying these two patches? I've had no feedback from you on them and they don't show up in your tree. Bruno -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Bruno, On Thu, Jun 02, 2011 at 08:18:57PM +0200, Bruno Pr??mont wrote: > On Tue, 24 May 2011 Bruno Pr??mont <bonbons@linux-vserver.org> wrote: > > Since fb_info is now refcounted and thus may get freed at any time it > > gets unregistered module unloading will try to unregister framebuffer > > as stored in platform data on probe though this pointer may > > be stale. > > > > Cleanup platform data on framebuffer release. > > > > CC: stable@kernel.org > > Signed-off-by: Bruno Pr??mont <bonbons@linux-vserver.org> > > --- > > This should also go into 2.6.39 stable as it didn't make it into 2.6.39 > > with the rest of fb_info refcounting work. > > > > This comes from > > [2.6.39-rc2, framebuffer] use after free oops > > ... > > [PATCH 0/2] fbcon sanity > > thread > > Any chance of applying these two patches? > > I've had no feedback from you on them and they don't show up in your tree. > Patchwork has been a bit spotty lately with some patches showing up and others not, so I've invariably missed a few. I've applied the first one now, and will address the second one separately. -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c index 53b2c5a..2bcfe32 100644 --- a/drivers/video/vga16fb.c +++ b/drivers/video/vga16fb.c @@ -1265,9 +1265,11 @@ static void vga16fb_imageblit(struct fb_info *info, const struct fb_image *image static void vga16fb_destroy(struct fb_info *info) { + struct platform_device *dev = container_of(info->device, struct platform_device, dev); iounmap(info->screen_base); fb_dealloc_cmap(&info->cmap); /* XXX unshare VGA regions */ + platform_set_drvdata(dev, NULL); framebuffer_release(info); }
Since fb_info is now refcounted and thus may get freed at any time it gets unregistered module unloading will try to unregister framebuffer as stored in platform data on probe though this pointer may be stale. Cleanup platform data on framebuffer release. CC: stable@kernel.org Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org> --- This should also go into 2.6.39 stable as it didn't make it into 2.6.39 with the rest of fb_info refcounting work. This comes from [2.6.39-rc2, framebuffer] use after free oops ... [PATCH 0/2] fbcon sanity thread --- -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html