Bug 215706
Summary: | SYS_vfork syscall may cause Segmentation fault | ||
---|---|---|---|
Product: | Linux | Reporter: | Odysseus_sz (620791627) |
Component: | Kernel | Assignee: | Virtual assignee user for helpdesk (kernelorg-helpdesk) |
Status: | NEW --- | ||
Severity: | normal | CC: | pagict |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | Subsystem: | ||
Regression: | No | Bisected commit-id: |
Description
Odysseus_sz
2022-03-21 03:55:37 UTC
fix the test program: #define _GNU_SOURCE #include <stdio.h> #include <unistd.h> #include <sys/syscall.h> #include <sys/types.h> #include <sys/wait.h> #include <stdlib.h> int main() { pid_t child; int status; child = syscall(SYS_vfork); if (child) { printf("parrent: %ld\n\n", child); child > 0 ? wait(&status) : exit(-1); _exit(0); } printf("child\n"); exit(0); } I think this segfault is totally legitimate. As the man page described, child process created by vfork shares the same linear address space with the parent. What child process do to modify the memory(including stack) would reflect the parent. | The vfork() function has the same effect as fork(2), except that the behavior is undefined if the process created by vfork() either modifies any data other than a variable of type pid_t used to store the return value from vfork(), or returns from the function in which vfork() was called, or calls any other function before successfully call‐ing _exit(2) or one of the exec(3) family of functions. (In reply to minzhi from comment #2) > I think this segfault is totally legitimate. > > As the man page described, child process created by vfork shares the same > linear address space with the parent. What child process do to modify the > memory(including stack) would reflect the parent. > > | The vfork() function has the same effect as fork(2), except that the > | behavior is undefined if the process created by vfork() either modifies any > | data other than a variable of type pid_t used to store the return value > from > | vfork(), or returns from the function in which vfork() was called, or calls > | any other function before successfully call‐ing _exit(2) or one of the > | exec(3) family of functions. The problem here is mix the glibc wrapper with raw system calls. If you replace `syscall(SYS_vfork)` with glibc wrapper `vfork`, or replace `exit(0)` with `syscall(SYS_exit, 0)`, there will be no such segmentation fault. Since the glibc wrapper do more than just `syscall()`, it definitely modified the data. |