resource limit

[devillinux]

Hey,

I'm getting the following message on my Lotus Domino Server (and the process fails):

Code: Select all

Feb 28 10:44:35 src@xxxxx kernel: grsec: attempted resource overstep by requesting 4294967295 for RLIMIT_LOCKS against limit 4294967295 by (http:2539) UID(1000) EUID(1000), parent (http:4353) UID(1000) EUID(1000)

The 2 numbers are identical so grsec shouldn't complain, or?

Regards
Heiko

[spender]

Here's the relevant code from the kernel. As you can see, grsecurity is reporting correctly. It seems though that current->locks is -1, (as an unsigned long it would be the number you reported)...so it's a bug in the application, as no app could hold that many locks.

if (account && current->locks >= current->rlim[RLIMIT_LOCKS].rlim_cur)
return NULL;

-Brad

[PaX Team]

Here's the relevant code from the kernel. As you can see, grsecurity is reporting correctly. It seems though that current->locks is -1, (as an unsigned long it would be the number you reported)...so it's a bug in the application, as no app could hold that many locks.

if (account && current->locks >= current->rlim[RLIMIT_LOCKS].rlim_cur)
return NULL;

then the kernel is likely wrong. here's the even more relevant code from include/asm-i386/resource.h:

Code: Select all

#define RLIM_INFINITY   (~0UL)

that is, before evaluating rlim_cur for >=, it should be checked against RLIM_INFINITY.

[spender]

True, but there still must be something wrong with the kernel or the app itself, since it is decrementing its lock count without it being incremented.

-Brad

[devillinux]

True, but there still must be something wrong with the kernel or the app itself, since it is decrementing its lock count without it being incremented.

What?

[spender]

Well, from the code that I pasted, the value of current->locks must have been -1(unsigned). This leads me to believe there's a bug in the kernel (since it should be at least 0)

-Brad

[devillinux]

Well, from the code that I pasted, the value of current->locks must have been -1(unsigned). This leads me to believe there's a bug in the kernel (since it should be at least 0)

Infinity is greater then 0, correct?
So I think PaX Team is right and you should check on it.

Heiko

[spender]

RLIM_INFINITY is the equivalent of -1 converted to an unsigned integer. I've updated grsecurity so that it doesn't bother logging if the limit is RLIM_INFINITY, but it should be noted that in this case, the kernel doesn't honor RLIM_INFINITY, so in your case the operation failed. So really, the original way I was implementing the logging was correct for this case. But the point that I was trying to make is that you should have never gotten that log unless there was a bug in the kernel that was decrementing the lock count without ever incrementing it. If you don't understand all this yet, there's no point in going over it again, as I've done repeatedly in the thread.

-Brad

[devillinux]

ok I'll shut up