To create the "steam input game controller" (which basically emulates an X Box game pad), steam needs direct access to /dev/uinput

To make this possible, the provided UDEV rules contain a rule which basically allows any user to create arbitrary input devices:

This is not a big issue if it was limited to creating game controllers. The problem with that is, that it also (easily) allows to create "virtual fake keyboards" and so basically allows attacks similar to "BadUSB" locally: https://sepiocyber.com/resources/case-studies/badusb-attack/
The problem behind this is not new and also described here: https://snapcraft.io/docs/uinput-interface
And was already mentioned in "steam context" here: https://www.reddit.com/r/archlinux/comments/viss0k/having_steam_installed_gives_your_user_readwrite/

This report is mainly to raise awareness of this issue. Having /dev/uinput "user accessible" could allow things like "sandbox escape", if, for example, a sandboxed Flatpak application has the same device access as the user logged into the system. In this case the sandboxed application can create a virtual keyboard, send keystroke "Alt + F2" (for Gnome) and follow with whatever command it intents to execute outside of the sandbox.

Possible fixes could include:

• Extend the kernel side (uinput module) with a parameter to limit which type of devices may be created (so an attempt to create a keyboard fails)
• Do not use uinput at all for "steam input" but add this feature to a separate library, attached with "LD_PRELOAD", so only the games, with the library preloaded, see this (fake) input device.