Your system information

Steam client version (build number or date): Built: Feb 1 2022, at 03:46:37
Distribution: Exherbo Linux, KDE X11 session, Kernel 5.16.4, NVIDIA 510.39.01 (beta) driver
Opted into Steam client beta?: Yes
Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

I just wanted to report this bug as well.

Additional information: dmesg is showing Chromium Embedded Framework (CEF) is constantly crashing

[   57.440050] traps: Chrome_IOThread[2231] trap invalid opcode ip:7f8893bbffe4 sp:7f888a1c2720 error:0 in libcef.so[7f8891475000+6fc6000]
[   81.126938] traps: Chrome_IOThread[2897] trap invalid opcode ip:7f64dc5eafe4 sp:7f64d2bed720 error:0 in libcef.so[7f64d9ea0000+6fc6000]
[  104.705789] traps: Chrome_IOThread[3204] trap invalid opcode ip:7f8055031fe4 sp:7f804b634720 error:0 in libcef.so[7f80528e7000+6fc6000]
[  128.647375] traps: Chrome_IOThread[3457] trap invalid opcode ip:7f5560d0dfe4 sp:7f5557310720 error:0 in libcef.so[7f555e5c3000+6fc6000]
[  152.392767] traps: Chrome_IOThread[6193] trap invalid opcode ip:7fa686766fe4 sp:7fa67cd69720 error:0 in libcef.so[7fa68401c000+6fc6000]

Also causing systemd-coredump to jump in causing additional load on the system until steam is closed.

Reverting back to stable rm ~/.steam/steam/package/beta allows the Steam client to work again, the previous beta was running fine as well.

Steam system log: steam-system-info.log

I can confirm the same issue here.

• Steam client version (build number or date): Built: Feb 1 2022, at 03:46:37
• Distribution: Fedora 35, Cinnamon DE, Kernel 5.16.4, open source amdgpu driver, Mesa 21.3.5
• Opted into Steam client beta?: Yes
• Have you checked for system updates?: Yes

Same issue on Fedora 35 (on desktop with NVIDIA/Plasma and on laptop with amdgpu/Gnome).
Browser in BPM also isn't working which I suspect might be related.

I too have the same issue on opensuse tumbleweed immediately after today's update of steam beta client.
Starting steam with -no-cef-sandbox makes the tabs function again.

[ 7784.836141] traps: Chrome_IOThread[27171] trap invalid opcode ip:7fa229239fe4 sp:7fa21f3cd420 error:0 in libcef.so[7fa226aef000+6fc6000]

src/steamexe/main.cpp (253) : Assertion Failed: reaping pid: 25128 -- CIPCServer::Thr src/steamexe/main.cpp (253) : Assertion Failed: reaping pid: 25128 -- CIPCServer::Thr Installing breakpad exception handler for appid(steam)/version(1643690051) assert_20220201101226_67.dmp[31374]: Uploading dump (out-of-process) /tmp/dumps/assert_20220201101226_67.dmp assert_20220201101226_67.dmp[31374]: Finished uploading minidump (out-of-process): success = yes assert_20220201101226_67.dmp[31374]: response: CrashID=bp-f8e84c0c-46e6-498d-9ea9-5e50d2220201 assert_20220201101226_67.dmp[31374]: file ''/tmp/dumps/assert_20220201101226_67.dmp'', upload yes: ''CrashID=bp-f8e84c0c-46e6-498d-9ea9-5e50d2220201''

System Info

Can I have a #metoo? Same version, dmesg messages and also on Fedora35.

Only way to play games is using Big Picture Play mode right now

Linking my comment in another issue here.
https://github.com/ValveSoftware/steam-for-linux/issues/8349#issuecomment-1026580093

Launching with -no-cef-sandbox works for me as well.

I am NOT experiencing this issue. Ubuntu 20.04, AMD GPU, Hardware accel on
Edit: What NPCs downvoted my comment, don't you think also knowing who is not affected by a bug helps in solving it?

Same problem on Fedora 35, KDE Wayland, Kernel 5.16.4, open source amdgpu driver, Mesa 21.3.5 and also -no-cef-sandbox workaround helped

Same on OpenSUSE TW, systeminfo.

tried rm -r ~/.local/share/Steam/config/htmlcache/*, no joy.
tried steam://flushconfig, no joy.

System information
Steam client version: 1643850988 / built Feb 3 2022 00:45:46
Distribution: Kubuntu 21.04 Hirsute (x86_64)
CPU: AMD Ryzen 7 5800x
NVIDIA GeForce GTX 1650 (Super, proprietary driver v470)
Opted into Steam client beta?: Yes
Checked for system updates?: Yes

Have the same problem. steamwebhelper crashes, Steam gui stays blank/black. Tried pins reset (forceful), tried steam complete wipe/reinstall.

Checked library linking, seems to be fine. Attaching steam info report:
https://pastebin.com/xfe6D8Hw

The crash of steamwebhelper looks like this:

virnik@Mainframe:~/.local/share/Steam/ubuntu12_32$ /home/virnik/.local/share/Steam/ubuntu12_64/steam-runtime-heavy.sh --unpack-dir=/home/virnik/.local/share/Steam/ubuntu12_64 --runtime=steam-runtime-heavy -- ~/.steam/steam/ubuntu12_64/steamwebhelper
setup.sh[331807]: Steam runtime environment up-to-date!
Neoprávněný přístup do paměti (SIGSEGV) (core dumped [obraz paměti uložen])
virnik@Mainframe:~/.local/share/Steam/ubuntu12_32$ 

assert_20220201135802_36.dmp.zip

library linking details are to be found here:
https://pastebin.com/2bLR0Pbg
https://pastebin.com/8c4qW84k

Library Pins
https://pastebin.com/buU4L7AY

Typical steam tty output relevant to steamwebhelper crash:

steamwebhelper.sh[1821093]: Runtime for steamwebhelper: defaulting to /home/virnik/.local/share/Steam/ubuntu12_64/steam-runtime-heavy
Illegal instruction (core dumped)

-no-cef-sandbox workaround doesn't work (no change), steam starts and runs, just with black pages.

I see libcef errors in system logs:
https://pastebin.com/S8jaBZFN

@kisak-valve : Please update impacted distro list by Kubuntu/Ubuntu (would be the same for both)

@kisak-valve Gentoo is also affected

custom distro: AMD dev linux kernel(git), xorg (git), mesa(git) vulkan/GL, busybox.

same crash, same workaround.

manjaro same issue

I can confirm the same issue here.

Steam client version (build number or date): Startup - updater built Feb  1 2022 03:46:32
Distribution: Arch Linux, KDE, Kernel 5.15.16-hardened1-1-hardened, AMD gpu, Mesa 21.3.3 
Opted into Steam client beta?: Yes
Have you checked for system updates?: Yes

I can also confirm that the aformentioned workaround (-no-cef-sandbox) works.

Same issue on Arch with the steam flatpak.

@kisak-valve Same issue on Debian Sid, with or without flatpak

Same issue on Debian Sid, works with -no-cef-sandbox.

Running Tumbleweed, same issue, workaround works but since I don't see that anyone else has included this, here is a chunk of 'journalctl -r' (run as user) which shows one of the systemd-coredump outputs which are occurring about 5 times a second:
steam_journalctl.txt

Steam (beta) client built: Feb 1 2022 at 03:46:37
Gentoo Linux.
Was seeing black/blank screens in the UI everywhere.
-no-cef-sandbox workaround works for me to restore the UI panes.

Not sure it's useful at this point, but same issue on my Gentoo install
-no-cef-sandbox fixed the issue for me too
Not posting more info because redondant with the rest, I also have the libcef.so related logs in dmesg if not running with -no-cef-sandbox

Also happens on openSUSE Tumbleweed 20220201 with Plasma 5.23.90 on Xorg here.
Just a quick side note that excessive crash dumping in /tmp for extended periods of time can also negatively affect the rest of your system if /tmp_'s capacity is limited on your system. It can then prevent other apps from being able to create their respective temp files correctly due to out-of-memory, potentially causing them to crash. Read more: https://wiki.archlinux.org/title/Steam/Troubleshooting#Preventing_crash_memory_dumps_

On fedora 35(even w/GE's tweaked nobara project after the fact of originally noticing it) and still same issue too. Works with -no-cef-sandbox.

Still the same issue with Feb 3 build on Fedora 35

Same issue here.
Just received an update a few minutes ago for the client (could not read the update log as it was black) but the problem is still present.

Pop_OS 21.10
Steam flatpak
Steam build: Feb 3 2022, at 00:45:52

@kisak-valve Can you give us more information what exactly the -no-cef-sandbox disables/changes? For me it sounds like it does not sandbox certain processes/applications or removes certain constraints? What I am most interested in: Does passing this flag have any security impact on the running steam (or child) applications?

Another workaround if you don't want to disable sandbox and just want to launch a game is to use "small mode" under view > small mode.

@kisak-valve I confirm that the workaround here works for me.

Another workaround if you don't want to disable sandbox and just want to launch a game is to use "small mode" under view > small mode.

I'm running steam currently with -no-browser and then switch small mode, otherwise the steamwebhelper process runs wild in the background. Better than disabling sandbox, I think...

Another workaround if you don't want to disable sandbox and just want to launch a game is to use "small mode" under view > small mode.

I'm running steam currently with -no-browser and then switch small mode, otherwise the steamwebhelper process runs wild in the background. Better than disabling sandbox, I think...

Thanks for the tip. In order to avoid steam and its spawns to slowly kill my system over period of time, I was using big picture mode, then killing remainder of webhelper processes. Using -no-browser is much better.

May as well leave my comment.

openSUSE Tumbleweed - 20220126
Nvidia 1650S
AMD FX8300
Steam Beta - Feb 3rd 2022 - 00:45:52
Steam Package Version 1643850988

Update resulted in black screen, unable to access any menu items.

Dmesg shows:

[21475.730781] steamwebhelper[23417]: segfault at d8 ip 00007ff02a858110 sp 00007ffee025f408 error 4 in libX11.so.6.4.0[7ff02a846000+8c000]

[21497.846294] traps: Chrome_IOThread[23906] trap invalid opcode ip:7fdc2dc3cfe4 sp:7fdc23c90420 error:0 in libcef.so[7fdc2b4f2000+6fc6000]

Curiously, the steamwebhelper.log shows:

[0204/134707.917873:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye

Which is a known glibc issue with Electron apps - see hence why no-sandbox works.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1029616820

Can confirm, I had AMD FX8350 two months back, also black screen. But no Xlib errors, had the same libcef like I have with Ryzen7 now.

I can confirm that it is the glibc issue @Radagast pointed out. After rebuilding glibc-2.34 to not use clone3 steam no longer crashes.
For the general mass we probably need an updated electron.

The patch to the chromium seccomp sandbox is here:

• https://bugs.chromium.org/p/chromium/issues/detail?id=1213452
• https://chromium-review.googlesource.com/c/chromium/src/+/2936184
• https://chromium.googlesource.com/chromium/src/+/218438259dd795456f0a48f67cbe5b4e520db88b

Via https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468

tacking onto g2p's comment:
https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1030242780

Here is the TLDR for the root cause, workarounds, and proper fix for the issue:

(1) glibc 2.34 enabled clone3, which breaks applications that use an outdated version of CEF:

https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1029616820

Curiously, the steamwebhelper.log shows:

    [0204/134707.917873:FATAL:gpu_data_manager_impl_private.cc(439)] GPU process isn't usable. Goodbye

Which is a known glibc issue with Electron apps - https://github.com/electron/electron/pull/31091 hence why no-sandbox works.

(2) The workaround for now is to build glibc with clone3 disabled:

https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1030166869

I can confirm that it is the glibc issue @Radagast pointed out. After rebuilding glibc-2.34 to not use clone3 steam no longer crashes.
For the general mass we probably need an updated electron.

(3) An alternative workaround without messing with glibc is to run steam with -no-cef-sandbox:

https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1026727945

Linking my comment in another issue here.
https://github.com/ValveSoftware/steam-for-linux/issues/8349#issuecomment-1026580093

Launching with -no-cef-sandbox works for me as well.

(4) This approach was applied to ubuntu's glibc for the time being:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468/comments/20
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468/comments/36

...
I've made a patched glibc package with clone3 disabled at https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+packages?field.name_filter=glibc, would be interesting to hear if it helps.
...
...
This bug was fixed in the package glibc - 2.34-0ubuntu3

---------------
glibc (2.34-0ubuntu3) impish; urgency=medium

  * d/patches/git-updates.diff: Update from release/2.34/master branch.
    - d/patches/ubuntu/Fix-close_range-closefrom-tests.patch,
      d/patches/ubuntu/fix-iconvconfig-directory.diff: removed as now
      upstream.
  * d/patches/ubuntu/disable-clone3.patch: Disable use of clone3 syscall
    to give Electron apps more time to get rebuilt. (LP: [#1944468](https://bugs.launchpad.net/bugs/1944468))

 -- Michael Hudson-Doyle <email address hidden> Tue, 28 Sep 2021 14:38:09 +1300
...

(5) The actual root cause, and proper fix, is to update the applications affected (in this case, steam beta) with a CEF version that contains a commit missing from older versions:

https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468/comments/9

Oh looks like these electron apps were built with a chromium that lacks
this commit
https://chromium.googlesource.com/chromium/src/+/218438259dd795456f0a48f67cbe5b4e520db88b
- which was only 4 months ago. And Chromium's sandbox defaults to crashing
on unknown syscalls. So I guess we're back to the "do we disable clone3 for
impish" question.

Same issue on ubuntu jammy (dev version 22.04), all the workarounds listed here also work. Stable version works fine. libc 2.35-0ubuntu1, glib 2.71.1-1.

To add some more information, it seems that the actual change that was made in Steam's Beta update was to enable CEF's sandboxing in steamwebhelper.

This resulted in at least three separate issues:

1. In runtime environments where glibc supports the new clone3(2) syscall (which allows sandbox escape), the steamwebhelper process is terminated with SIGSYS. This is because Steam's outdated libcef.so is missing the logic that forces glibc to fall back to the clone(2) syscall. (described by @GloriousEggroll in [#8373 (comment)](https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1030509625))
2. In runtime environments where unprivileged user namespaces aren't allowed, CEF's sandbox initialization fails. This is because the only two options for setting up CEF's sandbox aren't possible: it can't be set up using user namespaces, and a SETUID binary to set it up using the root user (usually called chrome-sandbox) is not present in Steam's runtime environment.
3. In sandboxed runtime environments such as Flatpak, CEF's sandbox initialization also fails. This is because Flatpak's own sandbox disallows both user namespaces and the use of SETUID binaries (both allow sandbox escape), but CEF doesn't support Flatpak's subsandboxing natively. The usual solution to this is to use Zypak, but Steam's elaborate runtime means that Zypak needs to be taught additional tricks to execute binaries inside Steam's runtime environment.

The three issues above all result in a similar user experience, but each of them is an entirely different issue with an entirely different solution. Perhaps it's better to disable steamwebhelper's sandboxing in an update and enable it again only when all three are handled.

@kisak-valve, @smcv, @refi64

IMHO ideally rather than teach zypak new tricks it would make more sense if Steam ran inside pressure-vessel and use zypak directly. Then it would work in same guaranteed way everywhere and this entire "Steam runtime libraries clash with host libraries" could be gradually forgotten.

IMHO ideally rather than teach zypak new tricks it would make more sense if Steam ran inside pressure-vessel and use zypak directly

pressure-vessel is not (currently) designed to be able to run Steam: it is designed to run individual games, and relies on setup that has been done by Steam itself.

Similarly, Steam is not designed to run inside pressure-vessel. Steam is not really designed to run in a container at all, and the Steam Flatpak app is not supported by Valve.

To add some more information, it seems that the actual change that was made in Steam's Beta update was to enable CEF's sandboxing in steamwebhelper.

This resulted in at least three separate issues

Thanks for breaking down these separate root causes: that'll make it much more likely that some or all of them can be fixed.

-no-cef-sandbox works (OpenSuse)

Also having this issue on Ubuntu Jammy, Kernel 5.16, under both X11 and Wayland, KDE Plasma. Commenting for updates.

Just for the record, GitHub has subscribe button at the right-hand panel so comments are just for sake of comments.

1. In runtime environments where glibc supports the new clone3(2) syscall

Steam beta 2022-02-10 (1644454953) has a workaround for this particular root cause. If you are running the beta branch, please make sure your Steam client is up-to-date (you should be able to use Steam → Check for Steam Client Updates... even if the rest of the UI is not working).

Distributions that would previously have been affected by this root cause include:

• Fedora 35
• Gentoo with default kernel options (and its derivatives such as Exherbo)
• Ubuntu 22.04 alphas with the jammy-proposed repository enabled (this disables the workaround used in 21.10)
• openSUSE Tumbleweed
• Arch Linux testing since 2022-02-10
• Debian experimental
• In general, rolling or fast-moving releases

Unaffected distributions (but note that these distributions can still suffer from one of the other root causes):

• Almost anything with glibc 2.33 or older
  • This includes older LTS distributions like Debian stable and Ubuntu LTS
  • As of 2022-02-10, Arch Linux is still in this category, but this is expected to change soon
  • As of 2022-02-10, Debian unstable is still in this category, but this is expected to change soon
• Ubuntu 21.10, because they applied a workaround
• Gentoo with the clone3 USE flag disabled, because this applies a workaround similar to the one in Ubuntu

1. In runtime environments where unprivileged user namespaces aren't allowed, CEF's sandbox initialization fails

Now reported separately as #8420.

This root cause affects older Debian releases (10 or older), older RHEL/CentOS releases (7 or older), and SteamOS 2.

It will also affect Arch Linux's non-default linux-hardened kernel, any system where /proc/sys/kernel/unprivileged_userns_clone exists and has been set to 0, and any system where /proc/sys/user/max_user_namespaces exists and has been set to 0.

Proton, Steam Linux Runtime and Flatpak users might recognise these as the same operating systems where a setuid version of bubblewrap is required.

If you are affected by this as a result of running an older OS, I would recommend upgrading to a newer operating system such as Debian 11 or RHEL 8 where unprivileged use of user namespaces is possible.

If you are affected by this as a result of configuring your kernel to prevent unprivileged processes from creating new user namespaces, I would recommend reassessing whether that configuration is a net security benefit. Unprivileged creation of user namespaces is increasingly often a requirement for sandboxing in web browsers like Firefox and Chrome/Chromium, and for container frameworks like Flatpak, Podman/Toolbx and Steam Linux Runtime. More information about the security trade-offs

1. In sandboxed runtime environments such as Flatpak, CEF's sandbox initialization also fails.

Now reported separately as #8421.

This affects all Flatpak versions on all host operating systems. The host operating system is not important here.

Debian experimental is also affected:
libc6:
Installed: 2.34-0experimental2
Candidate: 2.34-0experimental2
Version table:
*** 2.34-0experimental2 501
501 http://ftp.icm.edu.pl/pub/Linux/debian experimental/main amd64 Packages
501 http://http.debian.net/debian experimental/main amd64 Packages
500 /var/lib/dpkg/status
2.33-5 500
500 http://ftp.icm.edu.pl/pub/Linux/debian unstable/main amd64 Packages
500 http://ftp.icm.edu.pl/pub/Linux/debian testing/main amd64 Packages

Works now with latest update (Steam package version: 1644454953) on Fedora 35.

OK as well on OpenSUSE TW.

Arch has updated the toolchain today in testing. This issue now affects Arch Linux (testing) users.

Edit: Tracking this issue in https://bugs.archlinux.org/task/73713

@Scrumplex have you tried the Feb 9th Steam beta version that @grgrzybek mentioned that seems to have fixed it?

@DanMan I can confirm that updating the Steam Client fixes the issue. Unfortunate timing I guess :D

Works now with latest update (Steam package version: 1644454953) on Fedora 35.

This update avoids the first of the three root causes for this symptom that @doraskayo enumerated (glibc >= 2.34 with clone3() enabled). I've edited my comment above to reflect that.

As far as I know, this update does not address the second root cause (distros like Debian 10 that restrict user namespace creation). Workaround: run Steam with -no-cef-sandbox, or switch from the beta branch to the default (general availability) branch. See #8420.

As far as I know, this update also does not address the third root cause (running in a Flatpak sandbox). Workaround: run Steam with -no-cef-sandbox, or switch from the beta branch to the default (general availability) branch. See #8421.

Went ahead and upgraded to Jammy Jellyfish (Kubuntu 22.04 beta).

(steam:2031723): LIBDBUSMENU-GLIB-WARNING **: 13:09:19.760: Trying to remove a child that doesn't believe we're it's parent.
Installing breakpad exception handler for appid(steam)/version(1644454953)
Installing breakpad exception handler for appid(steam)/version(1644454953)
Installing breakpad exception handler for appid(steam)/version(1644454953)
src/common/html/chrome_ipc_client.cpp (410) : m_hCEFHandle == INVALID_PROCESS_HANDLE
src/common/html/chrome_ipc_client.cpp (410) : m_hCEFHandle == INVALID_PROCESS_HANDLE
Installing breakpad exception handler for appid(steam)/version(1644454953)
assert_20220210130923_42.dmp[2033555]: Uploading dump (out-of-process)
/tmp/dumps/assert_20220210130923_42.dmp
steamwebhelper.sh[2033558]: Runtime for steamwebhelper: defaulting to /home/virnik/.local/share/Steam/ubuntu12_64/steam-runtime-heavy
assert_20220210130923_42.dmp[2033555]: Finished uploading minidump (out-of-process): success = yes
assert_20220210130923_42.dmp[2033555]: response: CrashID=bp-51a7087b-e7d9-4a1f-a521-194642220210
assert_20220210130923_42.dmp[2033555]: file ''/tmp/dumps/assert_20220210130923_42.dmp'', upload yes: ''CrashID=bp-51a7087b-e7d9-4a1f-a521-194642220210''
Illegal instruction (core dumped)
src/steamexe/main.cpp (253) : Assertion Failed: reaping pid: 2031734 -- steam
src/steamexe/main.cpp (253) : Assertion Failed: reaping pid: 2031734 -- steam
Installing breakpad exception handler for appid(steam)/version(1644454953)
assert_20220210130924_45.dmp[2033754]: Uploading dump (out-of-process)
/tmp/dumps/assert_20220210130924_45.dmp
assert_20220210130924_45.dmp[2033754]: Finished uploading minidump (out-of-process): success = yes
assert_20220210130924_45.dmp[2033754]: response: CrashID=bp-2b6879a8-265a-4dd9-8609-82fff2220210
assert_20220210130924_45.dmp[2033754]: file ''/tmp/dumps/assert_20220210130924_45.dmp'', upload yes: ''CrashID=bp-2b6879a8-265a-4dd9-8609-82fff2220210''
Installing breakpad exception handler for appid(steam)/version(1644454953)
src/common/html/chrome_ipc_client.cpp (410) : m_hCEFHandle == INVALID_PROCESS_HANDLE
src/common/html/chrome_ipc_client.cpp (410) : m_hCEFHandle == INVALID_PROCESS_HANDLE
steamwebhelper.sh[2037418]: Runtime for steamwebhelper: defaulting to /home/virnik/.local/share/Steam/ubuntu12_64/steam-runtime-heavy
src/steamexe/main.cpp (253) : Assertion Failed: reaping pid: 2033556 -- steam
src/steamexe/main.cpp (253) : Assertion Failed: reaping pid: 2033556 -- steam
Illegal instruction (core dumped)

Remainder of logs is the same.

Tried with '-no-cef-sandbox', but to no dice. I run steam with '-no-browser' and in Compact Mode. This way, I do not observe any crashes, no gpu driver pegging, etc. But Compat Mode is very spartan, to be honest. Downloads, Run Options etc - aren't available. To change those or to update games, I have to run Big Picture Mode. A bit cumbersome, but works and all options are available. Steam becomes outdated as hell.

@virnik0: if running Steam as steam -no-cef-sandbox does not work around the crash, then you are experiencing a different issue that also has the symptom of breaking the web interface.

@smcv Possibly, but I have already tried to provide as much of details as possible, so knowing better in these terms is above me. See - I do have 'clean' prefix to which I install steam runtime. I re-set and re-checked pins, verified library links, reinstalled NVIDIA drivers and verified it works everywhere else (eg: not related to the issue). So only thing I am left with for now, is that I can run steam, and steam games, but I can't use Store/Library with webviews, as it keeps crashing and I keep seeing black screen/tabs.

Another annoying thing which I am trying to find out how to fix or help to fix this, is that if I keep steam unattended with self-crashing webviewer component, and if I played any GPU extensive game before, the steam process locking GPU driver never really exits, due to enormous spam from steamwebhelper crashes, which eventually leads to the kernel driver crashing as well, causing a cascade based on which it is more convenient to simply reboot (yeah, you can hunt for zombies, but it takes time).

I tried googling whether my problem is more relevant to this report or few others, finally settled here. If you believe I did a mistake, please be so kind and show me the right direction where my reports could be useful.

With $ steam -no-cef-sandbox:
https://pastebin.com/4TaJY8Qv

I just updated to the version 1644454953 and the web pages are being exhibited again.

@kisak-valve Hello, thank you. I have cut down my prior post, using pastebin link instead.

I have also raised new ticket, hopefully it would reflect the issue properly:
https://github.com/ValveSoftware/steam-for-linux/issues/8405

Can you give us more information what exactly the -no-cef-sandbox disables/changes? For me it sounds like it does not sandbox certain processes/applications or removes certain constraints? What I am most interested in: Does passing this flag have any security impact on the running steam (or child) applications?

Everything has a security impact, and in something as complicated as a modern web browser, few things are as simple as "this is good" or "this is bad".

When Steam displays web content, either trusted (Steam's own user interface and the Steam store) or untrusted (games' web pages), it is using a component called steamwebhelper which is based on CEF, an embeddable version of Chromium. The CEF sandbox is a security hardening feature that puts an extra boundary between some of the parts of CEF: it's the same as the sandboxing in the Chromium web browser, and means that even if an untrusted web page manages to exploit a bug in CEF's renderer, it can't escape from the sandbox to affect the rest of Steam, or the rest of your system.

A lot of security-hardening features are trade-offs that have a cost and a benefit, rather than being purely benefit, and this is one of them: it adds protection, but reduces portability and robustness. On some systems it protects CEF against some attacks, but on some systems it just doesn't work.

The CEF sandbox is not used in the current general-availability branch of Steam, and was newly enabled in recent beta versions of Steam, which is why those versions no longer work in some system configurations. Passing the -no-cef-sandbox option to a beta version of Steam returns it to (approximately) the behaviour of the general-availability branch.

There are three common reasons for the CEF sandbox to fail, as previously summarized in https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1030699670 and https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1033855419.

1. (The root cause originally seen in this issue) If your glibc is too new, it uses system calls that the CEF sandbox wasn't expecting, resulting in a crash. This is a bug in the version of CEF that Steam is using. The ideal solution would be to patch that version of CEF to be more compatible with new glibc, but the people who could do that are probably quite busy at the moment. The next best thing is to disable the CEF sandbox on these systems for now, which should happen automatically in a new Steam beta at some point.

2. (#8420) If your kernel is in an extra-paranoid configuration, the CEF sandbox might not be allowed to use the OS features that it needs. Some older operating systems like Debian 10 are set up like this, because disabling those features protects the OS from certain attacks; the cost of this is that unprivileged components like Chromium, Steam and Flatpak cannot use those features to protect themselves from different attacks. The CEF sandbox cannot work on these OS configurations, and the only thing Steam can do to resolve this is to disable the CEF sandbox if one of these operating systems is detected. This should happen automatically in a new Steam beta at some point. If you have one of these OS configurations, you should reassess whether disabling user namespaces is actually helping you: in Debian, there was some discussion between the kernel team, the security team and maintainers of apps that need these features, which led to these features being enabled by default since Debian 11.

3. (#8421) If you are running Steam as a Flatpak app, then all of Steam and all Steam games are already running in a sandboxed environment. The problem is that the CEF sandbox is not compatible with this: the two layers of sandboxing fight with each other. I've been looking into applying the same techniques that are used in Electron-based Flatpak apps, which would result in the CEF sandbox being replaced by a separate, more-restrictive Flatpak sandbox, but it's complicated and hard to get right. The next best thing is to disable the CEF sandbox automatically when running under Flatpak, which should happen automatically at some point in either a new Steam beta, or a new version of the Flatpak app, or both.

I'm closing this as it's working now.

Has this been fixed officially? If you are running the three scenarios listed here: https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1039339935 does the Web-UI work? I'm running the flatpak and it is still broken.

Has this been fixed officially?

I guess since the official steam beta works. Flatpak build afaik isn't officially suppoted by valve, but there's already MR for it though

What about scenarios 1 and 2? Shouldn't it detect if the configuration is invalid and then disable the sandbox? As far as I know it doesn't do this yet. Maybe OpenSUSE Tumbleweed have patched something (maybe glibc) to fix the issue.

There are at least three known root-causes for this symptom, so it isn't quite as simple as "it's fixed" or "it isn't fixed".

1. If your glibc is too new, it uses system calls that the CEF sandbox wasn't expecting, resulting in a crash.

As I said before, more recent Steam beta clients have a workaround for this. pgrep steamweb | xargs ps ww will show that the --disable-seccomp-filter-sandbox parameter has been passed to the steamwebhelper. This is a narrower version of the -no-cef-sandbox workaround. I have checked this on Fedora 35 (another affected OS) and it works.

This is the one that the initial reporter of this issue, @jpenala, was suffering from, so I think we can say that if it works for @jpenala then it's fixed.

1. If your kernel is in an extra-paranoid configuration, the CEF sandbox might not be allowed to use the OS features that it needs. Some older operating systems like Debian 10 are set up like this

This is not fixed. I have reported it separately as #8420.

1. If you are running Steam as a Flatpak app

This is not fixed. I have reported it separately as #8421. (@TheNamelessWonderer: this is the one that is affecting you.)

Also having this issue on Ubuntu Jammy, Kernel 5.16, under both X11 and Wayland, KDE Plasma. Commenting for updates.

Maybe related, or unrelated to Steam for Linux, but running Microsoft Teams with --no-sandbox (like in real Chrome) makes it work. I'm thinking there's something wrong going on in libcef and the latest >= 5.15.x kernels.

I don't know much but it seems to be due to a paranoid security setting in those kernels (I guess?). Is there a way to fix this without making a full kernel build from source? I'm also getting the invalid opcode error:

[  364.373909] traps: Chrome_IOThread[6142] trap invalid opcode ip:55bfd2a27774 sp:7f42c5162490 error:0 in teams[55bfd042c000+5fc7000]

This also seems to affect any other CEF/Chrome/Chromium/Electron based app, such as GitKraken or NordPass.

Thanks!

@darkguy2008: this is the Steam for Linux issue tracker, we cannot support non-Steam products.

The usual reason for the Chromium sandbox to have problems on upgraded systems is that after upgrading either glibc or the kernel, glibc automatically makes use of newer system calls provided by the new kernel; but the Chromium sandbox uses a strict seccomp filter that deliberately crashes the sandboxed process if it tries to use a system call that the sandbox wasn't expecting.

The short-term solution is for the developer of the crashing process (in this case Valve) to upgrade their version of Chromium/CEF/Chrome/Electron/etc. to one that knows about the newer system calls and will either allow them, or make them fail gracefully with ENOSYS, so that glibc thinks it is running on an older kernel and will fall back to an older code path.

The long-term solution is for Chromium to stop crashing on syscalls that it doesn't yet know about, and instead make them fail with ENOSYS so that glibc can fall back.

As I said https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1033855419, more recent Steam beta clients have a workaround for this.

I'm still affected by this bug on Gentoo as of now, both regular and beta Steam client versions.

Running with -no-cef-sandbox alleviates the issue, but weirdly rebuilding glibc with no clone3 support does not.

I'm still affected by this bug on Gentoo as of now, both regular and beta Steam client versions.

Please report a separate bug with full details, logs etc., mentioning Gentoo in the bug title.

If disabling clone3() in glibc does not work around the problem, then you have probably found a different way in which the CEF sandbox in Steam's version of CEF is incompatible with newer or rolling-release host systems, and Steam's developers will need enough information to figure out what.