I dug through the user‐/message‐management routines and the one glaring bug is in the “list_unread_messages” routine. At the top of every login menu-loop it calls:

list_unread_messages(user->message_list);

Inside that function it:

1. walks the linked list and counts “unread” messages into a byte, bVar8
2. computes
   sVar6 = bVar8 * 8 // overhead per message
   + bVar8 * 0x48 // another per-message chunk
   + bVar8 << 5 // yet another
   which simplifies to sVar6 = 112 * (number of unread messages)
3. rounds that up, then does bzero(stack_ptr, sVar6);

All of that stack math is done by hand via pointer arithmetic on a small stack‐buffer (8 bytes!). If you have N unread messages, you will zero out 112⋅N bytes on the stack, clobbering saved registers, return addresses, etc. Since you can send arbitrary numbers of messages to a user while they are logged out, you can store up a large “unread” count and then, at your victim’s next login, overflow the stack and take over execution.

In short:

• list_unread_messages uses a user‐controlled count to calculate a giant “sVar6”
• it then bzero()’s that many bytes on the stack, into a tiny local buffer
• you overwrite the frame and return‐address

That is a classic stack-based buffer overflow, trivially weaponizable by sending many messages to an offline account.