Your system information

• Steam client version (build number or date): 1779486452
• Distribution (e.g. Ubuntu): Ubuntu 26.04
• Opted into Steam client beta?: No
• Have you checked for system updates?: Yes
• Steam Logs: NA I have root caused the issue see below
• GPU: Nvidia

Please describe your issue in as much detail as possible:

The Steam client crashes because vgui2_s.so passes the return value of glGetString(GL_EXTENSIONS) directly to strstr() without checking for NULL. NULL is a documented possible return value per the OpenGL spec. When NULL is returned, strstr(NULL, _) invokes undefined behavior, and crashes.

I observed this when the i386 NVIDIA GL backend was non-functional while the x86-64 one continued to work. The underlying cause may vary; the fix is the missing NULL check regardless of trigger.

Steps for reproducing this issue:

1. Run Steam in an environment where glGetString(GL_EXTENSIONS) returns NULL. A reliable trigger: ensure the i386 NVIDIA libGL backend is non-functional (e.g., uninstall or break libnvidia-gl-<VER>:i386) while the x86-64 NVIDIA libs remain working.
2. Launch steam - segfault before the login UI appears.

This can occur as part of Ubuntu's update process depending on how the user has installed their drivers eg using the .run, rather than Ubuntu's built in installer.

Investigation via GDB

DEBUGGER=gdb steam

break __GI_strstr if (*(unsigned int*)($esp+4)) < 0x10000
run
...
Thread 1 "steam" hit Breakpoint 1, __GI_strstr (haystack=0x0,
      needle=0xeed74fbf "GL_NVX_gpu_memory_info") at ./string/strstr.c:77

Note at this point haystack is NULL. We need to determine why

bt
#0  __GI_strstr (haystack=0x0, needle="GL_NVX_gpu_memory_info") at strstr.c:77
#1  0xeedaa432 in ?? () from vgui2_s.so
#2  0xeedfe87c in ?? () from vgui2_s.so
#3  0xeee10cbf in ?? () from vgui2_s.so
#4  0xf50804ea in ?? () from steamui.so
... steam main ...

info sharedlibrary vgui2_s.so
0xeecaf000  0xef000000  vgui2_s.so

disassemble 0xeedaa3f0, 0xeedaa450
     ... omitted for brevity ...
     0xeedaa417:    movl $0x1f03,(%esp)   ; arg = GL_EXTENSIONS (0x1F03)
     0xeedaa41e:    call   0xeed90390        ; glGetString@plt - RETURNS NULL
     0xeedaa423:    pop    %edx
     0xeedaa424:    lea    -0x2798a9(%ebx),%edx ; needle = "GL_NVX_gpu_memory_info"
     0xeedaa42a:    pop    %ecx
     0xeedaa42b:    push   %edx                ; needle
     0xeedaa42c:    push   %eax                 ; haystack = NULL - *** NO CHECK ***
     0xeedaa42d:    call   0xeed90e20         ; strstr@plt - CRASH
  => 0xeedaa432:    add    $0x10,%esp    ; crashed in above caller, never runs.
     ... omitted for brevity ...

Note the call before the crashing call call 0xeed90390

x/5i 0xeed90390
0xeed90390:  endbr32
0xeed90394:  mov    $0x978,%ecx
0xeed90399:  jmp    *-0x67e0(%ebx)

Now lets decode the GOT slot

p /x *(unsigned int*)(0xeecaf000 + 0x339088)
$1 = 0xf0d4a5e0
info symbol *(unsigned int*)(0xeecaf000 + 0x339088)
glGetString in section wtext of /usr/lib/i386-linux-gnu/libGL.so.1

Looking at the disassembly since I do not have access to the code, the direct results of glGetString are being used without a NULL check. A possible retort is that glGetString shouldn't return null. However, refer to the OpenGL 4.6 spec (https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGetString.xhtml).

If an error is generated, glGetString returns 0.

Proposed Fix

Properly handle NULL when calling glGetString, ideally inform the user that the 32-bit drivers are not functional.

Related

When researching this bug, these issues matched my crash:

• #11980 (same crash signature dpy=0x47, closed not-planned)
• #13072 (same _XError/strchr stack)