grsecurity forums

Hi,

could you please take a look at the call trace in this gentoo bug:
http://bugs.gentoo.org/show_bug.cgi?id=242378
And tell me if it might be related to the grsec or pax patches used by gentoo's hardened-sources. If it's not, I'll have to submit it to the kernel.org bugzilla..

Thanks,

bbee

bbee wrote:could you please take a look at the call trace in this gentoo bug:
http://bugs.gentoo.org/show_bug.cgi?id=242378
And tell me if it might be related to the grsec or pax patches used by gentoo's hardened-sources. If it's not, I'll have to submit it to the kernel.org bugzilla..

if you can reproduce it easily, you could try a vanilla kernel too, that'd decide it definitely. from the logs, it's not obvious to me yet what's going on. i'll note however that the failing instruction is

Code: Select all

mov    %rax,0x8(%rdx)

with rdx=fff7e20002185e30, which happens to be an invalid address but is suspiciously close to ffffe20002185e30 (a valid address). since it's a single bit difference, it makes me think that it's either a very rare memory corruption bug (affecting a single bit only) or a bad RAM (memtest is your friend .

PS: i'm subscribed to the gentoo bugzilla, i'll see these issues sooner if you add me to the CC list.

Thanks for your reply. I've not been able to reproduce this after a few days' trying with similar workloads.
Since I suspected the memory, I did run a few memtest+ passes; they came up clean but I'll try to run it for an extented period when downtime is more convenient.

I guess for the moment I'll blame it on cosmic rays, and start saving for ECC RAM and hardware with EDAC support..