linux-kernel - Re: [PATCH] objtool: Fix stack overflow in validate

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: <20251202220540.5849bdc6@pumpkin>
Date: Tue, 2 Dec 2025 22:05:40 +0000
From: David Laight <david.laight.linux@...il.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, x86@...nel.org,
 linux-kernel@...r.kernel.org, Nathan Chancellor <nathan@...nel.org>, Peter
 Zijlstra <peterz@...radead.org>, Alexandre Chartre
 <alexandre.chartre@...cle.com>
Subject: Re: [PATCH] objtool: Fix stack overflow in validate_branch()

On Tue, 2 Dec 2025 21:20:55 +0100
Ingo Molnar <mingo@...nel.org> wrote:

> * Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> 
> > On Tue, Dec 02, 2025 at 09:11:50AM -0800, Josh Poimboeuf wrote:  
> > > > > > That's weird - how can a user-space tool run into stack 
> > > > > > limits, are they set particularly conservatively?  
> > > > > 
> > > > > On my Fedora system, "ulimit -s" is 8MB.  You'd think that would be
> > > > > enough :-)
> > > > > 
> > > > > In this case, objtool had over 20,000 stack frames caused by recursively
> > > > > following over 7,000(!) conditional jumps in a single function.  
> > > > 
> > > > Ouch ...
> > > > 
> > > > ... which means that very likely we'll run into this problem again. :-/
> > > > 
> > > > Time to add stack overflow self-detection?
> > > > 
> > > > I've attached a simple proof-of-concept that uses 
> > > > sigaltstacks based SIGSEGV handler to catch a stack 
> > > > overflow:
> > > > 
> > > >   starship:/s/stack-overflow> ./overflow 
> > > >   # Starting stack recursion:
> > > > 
> > > >   # WARNING: SIGSEGV received: Possible stack overflow detected!
> > > > 
> > > >   starship:/s/stack-overflow> 
> > > > 
> > > > Could we add something like this to objtool, with 
> > > > perhaps a look at the interrupted stack pointer from 
> > > > SIGSEGV_handler(), to make sure the SIGSEGV was due to 
> > > > a stack overflow?  
> > > 
> > > Yes, I think that would be wise.  I've been thinking objtool could use a
> > > SIGSEGV handler anyway, as it crashes more often than one would hope,
> > > with a cryptic non-helpful error message for the user.
> > > 
> > > I'll work on it.  
> > 
> > Is something like the below sufficient?  Or do you think we should add
> > logic to distinguish the stack overflow from other crashes?
> > 
> > ---8<---
> > 
> > From: Josh Poimboeuf <jpoimboe@...nel.org>
> > Subject: [PATCH] objtool: Improve error message for SIGSEGV
> > 
> > When the kernel build fails due to an objtool seg fault, the error
> > message is confusing:
> > 
> >   make[5]: *** [scripts/Makefile.build:503: drivers/scsi/qla2xxx/qla2xxx.o] Error 139
> >   make[5]: *** Deleting file 'drivers/scsi/qla2xxx/qla2xxx.o'
> >   make[4]: *** [scripts/Makefile.build:556: drivers/scsi/qla2xxx] Error 2
> >   make[3]: *** [scripts/Makefile.build:556: drivers/scsi] Error 2
> >   make[2]: *** [scripts/Makefile.build:556: drivers] Error 2
> >   make[1]: *** [/home/jpoimboe/git/linux/Makefile:2013: .] Error 2
> >   make: *** [Makefile:248: __sub-make] Error 2
> > 
> > Add a signal handler which prints an error message like:
> > 
> >   drivers/scsi/qla2xxx/qla2xxx.o: error: objtool: SIGSEGV (Segmentation Fault) received at address 0x7ffc5f33bf30
> > 
> > ... and re-raises the signal so the core dump still gets triggered.  
> 
> Could we somehow determine that 0x7ffc5f33bf30 is off 
> the end of the stack or so and that this is a stack 
> overflow?

You could compare it to the address of something on-stack during program startup.
Probably even argv[] - isn't that always at the bottom of the stack?
If you read the rlimit value, maybe the recursive loop could abort
before the fault.

	David

> 
> Maybe objtool could have a look into /proc/self/maps:
> 
>    7fc21a543000-7fc21a544000 rw-p 0003f000 103:02 96610309                  /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
>    7fc21a544000-7fc21a545000 rw-p 00000000 00:00 0 
>    7ffd6a5a0000-7ffd6a5c1000 rw-p 00000000 00:00 0                          [stack]
> 
> ?
> 
> Thanks,
> 
> 	Ingo
>