Opened 11 years ago

Closed 3 years ago

Last modified 16 months ago

#6354 closed bug (fixed)

Forwarding a mail crashes app_server

Reported by: humdinger Owned by: mmlr
Priority: normal Milestone: R1/beta2
Component: Servers/app_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


This is hrev37527.

The attached spam mail (it's big, showing bug #) crashes the app_server when it's forwarded. I can't seem to get a backtrace to show up in syslog...

Attachments (1) (335.8 KB ) - added by humdinger 11 years ago.
spam mail crashes app_server when forwarded

Download all attachments as: .zip

Change History (8)

by humdinger, 11 years ago

Attachment: added

spam mail crashes app_server when forwarded

comment:1 by humdinger, 11 years ago

Yeah... the bug number I forgot: #4816 "Opening large mails unacceptably slow"...

comment:2 by waddlesplash, 3 years ago

Still reproducible?

comment:3 by humdinger, 3 years ago

It is. I see this in syslog:

vm_soft_fault: va 0x7320b000 not covered by area in address space
vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x7320b32c, ip 0x20a0f42, write 1, user 1, thread 0x1290
debug_server: Thread 4752 entered the debugger: Segment violation
stack trace, current PC 0x20a0f42  _DispatchMessage__9ServerApplRQ28BPrivate12LinkReceiver + 0x40fa:
  (0x732888c8)  0x20a4708  _MessageLooper__9ServerApp + 0x1b0
  (0x73288988)  0x2094888  _message_thread__13MessageLooperPv + 0x28
  (0x732889b8)  0x55b043  thread_entry + 0x23

comment:4 by mmlr, 3 years ago

The faulting instruction seems to be at a call to ServerFont::GetHasGlyphs(char const*, int, bool*) const here:

It uses a variable length array depending on the incoming message which immediately sounds dangerous. It should at the very least check if it'll fit into the stack and split up as needed, or better yet use a StackOrHeapArray instead. I have not yet looked at the actual numbers that are used here though.

comment:5 by mmlr, 3 years ago

Owner: changed from axeld to mmlr
Status: newin-progress

So numChars is over 500k in this case which clearly just overflows the stack. I've implemented a fix using BStackOrHeapArray, but looking through that file there's a lot of similar cases that need fixing and a lot of missing sanity checks of incoming values and error checks of allocations. It's somewhat surprising that such problems don't seem to happen more often.

comment:6 by mmlr, 3 years ago

Resolution: fixed
Status: in-progressclosed

Fixed, with a bunch of other similar and other problems, in hrev52698.

comment:7 by nielx, 16 months ago

Milestone: R1R1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.