From: sashiko-bot@kernel.org
To: "Jens Remus" <jremus@linux.ibm.com>
Cc: "Heiko Carstens" <hca@linux.ibm.com>,
linux-trace-kernel@vger.kernel.org,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
linux-s390@vger.kernel.org
Subject: Re: [RFC PATCH v2 09/24] unwind_user/eh_frame: Add support for reading .eh_frame section
Date: Fri, 21 Aug 2026 20:16:18 +0000 [thread overview]
Message-ID: <20260821201618.6DBA21F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260821195259.2688377-10-jremus@linux.ibm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] DW_CFA_restore and DW_CFA_restore_extended fail to restore the complete register rule state (offset and register number).
- [High] Bypass of pointer masking mitigation inside scoped_user_read_access_size blocks leading to a Spectre V1 vulnerability.
- [Medium] Integer overflow during instruction pointer advancement in DW_CFA_advance_loc4.
--
--- Patch [9]: [RFC PATCH v2 09/24] unwind_user/eh_frame: Add support for reading .eh_frame section ---
commit cd03be3d9017de830eb9301ff0da6dd6d08e69be
Author: Jens Remus <jremus@linux.ibm.com>
unwind_user/eh_frame: Add support for reading .eh_frame section
In preparation for using .eh_frame to unwind user space stacks, add an
eh_frame_find() interface for finding the .eh_frame[_hdr] information
associated with a given text address.
> diff --git a/kernel/unwind/eh_frame.c b/kernel/unwind/eh_frame.c
> index 8cf19c5298fde..21f40805b417f 100644
> --- a/kernel/unwind/eh_frame.c
> +++ b/kernel/unwind/eh_frame.c
[ ... ]
> +static __always_inline int __read_cie(struct eh_frame_section *sec,
> + unsigned long cie_addr,
> + struct eh_frame_cie *cie)
> +{
> + void __user *cie_ptr = (void __user *)cie_addr;
> + unsigned long cur = cie_addr, end;
[ ... ]
> + scoped_user_read_access_size(cie_ptr, 4 + length, Efault) {
> + /* Read CIE_ID (must be 0 for CIE; FDE otherwise) */
> + UNSAFE_GET_USER_INC(cie_id, cur, end, Efault);
[Severity: High]
Are we bypassing the pointer masking mitigation here?
The scoped_user_read_access_size() macro shadows the passed pointer (cie_ptr)
with a masked version to prevent speculative kernel accesses. However, the
memory read via UNSAFE_GET_USER_INC() uses the separate unmasked cur variable.
Could this allow speculative out-of-bounds reads to access kernel memory?
> + if (cie_id != EH_FRAME_CIE_ID)
> + return -EINVAL;
[ ... ]
> +static __always_inline int __read_fde(struct eh_frame_section *sec,
> + unsigned long fde_addr,
> + struct eh_frame_fde *fde)
> +{
> + void __user *fde_ptr = (void __user *)fde_addr;
> + unsigned long cur = fde_addr, end;
[ ... ]
> + scoped_user_read_access_size(fde_ptr, 4 + length, Efault) {
> + /* Read CIE pointer (offset from current position) */
> + UNSAFE_GET_USER_INC(cie_offset, cur, end, Efault);
[Severity: High]
Is this susceptible to the same pointer masking bypass as __read_cie()?
The unmasked cur variable is being used here instead of the masked fde_ptr.
> + cie_addr = cur - 4 - cie_offset;
> + if (cie_addr + EH_FRAME_CIE_MIN_LENGTH > fde_addr)
> + return -EINVAL;
> + if (cie_addr < sec->eh_frame_start)
> + return -EINVAL;
> + }
[ ... ]
> +static __always_inline int __do_cfi_insn(struct eh_frame_section *sec,
> + struct eh_frame_fde *fde,
> + unsigned long *cur_ptr,
> + unsigned long end,
> + unsigned long *ip_ptr,
> + unsigned long target_ip,
> + struct eh_frame_cfi_context *ctx)
> +{
[ ... ]
> + case DW_CFA_restore: {
> + u8 reg = DW_CFA_operand(opcode);
> + int idx;
> +
> + if (ctx->cie)
> + return -EINVAL;
> +
> + idx = reg_to_index(reg);
> + if (idx >= 0)
> + ctx->state.reg_rule[idx] = ctx->cie_state.reg_rule[idx];
> + break;
> + }
[Severity: High]
Does this properly restore the complete register state?
It appears only the rule type is restored from ctx->cie_state, but the
offset (reg_offset) and register number (reg_regnum) are not restored and
will remain at their previously modified values.
[ ... ]
> + case DW_CFA_advance_loc4: {
> + unsigned long offset;
> + u32 delta;
> +
> + UNSAFE_GET_USER_INC(delta, cur, end, Efault);
> + offset = delta * fde->cie.code_align;
[Severity: Medium]
Can this calculation overflow?
The multiplication of delta (a u32) and fde->cie.code_align (an unsigned int)
evaluates as a 32-bit unsigned integer before being assigned to the 64-bit
unsigned long offset.
If the product exceeds 32 bits, the high bits would be truncated, which might
cause the unwinder to desync from the actual PC.
> + ip += offset;
> + break;
> + }
[ ... ]
> + case DW_CFA_restore_extended: {
> + unsigned long reg;
> + int idx;
> +
> + if (ctx->cie)
> + return -EINVAL;
> +
> + ret = read_uleb128(&cur, end, ®);
> + if (ret)
> + return ret;
> +
> + idx = reg_to_index(reg);
> + if (idx >= 0)
> + ctx->state.reg_rule[idx] = ctx->cie_state.reg_rule[idx];
> + break;
> + }
[Severity: High]
This seems to have the same register state restoration issue as DW_CFA_restore.
Should reg_offset and reg_regnum also be restored here alongside the rule type?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260821195259.2688377-1-jremus@linux.ibm.com?part=9
next prev parent reply other threads:[~2026-08-21 20:16 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 19:52 [RFC PATCH v2 00/24] unwind_user: Implement .eh_frame handling Jens Remus
2026-08-21 19:52 ` [RFC PATCH v2 01/24] unwind_user: Add generic and arch-specific headers to MAINTAINERS Jens Remus
2026-08-21 19:52 ` [RFC PATCH v2 02/24] unwind_user: Stop when reaching an outermost frame Jens Remus
2026-08-21 20:00 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 03/24] unwind_user: Enable archs that pass RA in a register Jens Remus
2026-08-21 20:02 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 04/24] unwind_user: Flexible FP/RA recovery rules Jens Remus
2026-08-21 20:03 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 05/24] unwind_user: Flexible CFA " Jens Remus
2026-08-21 20:03 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 06/24] unwind_user: Enable archs that define CFA = SP_callsite + offset Jens Remus
2026-08-21 20:03 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 07/24] unwind_user/eh_frame: Add support for reading .eh_frame_hdr section Jens Remus
2026-08-21 20:06 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 08/24] unwind_user/eh_frame: Store .eh_frame_hdr section data in per-mm maple tree Jens Remus
2026-08-21 20:13 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 09/24] unwind_user/eh_frame: Add support for reading .eh_frame section Jens Remus
2026-08-21 20:16 ` sashiko-bot [this message]
2026-08-21 19:52 ` [RFC PATCH v2 10/24] unwind_user/eh_frame: Detect .eh_frame_hdr sections in executables Jens Remus
2026-08-21 20:10 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 11/24] unwind_user/eh_frame: Wire up unwind_user to eh_frame Jens Remus
2026-08-21 20:07 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 12/24] unwind_user/eh_frame: Remove .eh_frame[_hdr] section on detected corruption Jens Remus
2026-08-21 20:18 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 13/24] unwind_user/eh_frame: Show file name in debug output Jens Remus
2026-08-21 20:06 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 14/24] unwind_user/eh_frame: Add .eh_frame[_hdr] validation option Jens Remus
2026-08-21 20:10 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 15/24] unwind_user/eh_frame: Duplicate registered .eh_frame[_hdr] section data on clone/fork Jens Remus
2026-08-21 20:09 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 16/24] unwind_user/eh_frame: Ignore DW_CFA_GNU_args_size Jens Remus
2026-08-21 20:03 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 17/24] unwind_user/eh_frame: Add support for DWARF expressions Jens Remus
2026-08-21 20:18 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 18/24] x86/uaccess: Add unsafe_copy_from_user() implementation Jens Remus
2026-08-21 20:11 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 19/24] unwind_user/eh_frame/x86: Enable eh_frame unwinding on x86 Jens Remus
2026-08-21 20:16 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 20/24] unwind_user/eh_frame/x86: Handle PLT expressions Jens Remus
2026-08-21 20:17 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 21/24] unwind_user/eh_frame/x86: Handle DRAP expressions Jens Remus
2026-08-21 20:15 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 22/24] s390/ptrace: Provide frame_pointer() Jens Remus
2026-08-21 20:07 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 23/24] unwind_user/eh_frame/s390: Enable eh_frame unwinding on s390 Jens Remus
2026-08-21 20:15 ` sashiko-bot
2026-08-21 19:52 ` [RFC PATCH v2 24/24] unwind_user/eh_frame: Add prctl() interface for (un)registering .eh_frame_hdr sections Jens Remus
2026-08-21 20:22 ` sashiko-bot
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=20260821201618.6DBA21F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=jremus@linux.ibm.com \
--cc=linux-s390@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.