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
Created cmake3 tracking bugs for this issue: Affects: epel-7 [bug 2210924] Created libarchive tracking bugs for this issue: Affects: fedora-37 [bug 2210925] Affects: fedora-38 [bug 2210927] Created mingw-libarchive tracking bugs for this issue: Affects: fedora-37 [bug 2210926] Affects: fedora-38 [bug 2210928]
Hi, In the description you've reported that this is affecting only libarchive-3.6.2 version. However, we don't have this version released in any of our products. Are older releases affected as well?
Adding upstream's documentation for this CVE: ``` The function `archive_write_disk_header()` is _not_ thread safe on POSIX machines and could lead to security issue resulting in world writeable directories. Thus it must be mutexed by the calling code. This is due to calling `umask(oldumask = umask(0))`, which sets the umask for the whole process to 0 for a short time frame. In case other thread calls the same function in parallel, it might get interrupted by it and cause the executable to use umask=0 for the remaining execution. This will then lead to implicitely created directories to have 777 permissions without sticky bit. ```