Change Details

This stack allocation turns into a potentially exploitable heap overflow in the context of posix_spawnp(3) based solely on the PATH environment variable. On x86 only, posix_spawnp(3) will allocates a small 4k stack to work with since rfork(2) w/ RFMEM cannot function correctly there. The logic isn't too hairy if we instead rewrite the PATH handling to operate on the immutable string passed in, so do this instead of the arbitrary stack allocation. This has not made it into any final release, but this does appear as written in releng/11.4; tagging in: - kib and jilles as knowledgeable reviewers - Andrew Gierth, who reported this to me today, 2020/05/28 - #secteam to handle it for to the in-progress release cycle - #releng to keep them apprised I've limited visibility so that someone who isn't me can decide if it's worth being limited or not. =-)

This stack allocation turns into a potentially exploitable heap overflow in the context of posix_spawnp(3) based solely on the PATH environment variable. On x86 only, posix_spawnp(3) will allocate a small 4k stack to work with since rfork(2) w/ RFMEM cannot function correctly there. The logic isn't too hairy if we instead rewrite the PATH handling to operate on the immutable string passed in, so do this instead of the arbitrary stack allocation. Additional size is also needed for the stack in posix_spawnp(), because it may need to push all of argv to the stack and rebuild the command with `sh` in front of it. This has not made it into any final release, but this does appear as written in releng/11.4; tagging in: - kib and jilles as knowledgeable reviewers - Andrew Gierth, who reported this to me today, 2020/05/28 - #secteam to handle it for to the in-progress release cycle - #releng to keep them apprised I've limited visibility so that someone who isn't me can decide if it's worth being limited or not. =-)

This stack allocation turns into a potentially exploitable heap overflow in the context of posix_spawnp(3) based solely on the PATH environment variable. On x86 only, posix_spawnp(3) will allocates a small 4k stack to work with since rfork(2) w/ RFMEM cannot function correctly there. The logic isn't too hairy if we instead rewrite the PATH handling to operate on the immutable string passed in, so do this instead of the arbitrary stack allocation. Additional size is also needed for the stack in posix_spawnp(), because it may need to push all of argv to the stack and rebuild the command with `sh` in front of it. This has not made it into any final release, but this does appear as written in releng/11.4; tagging in: - kib and jilles as knowledgeable reviewers - Andrew Gierth, who reported this to me today, 2020/05/28 - #secteam to handle it for to the in-progress release cycle - #releng to keep them apprised I've limited visibility so that someone who isn't me can decide if it's worth being limited or not. =-)