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


* 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?

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