From: Konstantin Khorenko <khorenko@virtuozzo.com>
To: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>,
Vasileios Almpanis <vasileios.almpanis@virtuozzo.com>
Cc: devel@openvz.org
Subject: [Devel] [PATCH hci-8.1 5/7] exec: refuse to preserve memory across a privilege-changing exec
Date: Wed, 14 Oct 2026 19:12:24 +0200 [thread overview]
Message-ID: <20261014-b4-prep-khorenko-vstor-149847-3-doexec-oracle-fixes-v1-5-e34cbe0d1440@virtuozzo.com> (raw)
In-Reply-To: <20261014-b4-prep-khorenko-vstor-149847-3-doexec-oracle-fixes-v1-0-e34cbe0d1440@virtuozzo.com>
Since commit 9e6d16a6c0a1 ("oracle/mm: introduce VM_EXEC_KEEP") a pinned
page in a preserved range is shared with the new image instead of
copied, and since commit 37d9f55655ea ("oracle/mm: do not write protect
COW mappings when preserving across exec") it is not copied on write
either: long-term pins taken before the exec, such as a VFIO DMA mapping
or io_uring fixed buffers, keep pointing at it. That is what the feature
is for, DMA into the pages has to continue across exec.
When the exec is a secure one, for a set-id or file-capability binary or
an LSM transition that asks for AT_SECURE, this hands a write path into
the privileged image to whoever drives those pins: the user who set them
up keeps the device or the io_uring fd in another process and has the
device or io_uring write into the memory of the new image. The pins
cannot be revoked, and zapping the ranges in the old mm does not touch
them.
Refuse the exec with EPERM from reserve_preserved_mem() when
bprm->secureexec is set. bprm_creds_from_file() has already run at that
point and the check is before the point of no return, so the caller gets
the error from execve(), can drop MADV_DOEXEC and retry. secureexec is
computed before the ptrace downgrade, so a ptraced setuid exec is
refused as well. A root task that regains dropped capabilities through
exec does not set it and is not refused.
Fixes: 9e6d16a6c0a1 ("oracle/mm: introduce VM_EXEC_KEEP")
https://virtuozzo.atlassian.net/browse/VSTOR-150232
Feature: oracle/mm: MADV_DOEXEC madvise() flag
Assisted-by: LLM
Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
---
fs/exec.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/exec.c b/fs/exec.c
index 5bf856e829af3..49a0a9693eb8a 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1021,6 +1021,10 @@ static int reserve_preserved_mem(struct linux_binprm *bprm)
if (!preserve)
return 0;
+ /* Pins taken under the old credentials outlive the exec. */
+ if (bprm->secureexec)
+ return -EPERM;
+
/* A clone is either counted here or already visible in the task list. */
spin_lock(&mm->page_table_lock);
if (mm->exec_keep_active || mm->exec_keep_clones)
--
2.43.0
_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel
next prev parent reply other threads:[~2026-10-14 17:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 17:12 [Devel] [PATCH hci-8.1 0/7] mm, exec: fix the MADV_DOEXEC code we carry from Oracle Konstantin Khorenko
2026-10-14 17:12 ` [Devel] [PATCH hci-8.1 1/7] oracle/mm: take a file reference when preserving a file-backed VMA Konstantin Khorenko
2026-10-14 17:12 ` [Devel] [PATCH hci-8.1 2/7] oracle/mm: refuse MADV_DOEXEC on special mappings Konstantin Khorenko
2026-10-14 17:12 ` [Devel] [PATCH hci-8.1 3/7] oracle/mm: keep a MADV_DOEXEC range from becoming executable Konstantin Khorenko
2026-10-14 17:12 ` [Devel] [PATCH hci-8.1 4/7] oracle/exec, elf: look for the opt-in note in every PT_NOTE segment Konstantin Khorenko
2026-10-14 17:12 ` Konstantin Khorenko [this message]
2026-10-14 17:12 ` [Devel] [PATCH hci-8.1 6/7] selftests/mm: check that a setuid exec refuses preserved memory Konstantin Khorenko
2026-10-14 17:12 ` [Devel] [PATCH hci-8.1 7/7] selftests/mm: check MADV_DOEXEC on /dev/zero and exec permission Konstantin Khorenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261014-b4-prep-khorenko-vstor-149847-3-doexec-oracle-fixes-v1-5-e34cbe0d1440@virtuozzo.com \
--to=khorenko@virtuozzo.com \
--cc=andrey.drobyshev@virtuozzo.com \
--cc=devel@openvz.org \
--cc=ptikhomirov@virtuozzo.com \
--cc=vasileios.almpanis@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox