Date: Sat, 27 Jun 2026 14:49:31 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 295991] lib/libc posix_spawnp(): PATH-search child runs on an undersized rfork_thread stack and underflows into the caller's heap (heavily-linked processes; PHP proc_open) Message-ID: <bug-295991-227-2AUY1ybJkL@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-295991-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295991 --- Comment #6 from Kyle Evans <kevans@freebsd.org> --- (In reply to Konstantin Belousov from comment #4) I'm still trying to pin down why we actually blow out the stack... I don't really see any way that # DSOs can be directly related. We do allocate one MAXPATHLEN(1k) buffer on the stack + a struct stat, but we don't push args or environment onto the stack- that's about the extent of our usage. I'm playing around with claude-code to see if it can reason about what they're talking about and find a way to reproduce it under ASAN or something. Its initial theory is that `strchrnul` is maybe obscure enough that it still needs to be resolved through the PLT, and that `_rtld_bind`'s stack usage scales with # DSOs loaded to an extent that our remaining 3k stack isn't sufficient. When I walk it along a little further, it points out that _rtld_bind -> find_symdef -> symlook_default will invoke donelist_init(): ``` #define donelist_init(dlp) \ ((dlp)->objs = alloca(obj_count * sizeof(dlp)->objs[0]), \ assert((dlp)->objs != NULL), (dlp)->num_alloc = obj_count, \ (dlp)->num_used = 0) ``` I think that might be enough to try and write a test for it, it's just going to be a little sketchy. I guess I could write one DSO and copy it into a bunch of shmfds and fdlopen() that. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-295991-227-2AUY1ybJkL>