The client crashes when trying to unpack a packet that has the sixup flag set, as `CNetClient` does not pass pointers for the output parameters `pSecurityToken` and `pResponseToken` to `CNetBase::UnpackPacket`.
Since the client does not handle sixup packets, checks are added to return an error and ignore the packet instead of crashing due to a null pointer access.
This was found by fuzzing the data returned by `net_udp_recv` with radamsa.
```
==6200==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f8d0fb8ba56 bp 0x7ffcbf67c7f0 sp 0x7ffcbf67c7a8 T0)
==6200==The signal is caused by a WRITE memory access.
==6200==Hint: address points to the zero page.
0 0x7f8d0fb8ba56 (/lib/x86_64-linux-gnu/libc.so.6+0xc4a56)
1 0x563a7e250fbe in mem_copy src/base/system.cpp:208
2 0x563a7e1bc6b6 in CNetBase::UnpackPacket(unsigned char*, int, CNetPacketConstruct*, bool&, int*, int*) src/engine/shared/network.cpp:263
3 0x563a7e1bf57e in CNetClient::Recv(CNetChunk*) src/engine/shared/network_client.cpp:100
4 0x563a7cfa76a2 in CClient::PumpNetwork() src/engine/client/client.cpp:2546
5 0x563a7cfb7cf6 in CClient::Update() src/engine/client/client.cpp:2838
6 0x563a7cfcfe47 in CClient::Run() src/engine/client/client.cpp:3214
7 0x563a7d04c631 in main src/engine/client/client.cpp:4702
8 0x7f8d0faf0d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
9 0x7f8d0faf0e3f in __libc_start_main_impl ../csu/libc-start.c:392
10 0x563a7cb28754 in _start (build-asan/DDNet+0x2472754)
==8315==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f4accfe5a56 bp 0x7ffcf1318530 sp 0x7ffcf13184e8 T0)
==8315==The signal is caused by a WRITE memory access.
==8315==Hint: address points to the zero page.
0 0x7f4accfe5a56 (/lib/x86_64-linux-gnu/libc.so.6+0xc4a56)
1 0x560413603200 in mem_copy src/base/system.cpp:208
2 0x56041356d9c7 in CNetBase::UnpackPacket(unsigned char*, int, CNetPacketConstruct*, bool&, int*, int*) src/engine/shared/network.cpp:224
3 0x5604135717c0 in CNetClient::Recv(CNetChunk*) src/engine/shared/network_client.cpp:104
4 0x5604123597e2 in CClient::PumpNetwork() src/engine/client/client.cpp:2546
5 0x560412369e36 in CClient::Update() src/engine/client/client.cpp:2838
6 0x560412381f87 in CClient::Run() src/engine/client/client.cpp:3214
7 0x5604123fe771 in main src/engine/client/client.cpp:4702
8 0x7f4accf4ad8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
9 0x7f4accf4ae3f in __libc_start_main_impl ../csu/libc-start.c:392
10 0x560411eda894 in _start (build-asan/DDNet+0x2472894)
```
src/base/system.c:261:15: runtime error: null pointer passed as argument 2, which is declared to never be null
/usr/include/string.h:44:28: note: nonnull attribute specified here
#0 0x565165b348dc in mem_copy /media/ddnet/src/base/system.c:261:2
#1 0x565165aeb27d in CNetBase::SendControlMsg(NETSOCKET, NETADDR*, int, int, void const*, int, int, bool) /media/ddnet/src/engine/shared/network.cpp:313:2
#2 0x565165aeeb4e in CNetConnection::SendControl(int, void const*, int) /media/ddnet/src/engine/shared/network_conn.cpp:169:2
#3 0x565165af08c5 in CNetConnection::Feed(CNetPacketConstruct*, NETADDR*, int) /media/ddnet/src/engine/shared/network_conn.cpp:367:6
#4 0x565165aec7d2 in CNetClient::Recv(CNetChunk*) /media/ddnet/src/engine/shared/network_client.cpp:94:174
#5 0x565165c5d5ea in CClient::PumpNetwork() /media/ddnet/src/engine/client/client.cpp:2571:24
#6 0x565165c67a71 in CClient::Update() /media/ddnet/src/engine/client/client.cpp:2856:2
#7 0x565165c72f4e in CClient::Run() /media/ddnet/src/engine/client/client.cpp:3237:4
#8 0x565165c94b7e in main /media/ddnet/src/engine/client/client.cpp:4341:11
#9 0x7fba5af2c151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
#10 0x5651659e1e0d in _start (/media/ddnet/DDNet+0x705e0d)
Purely automatic change. In case of conflict with this change, apply the
other change and rerun the formatting to restore it:
$ python scripts/fix_style.py
This means that we have a reliable and fast way to query for extended info,
while also not wasting network bandwidth.
The protocol is designed to be extensible, there's four bytes space for
encoding more request types (currently zeroed), and there's one string in each
response packet and one string for each player available (currently the empty
string).
The protocol itself has no problems with more than 64 players, although the
current client implementation will drop the player info after the 64th player,
because it uses a static array for storage.
Also fixes#130, the player list is just sorted each time new player info
arrives.
