sniper: bundled PipeWire 0.3.65 segfaults/deadlocks games on Bluetooth profile switch (fixed upstream in 1.2.2)

[ACEFGI]

Summary

The sniper runtime bundles pipewire 0.3.65-3+deb12u1~steamrt3.3+bsrt3.1 (upstream 0.3.65, released 2023-01-24). That version contains a known data race on SPA_IO_Buffers between the main thread and the pw-data-loop RT thread during port/format renegotiation, fixed upstream in PipeWire 1.2.2 (2024-07-29).

On a host with a modern PipeWire daemon, a Bluetooth headset switching profile (A2DP 48 kHz stereo <-> HSP/HFP 16 kHz mono) forces a mid-stream format renegotiation. The bundled 0.3.65 client then either SIGSEGVs in libspa-audioconvert.so or deadlocks the game.

In CS2 this reproduces on demand: with the headset connected, open Settings -> Audio and click the audio device selector dropdown. Enumerating devices re-creates the streams and drives the renegotiation straight into the racy window.

Observed with Counter-Strike 2, but this is a runtime-level defect and should affect any sniper game using audio with a Bluetooth headset.

Environment

Component	Version
OS	Fedora 44
Kernel	7.1.8-200.fc44.x86_64
CPU / GPU	Ryzen 9 5900X / Radeon RX 6700 XT (Mesa 26.1.7)
Host PipeWire	1.6.8
Host WirePlumber	0.5.14
Host BlueZ	5.87
sniper	3.0.20260805.254768, pressure-vessel 0.20260805.0
Bundled PipeWire	0.3.65-3+deb12u1~steamrt3.3+bsrt3.1

From sniper_platform_3.0.20260805.254768/files/manifest.dpkg:

libpipewire-0.3-0:amd64       0.3.65-3+deb12u1~steamrt3.3+bsrt3.1
libpipewire-0.3-modules:amd64 0.3.65-3+deb12u1~steamrt3.3+bsrt3.1
libspa-0.2-modules:amd64      0.3.65-3+deb12u1~steamrt3.3+bsrt3.1
pipewire-bin                  0.3.65-3+deb12u1~steamrt3.3+bsrt3.1

The host daemon flags the client as outdated on every stream creation:

pipewire[2300]: mod.client-node: detected old client version 4

Failure mode 1: SIGSEGV in libspa-audioconvert

kernel: pw-data-loop[1044288]: segfault at 21 ip 00007fdd599bba71 sp 00007fdd2c3fa270 \
  error 4 in libspa-audioconvert.so[31a71,7fdd5999a000+3f000]
systemd-coredump: Process 1044176 (cs2) of user 1000 dumped core.
  #0  0x00007fdd599bba71 n/a (/usr/lib/x86_64-linux-gnu/spa-0.2/audioconvert/libspa-audioconvert.so + 0x31a71)

Note the path /usr/lib/x86_64-linux-gnu/...: inside the pressure-vessel container, i.e. the runtime's bundled SPA plugin, not the host's /usr/lib64/.

objdump -d of the bundled libspa-audioconvert.so at the faulting offset:

31a54: cmp    %r15d,0x463c(%r12)   ; loop bound (port->blocks)
31a5e: mov    0x18(%r14),%rsi
31a65: lea    (%rax,%rax,4),%rdx   ; i * 5
31a69: mov    0x10(%rsi),%rax      ; -> datas array base
31a6d: lea    (%rax,%rdx,8),%rbx   ; &datas[i], stride 40 == sizeof(struct spa_data)
31a71: mov    0x20(%rbx),%rax      ; <-- FAULTS reading spa_data.chunk
31a75: movl   $0x0,(%rax)          ; chunk->offset = 0
31a7f: movl   $0x0,0x4(%rax)       ; chunk->size = 0

This is impl_node_process() in spa/plugins/audioconvert/audioconvert.c:

for (j = 0; j < port->blocks; j++) {
    bd = &buf->buf->datas[j];
    bd->chunk->offset = 0;
    bd->chunk->size = 0;

Fault address 0x21 with error 4 (userspace read of an unmapped page): the datas array base resolved to 1, i.e. a stale/freed buffer touched during renegotiation.

Failure mode 2: deadlock (same trigger)

On a subsequent launch the game hangs instead of crashing:

1044793 cs2          [S] futex_do_wait
1044924 pw-data-loop [S] ep_poll
1044926 pw-data-loop [S] ep_poll
1044930 pw-data-loop [S] ep_poll

Three pw-data-loop threads in a single client, consistent with repeated stream re-creation without teardown. Server side:

pipewire-pulse: mod.protocol-pulse: [] timeout on stream ... channel:0
... channels 0-7 all time out

This also wedges the host audio graph: host-side wpctl status hangs, and the desktop volume applet shows two simultaneously-selected default sinks until wireplumber/pipewire are restarted.

Trigger evidence

kernel: Bluetooth: hci0: SCO packet for unknown connection handle 257
bluetoothd: btd_service_connect() a2dp-source profile connect failed for XX:XX:XX:XX:XX:XX: Device or resource busy
wireplumber: <WpSiStandardLink> link failed: item deactivated before format was set

At crash time the card was stuck in the voice profile, with A2DP not offered at all:

Active Profile: headset-head-unit
  off                    : Off
  headset-head-unit-cvsd : Headset Head Unit (HSP/HFP, codec CVSD)
  headset-head-unit      : Headset Head Unit (HSP/HFP, codec MSBC)

Upstream fix

Upstream issue: https://gitlab.freedesktop.org/pipewire/pipewire/-/work_items/4094 (closed 2024-08-01). Different surface trigger (EasyEffects creating a new output stream), same underlying race.

The defect is not a missing null check at the crash site. It is a race on port->io / SPA_IO_Buffers between the main thread performing format renegotiation and the RT data loop running impl_node_process(). Fix commits, all dated 2024-07-29:

Commit	First release	Subject
628f292fb877440f9531cc452f81b59ac3471637	1.2.2	audioconvert: set IO_Buffers only when buffers are negotiated
0d7c20760e56fc60db13f7d972baed4bc0760767	1.2.2	impl-port: improve IO_Buffers management on ports
61dcd8dedec3c56375e333113156ec7fbd0cd372	1.3.81 / 1.4.0	audioconvert: set IO_Buffers only when buffers are negotiated (mainline)

The fix routes port->io assignment through the RT data loop, and clears SPA_IO_Buffers on SPA_PARAM_Format change before the port leaves the data-thread schedule, closing exactly the window an A2DP <-> HFP switch hits.

Verified by ancestry check against the upstream repo:

$ git merge-base --is-ancestor 628f292fb 0.3.65   # -> false (0.3.65 predates the fix)
$ git merge-base --is-ancestor 61dcd8ded 1.6.8    # -> true

0.3.65 is dated 2023-01-24, roughly 18 months before the fix landed.

Steps to reproduce

Deterministic path, via CS2's in-game device enumeration:

1. Host running a modern PipeWire (1.2.2+) and WirePlumber, with bluetooth.autoswitch-to-headset-profile at its default true.
2. Pair a Bluetooth headset exposing both A2DP and HSP/HFP, and connect it.
3. Launch CS2 (sniper runtime).
4. Open Settings -> Audio and click the audio device selector dropdown.
5. The game segfaults in libspa-audioconvert.so, or deadlocks with orphaned pw-data-loop threads.

Opening that dropdown makes the game enumerate and open the available audio devices, which tears down and re-creates streams and drives the port/format renegotiation into the racy window. This is consistent with the three orphaned pw-data-loop threads observed in failure mode 2: repeated stream re-creation without teardown.

The same crash also occurs without touching the menu, whenever the headset microphone is acquired and the profile autoswitches A2DP -> HSP/HFP mid-stream. The dropdown is simply the reliable way to trigger it on demand.

Workaround

Prevent the renegotiation entirely by disabling profile autoswitching on the host:

wpctl settings --save bluetooth.autoswitch-to-headset-profile false

Then reconnect the headset so it returns to a2dp-sink. This costs the headset microphone, since HFP is what was disabled, so it is not viable for players who need headset voice chat.

Request

Backport a current PipeWire into sniper. The steamrt README's backporting policy already names PipeWire as suitable for this (stable SONAME libpipewire-0.3.so.0), and recent sniper releases have carried updates for SDL, Vulkan-Loader, nss and others while PipeWire has stayed at the 0.3.65 baseline.

Possibly related, never root-caused: ValveSoftware/csgo-osx-linux#3349 ("Game Freeze when bluetooth headset is connected", closed 2023), which matches failure mode 2 and was closed after the reporter removed PipeWire entirely.

[ACEFGI]

Follow-up: this backport already exists in steamrt3c. It has simply never been applied to sniper.

steamrt3c is described in its own README as a variant of Steam Runtime 3 for internal use by the Steam client. It shares sniper's Debian 11 base, with a byte-identical glibc:

Runtime	glibc	pipewire
sniper (stable and beta, 3.0.20260805.254768)	2.31-13+deb11u14	0.3.65-3+deb12u1~steamrt3.3+bsrt3.1
steamrt3c	2.31-13+deb11u14 (identical)	1.4.2-1~steamrt3c.2
steamrt4	(newer)	1.4.2-1+steamrt4.1+bsrt4.2

Verifiable from the published source indexes:

• https://repo.steampowered.com/steamrt3/images/latest-public-stable/sources/ -> pipewire_0.3.65-3+deb12u1~steamrt3.3.dsc
• https://repo.steampowered.com/steamrt3c/images/latest-public-stable/sources/ -> pipewire_1.4.2-1~steamrt3c.2.dsc

From pipewire_1.4.2-1~steamrt3c.2.debian.tar.xz, debian/changelog:

pipewire (1.4.2-1~steamrt3c.1) steamrt3c; urgency=medium

  * Backport to steamrt3c (steamrt/tasks#982)
  * Changes inherited from steamrt4:
    ...
  * Backport changes:
    - d/control, d/*.install, d/*.symbols, d/*shlibs.local:
      Revert the t64 transition, preserving the pre-Debian-13 library
      name libpipewire-0.3-0 and the pre-Debian-13 time_t ABI for
      consistency with the rest of steamrt3c
    - d/control, d/gitlab-ci.yml: Use pkg-config instead of pkgconf
    - d/rules: Use override_dh_auto_install instead of
      execute_after_dh_auto_install

 -- Simon McVittie <smcv@collabora.com>  Wed, 06 May 2026 17:54:27 +0100

So the hard parts are already solved on a Debian 11 / glibc 2.31 base: PipeWire 1.4.2 builds there, and the t64 transition has been reverted to preserve the libpipewire-0.3-0 package name and the pre-Debian-13 time_t ABI. That same changelog shows the build already disables the daemon-side features (Bluetooth modules, audio interfaces, systemd integration, v4l2, echo-cancellation), which is precisely the client-only configuration a container needs, since the daemon lives on the host.

This means the request here is not "please attempt a new backport". It is "please apply the backport that already exists on steamrt3c to the steamrt/sniper branch as well".

For completeness, 1.4.2 is also the version in Debian trixie (1.4.2-1) and in bookworm-backports (1.4.2-1~bpo12+1), which fits the sniper README's stated preference for a version included in a stable release of Debian.

The sniper backporting policy also already names this library as a candidate:

In general, we can backport application-level libraries like Pipewire and SDL, subject to some conditions:

• The library needs to have a proper SONAME with a stable ABI, for example libpipewire-0.3.so.0.

And note that a full version bump is not strictly required to fix this bug:

If the library is not part of the dependency stack for graphics drivers (for example GTK, GNUTLS, Pipewire, SDL), then we can backport invididual bug-fixes and features without backporting an entire new upstream version.

A narrow cherry-pick of 628f292fb877440f9531cc452f81b59ac3471637 and 0d7c20760e56fc60db13f7d972baed4bc0760767 onto 0.3.65-3+deb12u1~steamrt3.3 would also close it, if a full 1.4.2 sync into sniper is undesirable.

There is precedent for both approaches in sniper's own release notes, which record a PipeWire 1.0.1 change being backported (steamrt/tasks#527) and a resync with the Debian 12.5 point release. Sniper's PipeWire has not been touched since January 2025.

[yohimik]

I checked the exact source package behind the current public-stable Sniper pin 3.0.20260805.254768, rather than inferring from the 0.3.65 base version. I fetched the .dsc and verified the upstream tarball and Debian patch tarball against the sizes and SHA-256 digests listed in that descriptor.

debian/patches/series contains these seven applied patches:

Don-t-automatically-start-pipewire-for-root-logins.patch
Don-t-build_same_binary_twice.patch
Fix_services.patch
fba7083f8ceb210c7c20aceafeb5c9a8767cf705.patch
7e2f6757fcc4eefd29cb47d8292714ac8014b9ef.patch
8680c74d1bd83b4969c9305171076b36f56d82fa.patch
pipewire-data-loop-set-thread-name.patch

None modifies spa/plugins/audioconvert/audioadapter.c, spa/plugins/audioconvert/audioconvert.c, or src/pipewire/impl-port.c in the areas changed by upstream 628f292f and 0d7c2076. In the exact packaged source, link_io() still initializes and installs SPA_IO_Buffers during link setup, and impl_node_port_set_io() still assigns port->io = data directly. It has neither activate_io() nor the synchronized do_set_port_io() added by 628f292f.

This confirms that the published Sniper source package does not carry those two fixes through downstream patches. It does not prove that their absence caused the reported crash: I did not run CS2 or reproduce the Bluetooth profile-switch trigger.

[smcv]

Observed with Counter-Strike 2, but this is a runtime-level defect and should affect any sniper game

For native Linux games that run in sniper (CS2, Dota 2, Retroarch, etc.), a likely workaround would be to force audio to go via pipewire-pulse PulseAudio compatibility in affected games:

Launch Options = SDL_AUDIO_DRIVER=pulseaudio %command%

Please try that on an affected system?

If this is reproducible in Windows games under Proton 10, selecting Proton 11 would probably work around it. Proton 11 runs under steamrt4, which is based on Debian 13.

A narrow cherry-pick of 628f292fb877440f9531cc452f81b59ac3471637 and 0d7c20760e56fc60db13f7d972baed4bc0760767 onto 0.3.65-3+deb12u1~steamrt3.3 would also close it, if a full 1.4.2 sync into sniper is undesirable.

Either taking 1.4.2 from steamrt3c or doing a targeted backport of individual bug fixes seems plausible, but we'll have to assess the risk/benefit ratio to choose which one is the better approach.

[smcv]

In CS2 this reproduces on demand: with the headset connected, open Settings -> Audio and click the audio device selector dropdown.

I wasn't able to reproduce this on a Steam Deck (OLED), using a speaker (Anker Soundcore 2) that appears to support HSP and HFP.

The host daemon flags the client as outdated on every stream creation

I do see this on the Steam Deck.

[smcv]

A backport of pipewire 1.4.2 (same as in Debian 13 and steamrt4) is likely to be added to sniper in its next beta update. Please opt-in to the client_beta branch of Steam Linux Runtime 3.0 (sniper), and re-test after the beta gets updated to 3.0.20260914.x or later.

I wasn't able to reproduce the crash, so I can't say for sure whether this backport addresses it, but hopefully it should.

[smcv]

Should be fixed in today's new Steam Linux Runtime 3.0 (sniper) beta 3.0.20260914.260626.