Opened 9 years ago

Closed 5 months ago

#6354 closed bug (fixed)

Forwarding a mail crashes app_server

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

Description

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)

crashing-spam.zip (335.8 KB) - added by humdinger 9 years ago.
spam mail crashes app_server when forwarded

Download all attachments as: .zip

Change History (7)

Changed 9 years ago by humdinger

Attachment: crashing-spam.zip added

spam mail crashes app_server when forwarded

comment:1 Changed 9 years ago by humdinger

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

comment:2 Changed 7 months ago by waddlesplash

Still reproducible?

comment:3 Changed 5 months ago by humdinger

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 Changed 5 months ago by mmlr

The faulting instruction seems to be at a call to ServerFont::GetHasGlyphs(char const*, int, bool*) const here: https://git.haiku-os.org/haiku/tree/src/servers/app/ServerApp.cpp#n2192

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 Changed 5 months ago by mmlr

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 Changed 5 months ago by mmlr

Resolution: fixed
Status: in-progressclosed

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

Note: See TracTickets for help on using tickets.