linux-kernel - [PATCH 0/3] Fix shadow stack issues in clone error handling

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: <20230908203655.543765-1-rick.p.edgecombe@intel.com>
Date:   Fri,  8 Sep 2023 13:36:52 -0700
From:   Rick Edgecombe <rick.p.edgecombe@...el.com>
To:     x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Andy Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>, hjl.tools@...il.com,
        linux-kernel@...r.kernel.org
Cc:     rick.p.edgecombe@...el.com
Subject: [PATCH 0/3] Fix shadow stack issues in clone error handling

HJ reported a crash when running a new glibc test added two weeks ago, 
with his (out of tree) rebased glibc shadow stack patches on top. The 
issue turned out to be a bug in shadow stack clone error handling. The new 
test exercises clone(CLONE_PIDFD|CLONE_VFORK) with the fd limit exhausted, 
which causes the clone to fail after the shadow stack handling. A failure 
at that point will normally try to clean up the shadow stack that it 
allocated before returning the error to userspace. But for vfork, it 
should not do this as nothing was allocated and the thread's shadow stack 
is the parent's shadow stack too. The logic for not unmapping the thread's 
shadow stack for CLONE_VFORK children works in the normal (exec() or 
exit()) case, but is buggy in the clone failure case. So on clone failure 
with those particular args, the parent will end up with a missing shadow 
stack.

When working on the solution I did a review of the surrounding logic and 
found another more minor issue.

Patch 1 is the bug fix for the main issue, and 2 is the other issue. Patch
3 is optional and adds a new warning to catch the issue in patch 2.

Rick Edgecombe (3):
  x86/shstk: Handle vfork clone failure correctly
  x86/shstk: Remove useless clone error handling
  x86/shstk: Add warning for shadow stack double unmap

 arch/x86/include/asm/mmu_context.h |  3 +--
 arch/x86/kernel/process.c          |  7 -------
 arch/x86/kernel/shstk.c            | 33 ++++++++++++++++++++++++++++--
 3 files changed, 32 insertions(+), 11 deletions(-)

-- 
2.34.1