font-size: 131131px; causes crash via libfreetype.so with very scary registers.

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
14 years ago
11 years ago

People

(Reporter: guninski, Assigned: pavlov)

Tracking

({crash, testcase})

Trunk
x86
Linux
Points:
---
Bug Flags:
wanted1.8.1.x -
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical] post 1.8-branch)

Attachments

(2 attachments)

font-size: 131131px; causes crash via libfreetype.so with very scary
registers.

macosx ppc and wine seem unaffected.
trunk only, ff 15 seems unaffected.

may be a duplicate of Bug 322345, but is exploitable from html.


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912558994496 (LWP 4831)]
0x00002aaaad7cc540 in memset () from /lib64/tls/libc.so.6
(gdb) info stack
#0  0x00002aaaad7cc540 in memset () from /lib64/tls/libc.so.6
#1  0x00002aaaac66a172 in gray_raster_render ()
   from /usr/lib64/libfreetype.so.6
#2  0x00002aaaac668e5a in ps_hints_apply () from /usr/lib64/libfreetype.so.6
#3  0x00002aaaac6697f1 in gray_raster_render ()
   from /usr/lib64/libfreetype.so.6
#4  0x00002aaaac62f5f4 in FT_Outline_Render () from /usr/lib64/libfreetype.so.6
#5  0x00002aaaac62f69e in FT_Outline_Get_Bitmap ()
   from /usr/lib64/libfreetype.so.6
#6  0x00002aaaaae78aa1 in _render_glyph_outline (face=0x11b78c0, 
    font_options=0x10b9b58, surface=0x7fffff833518)
    at /opt/joro/firefox/mozilla/gfx/cairo/cairo/src/cairo-ft-font.c:1014
#7  0x00002aaaaae79c17 in _cairo_ft_scaled_glyph_init (
    abstract_font=0x10b9ae0, scaled_glyph=0x10b9ea0, info=3)
    at /opt/joro/firefox/mozilla/gfx/cairo/cairo/src/cairo-ft-font.c:1817
#8  0x00002aaaaae623dc in _cairo_scaled_glyph_lookup (scaled_font=0x10b9ae0, 

(gdb) x/i $rip
0x2aaaad7cc540 <memset+32>:     mov    %sil,(%rdi)
(gdb) info reg
rax            0x2aaab527c9ab   46912672090539
rbx            0x11b574e        18569038
rcx            0x101010101010101        72340172838076673
rdx            0x1      1
rsi            0x6c6c6c6c6c6c6c6c       7812738666512280684
rdi            0x2aaab527c9ab   46912672090539
rbp            0x1      0x1
rsp            0x7fffff832e78   0x7fffff832e78
r8             0x2aaaac66a100   46912525213952
r9             0x100    256
r10            0x4a     74
r11            0x11b01c0        18547136
r12            0x2aaab5279e88   46912672079496
r13            0x2      2
I believe most existing Gfx backends do something like limiting font size to screen height.  Gfx:Thebes probably doesn't...
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
Yeah, this is running into the issue bug 330957 ran into by accident -- we overflow some internal data structures and end up memsetting memory we don't own.  We should be sanity-checking our font sizes for positivity and not being too big, since apparently cairo/freetype don't deal well.
(In reply to comment #3)
> Yeah, this is running into the issue bug 330957 ran into by accident -- we
> overflow some internal data structures and end up memsetting memory we don't

i am not sure who overflows - cairo or some other library.
valgrind doesn't report overflow in firefox and this doesnt't look like under allocaton:
--DOMWINDOW == 6
==4749== Warning: set address range perms: large range 162434164, a 0, v 0
==4749== 
==4749== Invalid write of size 1
==4749==    at 0x11B1DD27: memset (mac_replace_strmem.c:464)
==4749==    by 0x136E3171: (within /usr/lib64/libfreetype.so.6.3.8)
==4749==    by 0x136E1E59: (within /usr/lib64/libfreetype.so.6.3.8)
==4749==    by 0x136E27F0: gray_raster_render (in /usr/lib64/libfreetype.so.6.3.8)
==4749==    by 0x136A85F3: FT_Outline_Render (in /usr/lib64/libfreetype.so.6.3.8)
==4749==    by 0x136A869D: FT_Outline_Get_Bitmap (in /usr/lib64/libfreetype.so.6.3.8)
==4749==    by 0x11EF0AA0: _render_glyph_outline (cairo-ft-font.c:1014)

The address to memset is computed based on the font size you put in (since we're memsetting inside a bitmap for a glyph from the font).  We're actually ending up with a negative number where we expect a positive one and so memsetting before the beginning of our buffer.

Or at least that's what I saw in bug 330957.
(In reply to comment #5)
> The address to memset is computed based on the font size you put in (since
> we're memsetting inside a bitmap for a glyph from the font).  We're actually
> ending up with a negative number where we expect a positive one and so
> memsetting before the beginning of our buffer.
> 

i am not sure that technically speaking this is an overflow :)

> Or at least that's what I saw in bug 330957.

is fixing the above is expected to fix this one?
just built the fox and still crash.



> is fixing the above is expected to fix this one?

No.  All we fixed in that bug is that now we have a correct font size for the "default" font size.
we currently clamp on linux to 2*screen height.  Not sure thats the best thing really, but probably not unreasonable.

I'm going to just clamp to 5000px for now and I think that'll be good enough.
Posted patch fixSplinter Review
Assignee: nobody → pavlov
Status: NEW → ASSIGNED
Attachment #219041 - Flags: review?(vladimir)
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
*** Bug 331180 has been marked as a duplicate of this bug. ***
I assume these are CSS pixels, not device pixels, right?
Group: security
Whiteboard: [sg:critical]
Flags: blocking1.9a1?
Flags: wanted1.8.1.x-
Whiteboard: [sg:critical] → [sg:critical] post 1.8-branch
crash test landed
http://hg.mozilla.org/mozilla-central/rev/7c453c8b877c
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.