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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ