ValveSoftware / halflife

Half-Life 1 engine based games

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[CS] [Linux] Crash when buying Kevlar+Helmet while already having Kevlar (and/or Helmet)

Fesiug opened this issue · comments

My game crashes whenever I buy Kevlar+Helmet with Kevlar left.
The crash occurs whether or not VGUI menus is enabled.
I haven't experienced this on the Windows version.

output_hq.mp4

I verified my game files and it fixed itself... woops :P ...

Nevermind

[CS] A quick buy of vest followed by vesthelm leads to buffer overflow

Issue transferred from #3701.
@bolokanar posted on 2023-12-10T18:08:56:

A quick buy of vest followed by vesthelm leads to a buffer overflow.

Easiest steps to reproduce:
Start a New game
Buy via console vest; vesthelm

Core dump if of any use: http://masteros.bulgars.org/crash_20231210195605_13.dmp

A workaround for now is to bind in reverse: bind key "vesthelm; vest"

Error:/home/$USER/.local/share/Steam/steamapps/common/Half-Life/.so: cannot open shared object file: No such file or directory
DemoPlayer::Init: couldn't get engine interface.

ERROR! System::AddModule: couldn't initialize module (null).

Can't "cmd", not connected

Unknown command from unsafe location. Ignoring.

STEAM Auth Server

Playing Startup Videos...

AppActive: active
AppActive: active
Usage:
Setmaster unavailable, start a server first.

WARNING: UDP_OpenSocket: port: 27015  bind: Address already in use

NET Ports:  server 27015, client 27005

couldn't exec maps/ka_stadium_load.cfg

[S_API] SteamAPI_Init(): Loaded '/home/$USER/.local/share/Steam/linux32/steamclient.so' OK.
CAppInfoCacheReadFromDiskThread took 7 milliseconds to initialize
dlmopen steamservice.so failed: steamservice.so: cannot open shared object file: No such file or directory
SteamInternal_SetMinidumpSteamID:  Caching Steam ID:  76561197960265728 [API loaded yes]
SteamInternal_SetMinidumpSteamID:  Setting Steam ID:  76561197960265728
Looking up breakpad interfaces from steamclient
Calling BreakpadMiniDumpSystemInit
SteamInternal_SetMinidumpSteamID:  Caching Steam ID:  76561197960265728 [API loaded yes]
SteamInternal_SetMinidumpSteamID:  Setting Steam ID:  76561197960265728
FakeIP enabled! Requesting a fake IP.

[SteamNetworkingSockets] SDR network config fetch first attempt failed.  HTTP 504.  .  Trying again.

Connection to Steam servers successful.

FakeIP allocation succeeded: 169.254.244.218:42104


Using FakeIP

Server IP address 169.254.244.218:42104

   VAC secure mode is activated.


BUILD 9899 SERVER (0 CRC)
Server # 1

Glad!atoR'S !n Adr3NaL!n3 connected
Couldn't open file overviews/ka_stadium.txt. Using default values for overiew mode.

Couldn't open file overviews/ka_stadium.txt. Using default values for overiew mode.

Glad!atoR'S !n Adr3NaL!n3 is joining the Counter-Terrorist force
Scoring will not start until both teams have players
*** buffer overflow detected ***: terminated
ERROR: ld.so: object '/home/$USER/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
crash_20231210195605_13.dmp[5060]: Uploading dump (out-of-process)
/tmp/dumps/crash_20231210195605_13.dmp
/home/$USER/.local/share/Steam/steamapps/common/Half-Life/hl.sh: line 83:  4994 Aborted                 ${DEBUGGER} "${GAMEROOT}"/${GAMEEXE} "$@"
crash_20231210195605_13.dmp[5060]: Finished uploading minidump (out-of-process): success = yes
crash_20231210195605_13.dmp[5060]: response: Discarded=1
crash_20231210195605_13.dmp[5060]: file ''/tmp/dumps/crash_20231210195605_13.dmp'', upload yes: ''Discarded=1''
pid 5060 != 5059, skipping destruction (fork without exec?)

I fiddled around with this a bit more.

Results from tests:

  1. If you buy vest and then buy vesthelm - crash

  2. If you buy vest and take damage to vest:
    a) you buy new vest - no crash
    b) you buy vesthelm - no crash

  3. If you buy vesthelm - no crash
    a) vesthelm get damage and you buy vest - crash
    b) vesthelm get damage and you buy vesthelm - crash

Also I should add that my initial observation that it is about doing it quickly is incorrect. It follows the above patterns no matter how much time.

This is the same bug as #3551, more incorrect buffer sizes getting passed in:

#0  0xf7fc4549 in __kernel_vsyscall ()
#1  0xf7888aa7 in ?? () from /lib/i386-linux-gnu/libc.so.6
#2  0xf7837685 in raise () from /lib/i386-linux-gnu/libc.so.6
#3  0xf78203ac in abort () from /lib/i386-linux-gnu/libc.so.6
#4  0xf787b3fc in ?? () from /lib/i386-linux-gnu/libc.so.6
#5  0xf793384c in __fortify_fail () from /lib/i386-linux-gnu/libc.so.6
#6  0xf793209f in __chk_fail () from /lib/i386-linux-gnu/libc.so.6
#7  0xf7932d95 in __swprintf_chk () from /lib/i386-linux-gnu/libc.so.6
#8  0xcfabd64f in swprintf (__fmt=0xffffa840 L"", __n=2048, 
    __s=0xcfbefa18 <gHUD+24856> L"")
    at /usr/include/i386-linux-gnu/bits/wchar2.h:292
#9  CHudVGUI2Print::VGUI2HudPrintArgs (this=0xcfbef9fc <gHUD+24828>, 
    charMsg=charMsg@entry=0xcfc04180 <CHudTextMessage::MsgFunc_TextMsg(char const*, int, void*)::szBuf> "", 
    sstr1=sstr1@entry=0xcfc04200 <CHudTextMessage::MsgFunc_TextMsg(char const*, int, void*)::szBuf+128> "", 
    sstr2=sstr2@entry=0xcfc04280 <CHudTextMessage::MsgFunc_TextMsg(char const*, int, void*)::szBuf+256> "", 
    sstr3=sstr3@entry=0xcfc04300 <CHudTextMessage::MsgFunc_TextMsg(char const*, int, void*)::szBuf+384> "", 
    sstr4=sstr4@entry=0xcfc04380 <CHudTextMessage::MsgFunc_TextMsg(char const*, int, void*)::szBuf+512> "", x=x@entry=-1, y=315, r=r@entry=1, 
    g=g@entry=0.70599997, b=b@entry=0.118000001)
    at ../cstrike/cl_dll/hud_vgui2print.cpp:323
#10 0xcface6a2 in CHudTextMessage::MsgFunc_TextMsg (
    this=0xcfbef794 <gHUD+24212>, pszName=pszName@entry=0x9d9cc18 "TextMsg", 
    iSize=iSize@entry=36, pbuf=pbuf@entry=0xf60d5560 <buf>)
    at ../cstrike/cl_dll/text_message.cpp:242
#11 0xcfacebb7 in __MsgFunc_TextMsg (pszName=0x9d9cc18 "TextMsg", iSize=36, 
    pbuf=0xf60d5560 <buf>) at ../cstrike/cl_dll/text_message.cpp:31

The game will shut down when anything on the server side sends a TextMsg user message. In this case the message seems to contain only empty strings so that won't prevent it either.

I should point out that Valve's own APIs take wchar_t buffers as size in bytes:
https://github.com/ValveSoftware/source-sdk-2013/blob/0d8dceea4310fde5706b3ce1c70609d72a38efdf/mp/src/public/tier1/ilocalize.h#L84

virtual void ConstructString(OUT_Z_BYTECAP(unicodeBufferSizeInBytes) wchar_t *unicodeOutput, int unicodeBufferSizeInBytes, const char *tokenName, KeyValues *localizationVariables) = 0;

Presumably this mistake was being made so often that they decided to just use size in bytes everywhere instead of updating to use ARRAYSIZE (or std::size in modern C++ code). Since they updated to a newer GCC compiler that enables buffer overflow protection the game keeps terminating execution when swprintf or related functions are called.

As for why sizeof is being used to begin with, this code was probably using char before and was updated to use wchar_t when everything was converted to use Unicode. Nowadays the recommendation is to use UTF-8 everywhere and converting only when needed to interface with the operating system and other APIs that need it.

Since the APIs that use wchar_t aren't part of the public SDK it is possible to switch to UTF-8, but some mods do use internal APIs so those will break. Since the steam_legacy branch is a thing this isn't worth worrying about, but if any APIs that use wchar_t today are made part of the SDK (e.g. VGUI2, see #2110) then it will no longer be possible to change them without breaking mods.

Related issues:
#1770 (also points out the incorrect buffer sizes in the scoreboard dialog which cause #3551 to happen)
#1800
#1843

] version 
Protocol version 48
Exe version 1.1.2.7/Stdio (cstrike)
Exe build: 23:26:01 Dec  9 2023 (9907)

At least on my end, no crashes. Tested all scenarios I listed previously.

] version 
Protocol version 48
Exe version 1.1.2.7/Stdio (cstrike)
Exe build: 23:26:01 Dec  9 2023 (9907)

At least on my end, no crashes. Tested all scenarios I listed previously.

image
image
Update 14 hours ago fixing the previously mentioned scoreboard issue. Going to retest soon.

The issue is fixed, I don't get the crash anymore.