And your pulse audio service is running as which user now?
This is a local exploit but for any system supporting the mentioned combination of services, aka a lot of them, including the RHEL derivatives and likely Ubuntu.
> And your pulse audio service is running as which user now?
I'm not sure, I appear to be running pipewire. But assuming it's not my own account: not a user that will initiate an attack. A user account that allows logins or runs external servers would have to get compromised first, and at that point it can use the exploit directly with no need to touch pulseaudio.
If there's only one directory in your /home, it's very unlikely the urge for admins to patch this is directed at you.
> Pipewire runs under the pipewire user, managed by systemd or OpenRC. Which means any of their managed processes can start a new pipewire user process.
The box I checked has no pipewire user and it's running under the account I logged in with.
> A local priv-sec is one exploit [0] away from a remote one.
That only matters for accounts that talk to the outside world.
If I'm the only user, I'm not depending on security features to keep my account and the pipewire account safe from each other. Privilege escalation is a big threat for systems that are running in a significantly different way.
Yes, my account is. It's doing the decoding, not the pipewire account. It's not a cross-account attack that I need to defend from.
Maybe I wasn't clear. I'm saying exactly one account has meaningful exposure to the outside world, and it's the only one with valuable files. Not none, but also not multiple. It's effectively single user from a security perspective.
https://almalinux.org/blog/2025-06-18-test-patches-for-cve-2...