From 6823ed46584e753de3aba48a00ab738ab009a860 Mon Sep 17 00:00:00 2001 From: Justus Winter Date: Wed, 8 Feb 2017 13:49:41 +0100 Subject: gpg,common: Make sure that all fd given are valid. * common/sysutils.c (gnupg_fd_valid): New function. * common/sysutils.h (gnupg_fd_valid): New declaration. * common/logging.c (log_set_file): Use the new function. * g10/cpr.c (set_status_fd): Likewise. * g10/gpg.c (main): Likewise. * g10/keylist.c (read_sessionkey_from_fd): Likewise. * g10/passphrase.c (set_attrib_fd): Likewise. * tests/openpgp/Makefile.am (XTESTS): Add the new test. * tests/openpgp/issue2941.scm: New file. -- Consider a situation where the user passes "--status-fd 3" but file descriptor 3 is not open. During the course of executing the rest of the commands, it's possible that gpg itself will open some files, and file descriptor 3 will get allocated. In this situation, the status information will be appended directly to whatever file happens to have landed on fd 3 (the trustdb? the keyring?). This is a potential data destruction issue for all writable file descriptor options: --status-fd --attribute-fd --logger-fd It's also a potential issue for readable file descriptor options, but the risk is merely weird behavior, and not data corruption: --override-session-key-fd --passphrase-fd --command-fd Fixes this by checking whether the fd is valid early on before using it. GnuPG-bug-id: 2941 Signed-off-by: Justus Winter --- common/sysutils.c | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'common/sysutils.c') diff --git a/common/sysutils.c b/common/sysutils.c index e67420f18..a796677ba 100644 --- a/common/sysutils.c +++ b/common/sysutils.c @@ -1281,3 +1281,14 @@ gnupg_get_socket_name (int fd) return name; } #endif /*!HAVE_W32_SYSTEM*/ + +/* Check whether FD is valid. */ +int +gnupg_fd_valid (int fd) +{ + int d = dup (fd); + if (d < 0) + return 0; + close (d); + return 1; +} -- cgit v1.2.3