Hi all, We were recently made aware by a bug report [1] that when the strip executable from binutils 2.36-3 in [core] is run within a fakeroot, it does not keep the correct file ownership during stripping, but indiscriminately assigns ownership to root:root instead. This causes issues with executables that make use of setuid, setgid or capabilities and should be owned by a user other than root. The incorrect ownership in combination with these attributes could lead to a potential local privilege escalation. The issue is caused by the fact that binutils 2.36-3 is compiled using glibc 2.33, thus using a new syscall that fakeroot does not intercept correctly [2]. Following the bug report, pacman was patched [3] to correctly handle file ownership during stripping itself, instead of relying on binutils to restore the correct ownership. Additionally, all packages built with binutils 2.36 were scanned for usage of setuid, setgid or capabilities (either during packaging or using an install script). A small number of packages was found, but these turned out to be false positives or operated on files that are already supposed to be owned by root anyway. We conclude that users were not exposed to any vulnerable packages affected by this issue [4]. Note that the fix to pacman only covers the stripping process run automatically by pacman. If strip is run inside a PKGBUILD, either manually or as part of a build system like qmake [5], file ownership will still be set to root:root. Please double-check all your packages to see whether they execute strip on files that should not be owned by root. Since it is unclear when fakeroot will be updated to work with glibc 2.33, permissions will have to be fixed manually after running strip by an appropriate chown call in this case. Note however that generally strip should not be run inside a PKGBUILD at all as it breaks creating debug packages, and should be disabled if run by default by the build system. [1] https://bugs.archlinux.org/task/69584 [2] https://sourceware.org/pipermail/binutils/2021-February/115252.html [3] https://git.archlinux.org/pacman.git/commit/?id=88d054093c1c99a697d95b26bd9a... [4] https://md.archlinux.org/TAiOYgKzQl-1cJxDaQlB_g [5] https://github.com/archlinux/svntogit-packages/commit/138105f29cb29d7b7ebdff... Greetings, Arch Linux Security Team