From: Jens Remus <jremus@linux.ibm.com>
To: Steven Rostedt <rostedt@kernel.org>,
Josh Poimboeuf <jpoimboe@kernel.org>
Cc: Indu Bhagat <ibhagatgnu@gmail.com>,
bpf@vger.kernel.org, sashiko@lists.linux.dev
Subject: Re: [PATCH v14 05/19] unwind_user/sframe: Add support for reading .sframe contents
Date: Fri, 8 May 2026 11:49:59 +0200 [thread overview]
Message-ID: <3158dc1a-26cb-4942-b05e-6c60c092e588@linux.ibm.com> (raw)
In-Reply-To: <20260506110142.7b2943d7@fedora>
On 5/6/2026 5:01 PM, Steven Rostedt wrote:
> On Wed, 6 May 2026 16:34:34 +0200
> Jens Remus <jremus@linux.ibm.com> wrote:
>>> If a malicious user provides a large fre_len in the header, fres_end
>>> (calculated as fres_start + shdr.fre_len) could wrap around the 32-bit
>>> address space. This would bypass the bounds check in sframe_read_header(),
>>> allowing fres_start and fdes_start to point into kernel memory. Later, when
>>> __read_fde() and __find_fre() use unsafe_get_user(), this could lead to
>>> arbitrary kernel memory disclosure.
>>
>> SFrame is currently only supported on 64-bit architectures (i.e. x86-64,
>> arm64, s390 64-bit). So unsigned long fres_end should always be 64-bit.
>> Do we need to add the following to the header parsing?
>>
>> if (fdes_start >= fdes_end || fres_start >= fres_end) {
>> dbg_sec("inconsistent FDE/FRE start/end address\n");
>> return -EINVAL;
>> }
>
> I guess this wouldn't hurt.
Reviewing my suggestion again I realize that this check would be
superfluous. The existing computation and check already ensures that
the FDE table is within sframe section, the FRE table is within sframe
section, and both tables do not overlap:
num_fdes = shdr.num_fdes;
fdes_start = header_end + shdr.fdes_off;
fdes_end = fdes_start + (num_fdes * sizeof(struct sframe_fde_v3));
fres_start = header_end + shdr.fres_off;
fres_end = fres_start + shdr.fre_len;
if (fres_start < fdes_end || fres_end > sec->sframe_end) {
dbg_sec("inconsistent FDE/FRE offsets\n");
return -EINVAL;
}
- fdes_start and fres_start are computed from header_start and thus must
be larger sframe_start
- fdes_end and fres_end are computed from their fdes_start and
fres_start and thus must be larger than sframe_start
- fres_start < fdes_end ensures that the FDE table and FRE table do not
overlap
- fres_end > sec->sframe_end ensures that fres_end (and fdes_end and both
fdes_start and fres_start) are smaller or equal sframe_end
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
next prev parent reply other threads:[~2026-05-08 9:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260505121718.3572346-6-jremus@linux.ibm.com>
[not found] ` <20260505185932.C708CC2BCB4@smtp.kernel.org>
2026-05-06 14:34 ` [PATCH v14 05/19] unwind_user/sframe: Add support for reading .sframe contents Jens Remus
2026-05-06 15:01 ` Steven Rostedt
2026-05-06 15:29 ` Jens Remus
2026-05-08 9:49 ` Jens Remus [this message]
2026-05-08 23:04 ` Indu Bhagat
2026-05-12 13:35 ` Jens Remus
2026-05-13 12:22 ` Steven Rostedt
2026-05-08 23:03 ` Indu Bhagat
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=3158dc1a-26cb-4942-b05e-6c60c092e588@linux.ibm.com \
--to=jremus@linux.ibm.com \
--cc=bpf@vger.kernel.org \
--cc=ibhagatgnu@gmail.com \
--cc=jpoimboe@kernel.org \
--cc=rostedt@kernel.org \
--cc=sashiko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox