Hi. Apologies if my list etiquette is bad, I am noob here. There was a 2021 commit to libblkid, https://github.com/util-linux/util-linux/commit/6db368598962ea8b0329ae148ab878fd458f2533 commit label "Optimize the blkid_safe_string() function" This is potentially an unsafe change and may allow shell command injection. 1. The shell command blkid has a mode "-o udev" which was designed to output information about block devices in a LABEL=VALUE format for consumption by shell scripts. I have seen more than one instance (I am looking at one now in a commercial product) where userspace script has done: eval $(blkid -o udev ...) 2. One of the fields returned by blkid (e.g. for a USB stick) is the volume label, which would be controllable by an attacker inserting a USB stick. The blkid 'udev' command code is aware of this danger and sanitizes the volume label and other attacker-controllable strings by calling the function blkid_safe_string(...) in libblkid. Here is the blkid code that attempts to sanitize this string, calling libblkid : https://github.com/util-linux/util-linux/blob/b1f8b5740d81d813a2ea9ae1db8f059e5bee3b60/misc-utils/blkid.c#L280 3. In previous versions of libblkid the blkid_safe_string function used to strip several dangerous ascii characters that would have allowed command injection (specifically; backtick, parenthesis, etc. It still allowed '$' which is a little dubious). The commit 6db3685 I linked to above, dating from 2021 (which was accepted) rewrites the ..safe_string function and now allows all printable ascii chars from 32-127, including all shell-dangerous characters; essentially blkid_safe_string is much less safe - in fact downright dangerous if the "-o udev" mode output of blkid is evaluated in a shell. Proof of concept: 1. Format a removable USB stick (e.g. /dev/sdc1) with a VFAT volume label e.g. "$(reboot)" 2. Run the commit listed above: "blkid -o udev -p /dev/sdc1" 3. Observe that the output of blkid has not stripped dangerous characters and includes the line ID_FS_LABEL=$(reboot) 4. If you want to feed that output into eval or run it as a bash script, be my guest. 5. This behavior did not happen prior to commit 6db368598962ea8b0329ae148ab878fd458f2533 - the blkid output would be ID_FS_LABEL=$_reboot_ this is still not ideal (the '$' was preserved so it looks for an environment variable which can be abused to leak information etc, ...but at least would not result in command execution. I suggest this commit be removed because in simple terms the "blkid_safe_string" is now much less safe (depending on the threat model). Thanks, Richard Aplin