linux-kernel - Re: [PATCH v12 02/14] unwind_user: Add frame pointer support

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250630230528.5e368f19@gandalf.local.home>
Date: Mon, 30 Jun 2025 23:05:28 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 bpf@...r.kernel.org, x86@...nel.org, Masami Hiramatsu
 <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Josh Poimboeuf <jpoimboe@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Jiri Olsa
 <jolsa@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Thomas Gleixner
 <tglx@...utronix.de>, Andrii Nakryiko <andrii@...nel.org>, Indu Bhagat
 <indu.bhagat@...cle.com>, "Jose E. Marchesi" <jemarch@....org>, Beau
 Belgrave <beaub@...ux.microsoft.com>, Jens Remus <jremus@...ux.ibm.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>,
 Florian Weimer <fweimer@...hat.com>, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH v12 02/14] unwind_user: Add frame pointer support

On Mon, 30 Jun 2025 22:56:03 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Mon, 30 Jun 2025 19:10:09 -0700
> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Mon, 30 Jun 2025 at 17:54, Steven Rostedt <rostedt@...dmis.org> wrote:  
> > >
> > > +       /* stack going in wrong direction? */
> > > +       if (cfa <= state->sp)
> > > +               goto done;    
> > 
> > I suspect this should do a lot more testing.  
> 
> Sure.

Adding Kees too.

Kees,

I'd like to get some security eyes on this code to take a look at it. As it
is making decisions on input from user space, I'd like to have more
security folks looking at this to make sure that some malicious task can't
set up its stack in such a way that it can exploit something here.

The parsing of the sframe code (latest version net yet posted) will need a
similar audit.

Thanks,

-- Steve

> 
> >   
> > > +       /* Find the Return Address (RA) */
> > > +       if (get_user(ra, (unsigned long *)(cfa + frame->ra_off)))
> > > +               goto done;
> > > +
> > > +       if (frame->fp_off && get_user(fp, (unsigned long __user *)(cfa + frame->fp_off)))
> > > +               goto done;    
> > 
> > .. and this should check the frame for validity too.  At a minimum it
> > should be properly aligned, but things like "it had better be above
> > the current frame" to avoid having some loop would seem to be a good
> > idea.  
> 
> Makes sense.
> 
> > 
> > Maybe even check that it's the same vma?  
> 
> Hmm, I call on to Jens Remus and ask if s390 can do anything whacky here?
> Where something that isn't allowed on other architectures may be allowed
> there? I know s390 has some strange type of stack usage.
> 
> -- Steve