PAX: RAP hash violation for return address: __ext4_get_inode_loc+0x258/0xab0 #17
Comments
|
This call trace looks strange, indeed. Looks like a stack buffer overflow in Can you reproduce this on vanilla? It should Oops instead, though, as it has no RAP to detect the smashed return address. |
|
As I used to tell PaX Team or spender when then asked for more info, I have to tell you too: I need time to understand what you're asking, and try and follow through. |
Of course I'll gladly try and provide more info. All the logs are safely backed from the machine in which this happened. |
|
First: And more coming, the Call Trace coming... If I make it... |
|
Will be very verbose... Lots of things to consider... The trace comes in some almost 40 minutes after just here below... No, not all is important, and I did remove a lot of fluff, but this is documented what happened, what programs were on, when the martian source appeared and when my iptables decided something wasn't right... and so on... At this place/time the martian source's appear: And here my iptables decided some packets were not right: Here goes the Call Trace: I'd better post this before I'm crashed again... |
|
And now that it's posted, I can try and make it a little more readable for skim readers... (of course you need to visit github for that, sorry). |
|
This is multitasking, for my level of knowledge and aptness, so forgive me that I only now tell you... |
|
The |
|
It feels for the careful and persevering observer of my system, i.e. me, that the sources of these bugs are in the internet (and allowed, or even catered for or even possibly actually meeted out by the bad provider of mine; just how else would a freshly mint version of virus find its way into my mailbox through spam on the very day it was created? --I had such events, they're provable! past all antivirus software which they do have?...-- but I'm not going to digress on that now (or other indications of an actually... sick... employees/higher-ups in charge of this particular situation... at that provider)... So in this report, which involves another function from the same script: as in the report that I spent some five hours last night and which is just above here, I'm only posting the latest entry before the crash and the ban by grsecunoff: That's just me looking up the log extracts that I took. I usually do so to fix my /etc/grsec/policy, which I learned how to do, posted very much about it, and which is still read a lot in the RBAC section of https://forums.grsecurity.net, because this is my best loved program, the most honest in the GNU/Linuxdom, and I like to spread it and teach newbies to use it... The grsec_180102_022229_rwx is a copy of /etc/grsec/policy. I work on a copy and then apply the good work back to /etc/grsec/policy. Not hiding anything, but I'm not sure why these ' denied ' lines. Haven't been seeing similar before.. There's more below, just I like to show that grsecunoff remained in control. All the regular cron jobs are being done. Just the user mr (uid 1000), which is the only flesh and bones user of my computor, i.e. me, is not allowed to mess anymore... Stern and unforgiving grsec!... I had actually gone to sleep and only after I figured out the screen is not going blank did I understand that there was another crash... A series of ugly NULL bytes was here, because I rebooted the machine by mechanical switch. And this is regular booting. But, actually, first I have to say the machine wouldn't boot, the BIOS screen wouldn't appear... And again I had an instance of what I described in at least two different places in the past weeks, let me find them... That's what happened. But only once. And I hit the swicth and booted fine. And this is that booting: Obviously, I'd need to look up and analyze and then possibly post the network dumps of my... But it's way too much work. Suffice it that I identify those traces: These are the minimally anonymized PCAPs as per the explanation in the: |
|
I've studied my archived Call Traces and Oops, and I think I can try and post a series of a small number of those here. Old ones, all from Feb 26 to Feb 27, with grsecunoff and with vanilla kernel. To me, the series of Call Traces and Oops that I'm about to post show that it is either an upstream bug or bugs, some of the already presented Call Traces here, or an attack of some kind (although the latter fades as possibility in view of lack of bugs showing in: Pls. more knowledgeable/more experienced visitors, look into this and make your valuable points on it. It's a lot of log lines crisscrossed with Call Traces and Oopses, and I've cut those in many places to trim down to necessary information. For better readability, I'll post those consecutive events cut very much down from the verbose log, in several consecutive posts from here onwards. |
|
Here is what this sole-bug-presenting-system-of-mine --in no other have I seen any bugs for months now-- as I explained anew in (already linked issue, but the comment linked now): And those NULL bytes mean that there was a lockup. |
|
So this is the reboot. Incompletely logged, as I explained in: And we actually reached at the time which is 3 minutes and 4 seconds from the BUG, here. |
|
So, the BUG, as the log says: |
That's just system functioning without the banned user (which was me as normal user). |
|
After the mechanical switch put to action, I now boot into vanilla kernel. I know this is a lot of log, but believe you me, it is complete. Surprise wating at end. |
|
No log at all after the above... And then this: And a total freeze/lockup/you-name-it. |
|
Rebooted. Complete again. And now... |
|
And now we have a few bugs forcefully making their way into the log, probably desperate to show off their malice... And do they at least somewhat exonerate grsecunoff? More knowledgeable should tell... |
|
And there's no bugs anymore, just me booting back into grsecunoff, what else. Stay with the kernel which allows that my processor's cores get stuck for 22 seconds repeatedly?... It's a lot of log, but it is way better, safer, nicer than vanilla kernel... Pls. save grsec for FOSS, any of you guys who maybe can do it! I don't think vanilla kernel can be trusted... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've studied hard and presented some traces of the last week and longer, but exactly this one I noticed, and failed to post at: grsec-unoff RAP related Call Traces
The text was updated successfully, but these errors were encountered: