Hi Waldemar,
>>
>> On 10/17/23 12:01, Pavel Kozlov wrote:
>> > From: Pavel Kozlov <pavel.koz...@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
_______________________________________________
devel mailing list -- devel@uclibc-ng.org
To unsubscribe send an email to devel-le...@uclibc-ng.org
