Remote crash exploit via malformed ScEvent clone sync packet (b3258 +0x1701C90)

[the-big-gs]

What happened?

A player on the server sent a crafted clone sync packet that crashed
every client on the server simultaneously. The crash happens inside
the ScEvent sync node linked list unlink operation at offset +0x1701C90.

The attacker needs to be inside a vehicle. When they trigger it,
everyone crashes including themselves, then they reconnect and repeat.

I captured a full memory dump during a controlled reproduction and
analyzed it with WinDbg. The crash is caused by a non-canonical
pointer (0x400000003d9eb4c2) being loaded into rcx at +0x1701C88
from attacker-controlled next->next data inside the ScEvent node,
then used as a write target at +0x1701C90 with no validation.

There is a heap spray in the dump confirming the packet was
manually crafted: pattern 0x82828282 -> 0x02020202 -> 0x81818181
inside a valid RAGE allocation (0x0aadbeef header confirmed).

This is not the same crash as PR #4100. That one is at +0xF2BC09
(archetype dereference). This one is at +0x1701C90 (linked list
write) and has no existing fix.

Expected result

Malformed sync packets should be rejected or validated before the linked list unlink operation processes them.

Reproduction steps

1. A player joins the server and gets inside a vehicle
2. All clients on the server crash simultaneously with
   ACCESS_VIOLATION c0000005 at FiveM_b3258_GTAProcess+0x1701C90
3. The attacker reconnects and repeats

Note: I am the victim in this case, not the attacker.
The above is what was observed. The exact packet crafting
method is unknown to me, but the full memory dump confirms
the crash path and the intentional heap spray pattern.

Full dump (11GB): https://mega.nz/file/0QMkjJjJ#gNYAG8vW2XG4fhkZUiMBBpFj66tVh--8jU61BNHvnx8

Importancy

Crash

Area(s)

FiveM

Specific version(s)

Artifact 34629

Additional information

Crash details from dump:

Fault address: FiveM_b3258_GTAProcess+0x1701C90
Exception: 0xC0000005 write to 0x400000003d9eb4d2
Node type: ScEvent (ASCII confirmed in dump at 0x29f8b7ce030)
Entity netID: 298, entityID: 300

The unlink function at +0x1701C70 reads next->next at +0x1C7B,
writes it to list_head at +0x1C7F, then loads it back into rcx
at +0x1C88 with no canonical check before the write at +0x1C90.
Adding a canonical address check between +0x1C88 and +0x1C90
would fix this specific path.

Full dump attached: a58cf9d0-48ee-48e2-be5b-138cf3f4700b-full.dmp

[divocbn]

Hi, please avoid posting full dumps publicly since it contains sensitive information.

From my own experience, I can tell you that unfortunately there are again too many crash exploits circulating, and the team doesnt have the resources to address them right now, so as always, just be patient.