On 05/15/2014 09:48 AM, PaX Team wrote:
>
> unfortunately the backtrace is not usable as is due to lack of symbols.
> if you still have the original vmlinux around (or can reproduce it with
> all the debug symbols) then i can take a look and perhaps figure out
> where the refcount overflow was det
On 13 May 2014 at 15:39, Joshua Kinard wrote:
> For me, I never had an actual oops. Just a note in dmesg that pax was
> killing command-line processes at random. Running services didn't seem to
> be affected, but I could go run grep or something and it'd just abruptly
> terminate.
when PaX kill
On 9 May 2014 at 11:15, Michael Orlitzky wrote:
> > [Fri May 9 11:00:42 2014] PAX: refcount overflow detected in:
> > syslog-ng:21823, uid/euid: 0/0
this is the key message, the REFCOUNT feature triggered as it detected
an overflow somewhere.
> > [Fri May 9 11:00:42 2014] CPU: 2 PID: 21823 Co
On 05/13/14 15:39, Joshua Kinard wrote:
On 05/10/2014 09:43, Anthony G. Basile wrote:
On 05/10/14 07:39, Michael Orlitzky wrote:
On 05/10/2014 07:14 AM, Joshua Kinard wrote:
I think I ran into this, too, in 3.11. It takes a few days of uptime before
it happens. Running 3.13.x now on my x64 m
On 05/10/2014 09:43, Anthony G. Basile wrote:
> On 05/10/14 07:39, Michael Orlitzky wrote:
>> On 05/10/2014 07:14 AM, Joshua Kinard wrote:
>>>
>>> I think I ran into this, too, in 3.11. It takes a few days of uptime before
>>> it happens. Running 3.13.x now on my x64 machine and haven't ran into i
While a refcount overflow would be fair indicator. When this goes of
after approximately some months AND on different machines could hint of
false positives pilling up.
On 05/10/14 07:39, Michael Orlitzky wrote:
On 05/10/2014 07:14 AM, Joshua Kinard wrote:
I think I ran into this, too, in 3.11. It takes a few days of uptime before
it happens. Running 3.13.x now on my x64 machine and haven't ran into it
again. So I second the suggestion to upgrade your kernel
On 05/10/2014 07:14 AM, Joshua Kinard wrote:
>
> I think I ran into this, too, in 3.11. It takes a few days of uptime before
> it happens. Running 3.13.x now on my x64 machine and haven't ran into it
> again. So I second the suggestion to upgrade your kernel.
>
I couldn't come up with a better
On 05/09/2014 13:46, "Tóth Attila" wrote:
> 2014.Május 9.(P) 17:39 időpontban Michael Orlitzky ezt írta:
>> On 05/09/2014 11:29 AM, Mark Gomersbach wrote:
>>> Maybe a bug somewhere else too, which combination kernel/grsec/pax was
>>> used?
>>>
>>
>> Whatever came with sys-kernel/hardened-sources-3.
I encourage you to upgrade your kernel to the latest available in the
tree. Even if its keyworded currently. Such things pop up sometimes, come
and go. Grsec/PaX developers (spender/pipacs/ephox) fixes most of these
pretty quickly. I would also check out grsecurity support forums.
--
dr Tóth Attil
On 05/09/2014 11:29 AM, Mark Gomersbach wrote:
> Maybe a bug somewhere else too, which combination kernel/grsec/pax was used?
>
Whatever came with sys-kernel/hardened-sources-3.11.7-r1:
# uname -a
Linux mmmc2 3.11.7-hardened-r1 #1 SMP Fri Jan 3 23:13:48 EST 2014
x86_64 Intel(R) Xeon(R) CPU
Maybe a bug somewhere else too, which combination kernel/grsec/pax was used?
On 05/09/2014 05:15 PM, Michael Orlitzky wrote:
> Last week, the LMTP daemon on our mail server (HP DL360 G6) crashed.
> People noticed that the mail stopped coming in, so I SSHed in to check
> on it, and there were some
12 matches
Mail list logo
