[Webkit-unassigned] [Bug 28131] [Haiku] Adding font-specific files to WebCore.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Aug 21 01:22:06 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=28131





--- Comment #20 from Maxime Simon <simon.maxime at gmail.com>  2009-08-21 01:22:06 PDT ---
(In reply to comment #16)
> (From update of attachment 34894 [details])
> Not sure where familyName comes from, but i suspect it's from CSS, and that
> means you have a buffer overflow vulnerability here.  Never use strcpy --
> always strncpy.  That said, wth is a font_family?  From reading this it looks
> like it's just a string?

font_family is in fact a simple array of chars.
definition from the BeBook:
typedef char font_family[B_FONT_FAMILY_LENGTH + 1]
But you're right using strncpy would be more secure than a simple strcpy.

> > +    else {
> > +	   // If no font family is found for the given name, we use a generic
> font.
> > +	   if (BString(familyName.string()).FindFirst("Sans") != B_ERROR)
> > +	       strcpy(family, "DejaVu Sans");
> > +	   else if (BString(familyName.string()).FindFirst("Serif") != B_ERROR)
> 
> > +	       strcpy(family, "DejaVu Serif");
> > +	   else if (BString(familyName.string()).FindFirst("Mono") != B_ERROR)
> > +	       strcpy(family, "DejaVu Mono");
> > +	   else // This is the fallback font.
> > +	       strcpy(family, "DejaVu Serif");
> This code seems to repeatedly create the same bstring, which seems
> unnecessarily expensive.  More over i'm fairly sure AtomicString has all the
> logic you need to do this without ever creating a bstring anyway.

Indeed, I should have investigate to see if AtomicString has some functions to
find a motif in a string.

> > +    }
> > +
> > +    font_family* fontFamily = &family;
> > +    return fontFamily;
> You can't return a pointer to a stack allocated variable, it's just not okay --
> the code structure implies that the compiler even warned you.

If I wrote "return &family" then the compiler warned me. But if I made it like
this, it didn't complain (maybe an issue in our gcc version). Anyway, I made
some tests and it works as it. It may be a stroke of luck and it will not work
another time.

> Once again, don't return pointers to locals -- you're far better off just using
> out parameters

In fact, it should be better. :)
Thanks for the advices.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list