[CVE-2023-30571]README: vulnerability on implicite directory creationaccepted/tizen/base/riscv/20231123.094518accepted/tizen/base/20231015.230507sandbox/backup/libarchive_3.6.2_20231207

There's a race condition with the umask() execution in multi-threaded
use of the libarchive.
It's the users responsibility to mutex archive_write_disk_header()
call.

Change-Id: I50a9495680e101dada09cd4559782061c6efdb87
Signed-off-by: Peter Kaestle <peter.kaestle@nokia.com>

1 files changed, 11 insertions, 0 deletions

diff --git a/README.md b/README.md
index 4040762..57b7cff 100644
--- a/README.md
+++ b/README.md
@@ -192,6 +192,17 @@ questions we are asked about libarchive:
   functions.  On those platforms, libarchive will use the non-thread-safe
   functions.  Patches to improve this are of great interest to us.
 
+* 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.
+
 * In particular, libarchive's modules to read or write a directory
   tree do use `chdir()` to optimize the directory traversals.  This
   can cause problems for programs that expect to do disk access from