Closed msmeissn closed 6 months ago
Yes, apparently this is all that is required to trigger a crash as root (e.g. in a container):
char* val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
int fd = 0;
fd = fsopen("9p", 0);
...
for (int i = 0; i < 5000; i++) {
fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0);
}
Yes, apparently this is all that is required to trigger a crash as root (e.g. in a container):
char* val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"; int fd = 0; fd = fsopen("9p", 0); ... for (int i = 0; i < 5000; i++) { fsconfig(fd, FSCONFIG_SET_STRING, "\x00", val, 0); }
That means we create new test case such as fsconfig03.c for running above code under testcases/kernel/syscalls/fsconfig ? Running on latest kernel i think it's ok, but if somebody start running this code in old kernel then he will encounter system crash and the whole test will stopped, correct me if any misunderstanding. Also what's meaning "e.g. in a container", you mean we build container and start run above code?
Implemented in 96e4941ee260b7e41118e5c06c988da1de66a8db, thanks!
there are reproducers available for CVE-2022-0185
https://www.openwall.com/lists/oss-security/2022/01/25/14 has links or even a zip file for an exploit
https://github.com/Crusaders-of-Rust/CVE-2022-0185
the exploits are kind of complicated as they try to be complete, but the exploitation vector is the fsconfig() syscall which probably can be tested standalone...
might add some coverage to that to detect it