[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <202501141326.E81023D@keescook>
Date: Tue, 14 Jan 2025 13:29:44 -0800
From: Kees Cook <kees@...nel.org>
To: Isaac Manjarres <isaacmanjarres@...gle.com>
Cc: Jeff Xu <jeffxu@...omium.org>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Jann Horn <jannh@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jeff Layton <jlayton@...nel.org>,
Chuck Lever <chuck.lever@...cle.com>,
Alexander Aring <alex.aring@...il.com>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Vlastimil Babka <vbabka@...e.cz>, Shuah Khan <shuah@...nel.org>,
kernel-team@...roid.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kselftest@...r.kernel.org,
Suren Baghdasaryan <surenb@...gle.com>,
Kalesh Singh <kaleshsingh@...gle.com>,
John Stultz <jstultz@...gle.com>
Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC
to memfd
On Tue, Jan 14, 2025 at 12:02:28PM -0800, Isaac Manjarres wrote:
> I think the main issue in the threat model that I described is that
> an attacking process can gain control of a more priveleged process.
I understood it to be about an attacker gaining execution control through
a rewritten function pointer, not that they already have arbitrary
execution control. (i.e. taking a "jump anywhere" primitive and
upgrading it to "execute anything".) Is the expectation that existing
ROP/JOP techniques make protecting memfd irrelevant?
--
Kees Cook
Powered by blists - more mailing lists