grsecurity forums

Hi!

I'm sitting on a Debian 2.6.32.13-kvm-grsec with 206 days uptime. So far nothing fancy happened. But today the kern.log showed the following:

Code: Select all

kernel: et_from8107a4af>ffff8107affff8105874ffff81058c9f>] ? do_group_exit+0x75/0x9c
kernel: [17815398.893570]  [<ffffffff81063222>] ? get_signal_to_deliver+0x30d/0x333
kernel: [17815398.893572]  [<ffff81022f8d>] ffff816923ffff8102459om 195.228.xxx.xxx: refcount overflow detected in: apache2:10774, uid/euid: 33/33
PAX: refcount overflow occured at: bad_to_user+0x1229/0xa586

What the heck is this? If you need more details, I can include the whole 7500 line long trace.

molly wrote:

Code: Select all

kernel: et_from8107a4af>ffff8107affff8105874ffff81058c9f>] ? do_group_exit+0x75/0x9c
kernel: [17815398.893570]  [<ffffffff81063222>] ? get_signal_to_deliver+0x30d/0x333
kernel: [17815398.893572]  [<ffff81022f8d>] ffff816923ffff8102459om 195.228.xxx.xxx: refcount overflow detected in: apache2:10774, uid/euid: 33/33
PAX: refcount overflow occured at: bad_to_user+0x1229/0xa586

What the heck is this? If you need more details, I can include the whole 7500 line long trace.

that's a (probably false positive) refcount overflow being detected and duly reported . since this is a rather old kernel and we've fixed some false positives since, you should update to the latest .32 kernel and send me the corresponding vmlinux (not vmlinuz or bzImage) so that i can double check what exactly triggered here.

As it turned out the underlying reiserfs had some headaches. After a reboot/fsck, everything was a-ok.

PS: Grats for the lifetime achievement award! Csak így tovább .

It'll seem a-ok for now, but the nature of these false positives is that the crash will occur in the same 200+ days as it took this time (as the counter takes that long to reach the "overflow" point). As the PaX Team mentioned, numerous false positives were fixed (some in reiserfs even iirc) so a kernel update is recommended even if the machine seems ok now.

-Brad