[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)

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.