Forwarding a mail crashes app_server

[humdinger]

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...

[humdinger]

spam mail crashes app_server when forwarded

[humdinger]

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

[waddlesplash]

Still reproducible?

[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

[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.

[mmlr]

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.

[mmlr]

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

[nielx]

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