Messages in this thread | | | Date | Tue, 15 Aug 2006 09:16:48 +0100 | From | "Catalin Marinas" <> | Subject | Re: [PATCH] Fix memory leak in vc_resize/vc_allocate |
| |
On 14/08/06, Andrew Morton <akpm@osdl.org> wrote: > On Thu, 10 Aug 2006 15:22:21 +0100 > Catalin Marinas <catalin.marinas@arm.com> wrote: > > diff --git a/drivers/char/vt.c b/drivers/char/vt.c > > index da7e66a..31c8b32 100644 > > --- a/drivers/char/vt.c > > +++ b/drivers/char/vt.c > > @@ -730,7 +730,8 @@ int vc_allocate(unsigned int currcons) / > > visual_init(vc, currcons, 1); > > if (!*vc->vc_uni_pagedir_loc) > > con_set_default_unimap(vc); > > - vc->vc_screenbuf = kmalloc(vc->vc_screenbuf_size, GFP_KERNEL); > > + if (!vc->vc_kmalloced) > > + vc->vc_screenbuf = kmalloc(vc->vc_screenbuf_size, GFP_KERNEL); > > if (!vc->vc_screenbuf) { > > kfree(vc); > > vc_cons[currcons].d = NULL; > > hm. Maybe. I'd worry that the memory at vc->vc_screenbuf isn't of the > correct size and this patch will convert a leak into a buffer overrun.
My initial attempt was to free the kmalloc'ed buffer and reallocate it in vc_allocate (similar to the code in vc_resize) but I realised that vc_screenbuf kmalloced block is always of the vs_screenbuf_size length.
> Also, what's up with this, in vc_resize()? > > if (vc->vc_kmalloced) > kfree(vc->vc_screenbuf); > vc->vc_screenbuf = newscreen; > vc->vc_kmalloced = 1; > > if vc->vc_kmalloced means "there is kmalloced memory at vc->vc_screenbuf" > then this is wrong.
I think the above should be fine because vc_resize can be called either via vc_allocate->visual_init->fbcon_init when the buffer was not yet allocated or via a tty ioctl etc. and it needs to free the old buffer.
-- Catalin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |