From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94328204F93 for ; Tue, 2 Dec 2025 22:05:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764713145; cv=none; b=CNUhX/9rshkezGxEGldpHFLgbzwZtVXU4dFP3IGqZazqR3y/cuUx2d7+uYyFJoXAWpCNPP0K6I9N9Gb1bmuwZJHVD3CpbKiXSpXGWfPPmnts0wn+9TblVVC80UOdu3xuk3MdMxr63d1jkXC+8ixVMhyIJZcLOSBeIvtiaZM22p4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764713145; c=relaxed/simple; bh=MR1qTzyhG5FaV4mi3lqcVymP1tMRlnhXgyvKp590/aQ=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Id8SyYry4cOF9+mHTQVezdioDdivYhrvxPVFcU7WuENjdpdswjfUH/k8IRQEeGEnw3OQfB5sPHQTLvs2FXsCjNiokY7oEXSWnzl4LaxfFtYVZCtTWedxHt+bEHCdex5PFSHPJ1qtj3BAAiDxo97XdhfjulgfhrE9WkoD8VwCHbQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=EmF1HL7Q; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="EmF1HL7Q" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-477b198f4bcso44994685e9.3 for ; Tue, 02 Dec 2025 14:05:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764713142; x=1765317942; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=fL7Nt+kjxRKn7RKpNUCMQBHxrtm8pUPEhq/4CqAAaUw=; b=EmF1HL7Q4L+ro23yiqYuGrIPZBUwDlbnFlN9oQr1nhQWdQkN3D+9Qw7goGhMdSVeTS KCY0BXzKLNhGKFLzV5I2T9HJZklaHj0cTX/klORJSBNw10xlXD/aZVFVMfYKNp812fkk 7IK0PK3m4T3hwa5NHxMGQ4rnl/uzFTvT3iVAAixbBWFUmmaOyqZZPPHVXLzr2PbVaxGN 7AF2+14g1WskiI4vLKZIQxN38xaC1dLF+FvQoPFEp28/0YrC4Mxcc+/VjxazE5aQBf8d 79zIEXBbcjvfasgHKIWhnZ2oqc2B5UPG79++I7xGLrPB44MClyfyCuPEy9u957hsu0KH ebQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764713142; x=1765317942; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=fL7Nt+kjxRKn7RKpNUCMQBHxrtm8pUPEhq/4CqAAaUw=; b=wsnmCIyx/7SKAxUPphTHSa27F4Pc0nMr+wBBFG+qlNyCVofn60gheVcZWodS+b8/VF B1PonYvo9gXAXvE1RmfKj8om20ak0RlmlpMfog9ddopge63NniX+Esswoh60n64vtBIn 4tcCO1PZAOCx6w88Il6nDSDVWbovGUhdweXDPcL6HOLvyyB+ght2ZMQo/fUecOGrFC4n z5lRbRWhykZAem1/LW77t2p1EkAz5gF9u9OU0ZG1jwKFlyxBoS81XtjJKsBOvBu0h0x0 SJeh/t7TaFdJL0INVbuYVJRrb2S2BSPoCNAZhrseG9CyC4ww05inAA6JnsJFkSBXG5q2 yRcg== X-Forwarded-Encrypted: i=1; AJvYcCV8seGNSJfXIFfG4xUpDOF8sTLvv8slFJeVs6olycAHy5qL68zHHFw6jionLCFaQC8cYB1gXeaTNcEAhfw=@vger.kernel.org X-Gm-Message-State: AOJu0Yx/t2Vhq8gOD0lkZNYGHcAQ4WXsS8xQiUbG1x7HLpO75tqWbXXF +nzHumW6lUo14+UpAmf9dYTUynorCMUl3SnBsonij6BueZQOmemyvf0b X-Gm-Gg: ASbGnct0V+oyizpZY/CieBgTfJD7inAdldRQIbing33BsrTfOu4CYfSgQQRqveuKaDD BeI8HXn9F8OHNe1rF2ELCQLDYRQVJYgxxHEwjrOvvN3qF5pI7muDuhbENAy2aMLo12Sjh99ccKr KYw+65gF97IZsSXDNSfsjcRTSd9NS70QNLug6m+72dX6/3ZISuEymwujUJ6XFLEv6iBNPjv/KPb fdFYlG2Q7wTDmGaAar0OS35uyLJodvPliqnXC04SJ828/j1qTz2+mmI7g8abwe7VeZKPQKz38+m TfBXIBNhsdncthORQK/e514SdiBoOZRK1QVSlURX6DGvlBzZkgJ8ATMw+fhgXfx3kvdHL9Awu9I 1reORfHKr3+sdPG4pEP7oievj8rpdyLzT/IKnlO9L1OCFFUg85hQjoNanszuLvKdoYiZWQHe2Yj UcukOivqEWyWmagafFhhNjeFdo6iclHSAZfjOf6ZQCzh5vU9C0xbI7 X-Google-Smtp-Source: AGHT+IGGmlWpjfI/m4VP83dZMEfuUAWJtWmpzdXuojuNMJPIBzE8Y+5Ll+ZMdMNBwELpyODnV/28pw== X-Received: by 2002:a05:600c:46c6:b0:477:a21c:2066 with SMTP id 5b1f17b1804b1-4792aedec5dmr1487125e9.5.1764713141721; Tue, 02 Dec 2025 14:05:41 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4792a79760esm11407575e9.3.2025.12.02.14.05.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Dec 2025 14:05:41 -0800 (PST) Date: Tue, 2 Dec 2025 22:05:40 +0000 From: David Laight To: Ingo Molnar Cc: Josh Poimboeuf , x86@kernel.org, linux-kernel@vger.kernel.org, Nathan Chancellor , Peter Zijlstra , Alexandre Chartre Subject: Re: [PATCH] objtool: Fix stack overflow in validate_branch() Message-ID: <20251202220540.5849bdc6@pumpkin> In-Reply-To: References: <21bb161c23ca0d8c942a960505c0d327ca2dc7dc.1764691895.git.jpoimboe@kernel.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 2 Dec 2025 21:20:55 +0100 Ingo Molnar wrote: > * Josh Poimboeuf 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 > > 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 >