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/logging.c | 3 +++ 1 file changed, 3 insertions(+) (limited to 'common/logging.c') diff --git a/common/logging.c b/common/logging.c index 8c70742cc..ac130535c 100644 --- a/common/logging.c +++ b/common/logging.c @@ -570,6 +570,9 @@ log_set_file (const char *name) void log_set_fd (int fd) { + if (! gnupg_fd_valid (fd)) + log_fatal ("logger-fd is invalid: %s\n", strerror (errno)); + set_file_fd (NULL, fd); } -- cgit