From: Xiang Mei <xmei5@asu.edu>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Kees Cook <kees@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, linux-hardening@vger.kernel.org,
Uladzislau Rezki <urezki@gmail.com>,
"Gustavo A . R . Silva" <gustavoars@kernel.org>,
"H . Peter Anvin" <hpa@zytor.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Jennifer Miller <jmill@asu.edu>, Tiffany Bao <tbao@asu.edu>,
Ruoyu Wang <fishw@asu.edu>, Adam Doupe <doupe@asu.edu>,
Kyle Zeng <zengyhkyle@asu.edu>,
Yan Shoshitaishvili <yans@asu.edu>
Subject: Re: [PATCH v2] mm/vmalloc: widen guard region to defeat ENTER-based stack pivot
Date: Mon, 29 Jun 2026 18:22:44 -0700 [thread overview]
Message-ID: <CAPpSM+RhcW=xciX50W3G+2mUVNkmLfL1-BScPN_2TekMbzYVcg@mail.gmail.com> (raw)
In-Reply-To: <4e96acf4-25e7-4f30-8455-f9b3f49062be@intel.com>
On Mon, Jun 29, 2026 at 4:37 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 6/29/26 16:28, Xiang Mei wrote:
> >>> That is more than enough to step off the current stack, across the
> >>> one-page guard, and into the adjacent sprayed pages. When those pages
> >>> contain a return sled feeding a ROP chain, reaching any ENTER gadget
> >>> (opcode 0xc8, abundant as both intended and unintended gadgets) turns a
> >>> control-flow hijack into full ROP execution without any register control
> >>> at the hijack site, making it a one-gadget-style primitive that
> >>> significantly eases exploitation. The pivot happens after the control
> >>> transfer, so it is not constrained by CFI (kCFI/FineIBT).
> >> This all sounds super theoretical.
> >>
> >> I don't think we should mess with any of this without there being some
> >> sign that this is an actual, practical juicy exploit target.
> >>
> > Yes, I am sorry to reuse some incorrect comments I copied from v1.
> > I'll remove the CFI-related content since we assume we already have
> > control flow hijacking.
>
> I think you missed the main point: this all sounds *SUPER* theoretical.
> In other words, no real attacker would ever need to use ENTER like. Only
> make-believe attackers in imaginary academic papers. Those imagined
> attackers' only goal is to help mint PhD's.
>
> Upstream, we're concerned with practical attacks, not theoretical ones.
>
> You've done virtually nothing here to show that this is a practical
> attack that someone might use in the real world, outside of the
> PhD-minting industry.
>
> Please don't even try to send a v3 without addressing this.
This is a demo exploiting CVE-2026-31419 with this technique:
https://github.com/google/security-research/pull/397
I have no comment on your PhD-minting story. Let's keep this issue
free from personal stuff.
I would like to demo you that this technique is practical. Please tell
me what you need to prove that this bug is practical.
Thanks,
Xiang
next prev parent reply other threads:[~2026-06-30 1:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 21:47 Xiang Mei
2026-06-29 22:29 ` Dave Hansen
2026-06-29 23:28 ` Xiang Mei
2026-06-29 23:37 ` Dave Hansen
2026-06-30 1:22 ` Xiang Mei [this message]
2026-06-30 14:01 ` Dave Hansen
2026-06-30 14:58 ` Pedro Falcato
2026-07-01 7:23 ` Peter Zijlstra
2026-06-30 22:02 ` Xiang Mei
2026-06-30 22:05 ` Dave Hansen
2026-06-30 22:13 ` H. Peter Anvin
2026-06-30 22:47 ` Xiang Mei
2026-06-30 23:40 ` Dave Hansen
2026-06-30 23:48 ` Xiang Mei
2026-07-01 7:19 ` Peter Zijlstra
2026-06-30 14:40 ` Pedro Falcato
2026-06-30 15:15 ` Dave Hansen
2026-06-30 21:54 ` Dave Hansen
2026-06-30 21:41 ` Xiang Mei
2026-07-01 7:27 ` Peter Zijlstra
2026-07-01 7:48 ` Peter Zijlstra
2026-07-01 7:58 ` H. Peter Anvin
2026-07-01 8:31 ` Peter Zijlstra
2026-07-01 21:04 ` Xiang Mei
2026-07-10 18:58 ` Dave Hansen
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='CAPpSM+RhcW=xciX50W3G+2mUVNkmLfL1-BScPN_2TekMbzYVcg@mail.gmail.com' \
--to=xmei5@asu.edu \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=doupe@asu.edu \
--cc=fishw@asu.edu \
--cc=gustavoars@kernel.org \
--cc=hpa@zytor.com \
--cc=jmill@asu.edu \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=tbao@asu.edu \
--cc=tglx@kernel.org \
--cc=urezki@gmail.com \
--cc=x86@kernel.org \
--cc=yans@asu.edu \
--cc=zengyhkyle@asu.edu \
/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