Bugzilla – Bug 1211842
VUL-0: CVE-2023-30571: libarchive: race condition in multi-threaded use of archive_write_disk_header() on posix based systems
Last modified: 2024-01-12 15:39:08 UTC
CVE-2023-30571 Libarchive through 3.6.2 can cause directories to have world-writable permissions. The umask() call inside archive_write_disk_posix.c changes the umask of the whole process for a very short period of time; a race condition with another thread can lead to a permanent umask 0 setting. Such a race condition could lead to implicit directory creation with permissions 0777 (without the sticky bit), which means that any low-privileged local user can delete and rename files inside those directories. https://groups.google.com/g/libarchive-announce https://github.com/libarchive/libarchive/issues/1876 References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-30571 https://bugzilla.redhat.com/show_bug.cgi?id=2210921 https://www.cve.org/CVERecord?id=CVE-2023-30571 https://github.com/libarchive/libarchive/issues/1876 https://groups.google.com/g/libarchive-announce
No patch yet.
the window is super small: libarchive/archive_write_disk_posix.c: umask(a->user_umask = umask(0)); a workaround might be to code this according to man 2 umask: Since Linux 4.7, the umask of any process can be viewed via the Umask field of /proc/[pid]/status. Inspecting this field in /proc/self/status allows a process to retrieve its umask without at the same time changing it. although it would really better if someone invents a new syscall for it or overloads umask itself ;) I am tempted to ignore this issue due to the small window.
This issue is being ignored because it's not a libarchive bug but rather an issue with its usage. See the following for more context: https://github.com/openembedded/openembedded-core/commit/ffa8f92aa6f8405d8fea117af2f212ba190de393