Hi Waldemar,
On 10/17/23 12:01, Pavel Kozlov wrote:
From: Pavel Kozlov pavel.kozlov@synopsys.com
Commit 95e38b37 ("add support for systems without legacy setrlimit/getrlimit syscalls") has added use of the prlimit64 syscall in getrlimit and setrlimit functions. This change causes memory corruption on getrlimit call for 32-bit CPUs like ARC, as ARC doesn't have ugetrlimit syscall and uses prlimit64. Also, setrlimit has been broken by prlimit64 call on 32-bit CPUs like, i386, ARM, ARC.
Oopsy! Sorry about that, indeed I guess I broke 32 bit CPUs.
I've started a CI job to test your patch to see if it breaks our arch, I'll keep the list informed on whether this works or not.
Thanks a lot!
Any news from your side? @pavel: Do you have a test application showing the memory corruption for 32 Bit CPU's which could be added to the uclibc-ng-testsuite?
No, I don't have a test to reproduce memory corruption. In my configuration for ARC CPU this issue prevented the shell start. The sell crashed while polling input (in poll() function). Actually, it was a fault in return from getdtablesize() function (called inside poll function). This function calls getlimit(), but prlimit64 syscall corrupted the stack and overwrote the return address. As a result I got: --- zebu_hs login: root # potentially unexpected fatal signal 11. Path: /bin/busybox CPU: 0 PID: 75 Comm: sh Not tainted 5.16.0 #11 Insn could not be fetched @No matching VMA found ECR: 0x00040000 EFA: 0x00001000 ERET: 0x00001000 STAT: 0x80081a82 [IE U ] BTA: 0x20021360 SP: 0x5fe0baf4 FP: 0x5fe0bb18 BLK: 0x1000 LPS: 0x20037500 LPE: 0x20037508 LPC: 0x00000000 r00: 0x00000400 r01: 0x00000007 r02: 0x00000000 r03: 0x5fe0bae8 r04: 0x01010101 r05: 0x00000020 r06: 0x20077380 r07: 0x01010101 r08: 0x00000105 r09: 0x00000a3b r10: 0x7f1c0300 r11: 0x01000415 r12: 0x2001f1fc r13: 0xffffffff r14: 0xffffffff r15: 0x5fe0bb68 r16: 0x00000001 r17: 0x00000001 r18: 0x5fe0bbc9 r19: 0xffffffff r20: 0x5fe0bb68 r21: 0x5fe0bc24 r22: 0x5fe0bbc8 r23: 0x200722c0 r24: 0x00000400 r25: 0x2000ab68 --- Any test that calls poll() function of can be used to verify this issue on ARC CPU. On other CPUs the consequences of stack corruption may vary.
I just have a small test to ensure that getrlimit/setrlimit/prlimit are working as expected and can read/write limits with a patch, but in functionality it is something like ulimit.
-Pavel