24 Oct
2023
24 Oct
'23
8:35 a.m.
Hi Waldemar,
On 10/24/23 10:24, Pavel Kozlov wrote:
Hi Waldemar,
>> On 10/17/23 12:01, Pavel Kozlov wrote:
>>> From: Pavel Kozlov <pavel.kozlov(a)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?
I have some issues with my CI but it passed basic tests so let's go
I can also say that openrisc shell does not start either with current
uClibc-ng master branch, I guess it's because of the same issue.
Tested-by: Yann Sionneau <ysionneau(a)kalrayinc.com>
@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