lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230831203647.558079-1-mclapinski@google.com>
Date:   Thu, 31 Aug 2023 22:36:45 +0200
From:   Michal Clapinski <mclapinski@...gle.com>
To:     Jeff Layton <jlayton@...nel.org>,
        Chuck Lever <chuck.lever@...cle.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        Shuah Khan <shuah@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jeff Xu <jeffxu@...gle.com>, Aleksa Sarai <cyphar@...har.com>,
        Daniel Verkamp <dverkamp@...omium.org>,
        Kees Cook <keescook@...omium.org>,
        Marc Dionne <marc.dionne@...istor.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Cc:     Michal Clapinski <mclapinski@...gle.com>
Subject: [PATCH 0/2] fcntl: add fcntl(F_CHECK_ORIGINAL_MEMFD)

This change introduces a new fcntl to check if an fd points to a memfd's
original open fd (the one created by memfd_create).

We encountered an issue with migrating memfds in CRIU (checkpoint
restore in userspace - it migrates running processes between
machines). Imagine a scenario:
1. Create a memfd. By default it's open with O_RDWR and yet one can
exec() to it (unlike with regular files, where one would get ETXTBSY).
2. Reopen that memfd with O_RDWR via /proc/self/fd/<fd>.

Now those 2 fds are indistinguishable from userspace. You can't exec()
to either of them (since the reopen incremented inode->i_writecount)
and their /proc/self/fdinfo/ are exactly the same. Unfortunately they
are not the same. If you close the second one, the first one becomes
exec()able again. If you close the first one, the other doesn't become
exec()able. Therefore during migration it does matter which is recreated
first and which is reopened but there is no way for CRIU to tell which
was first.

Michal Clapinski (2):
  fcntl: add fcntl(F_CHECK_ORIGINAL_MEMFD)
  selftests: test fcntl(F_CHECK_ORIGINAL_MEMFD)

 fs/fcntl.c                                 |  3 ++
 include/uapi/linux/fcntl.h                 |  9 ++++++
 tools/testing/selftests/memfd/memfd_test.c | 32 ++++++++++++++++++++++
 3 files changed, 44 insertions(+)

-- 
2.42.0.283.g2d96d420d3-goog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ