grsec: halting the system due to suspicious kernel crash

[timbgo]

Code: Select all

[250833.616726] Kernel panic - not syncing: grsec: halting the system due
to suspicious kernel crash caused by root
[250833.616782] drm_kms_helper: panic occurred, switching back to text console

However, all I could do in text console is take a picture with my mobile camera...

I trust there just was perfectly enough reason for Grsec/Pax to halt the kernel.

I don't want to bother Spender and Pax, and it would be great if someone of you
clever people who use these great program, such as M$ used it in Skype (oh, but
they tried to covertly used it, ooh what a pity they were brought to light by a
fine hacker)...

Pls. I earlier posted on that, look it up here:
https://forums.grsecurity.net/viewtopic.php?f=3&t=3594#p13203

I really would be so happy if there were a little more gratitude among you big
guys and big firms who use this
(I am a user of very modest means who can't even afford to eat
well, that's how I modest),
and give us, the users of Grsec/Pax, here, upon this example that I can provide,
some insight into the attack that happened.
By gratitude I mean gratitude to Spender and Pax Team.
The system I have not booted into, and I am taking disk dump images (with dd)
of all the system partitions, having booted into latest sysresccd
instead, but I'll be around, as soon as I get a little sleep, to follow possible
advice on what to and where to possible search something in the non-system
partitions.

I suspect it is an attack because only with two of my systems which I went online
these days and weeks I have had strange issues.
And I can prove those issues with both wireshark pcapng captures and, so regular
users like me would understand I also keep screencasting with ffmpeg, courtesy of
Christian Marillat, certainly not Stefano Zachiroli...

Pls. don't try to blame any of what I write to anyone else but me.

Pls. any of you high level users, or pros, give us an insight into what happened here.
Tell me what I need to provide you, like I know it's /var/log/messages and
/var/log/kern.log to look into... but possible so much more...

Because I believe it would be great for normal users like me, to have an insight
into the great defence for their systems, and for the developers of Grsec/Pax that just means
absolutely ligitimate work and absolutely ligitimate goals of protecting systems,
but for me, if I translate it, it means my data is sooo much safer than if could
never ever be with any other crap like SELinux or any other protection for systems
that I don't think stand any chances in comparison with Grsec/Pax. Not everybody
can be neither Leonardo nor Michelangelo.

The system that panicked, and was halted by grsec is my Gentoo install. And it was
much less online than one of my Debian sytems. Just enough to:

Code: Select all

$ eix sync && emerge -qavtUDN ...

,
and the downloaded packages I then use for my other Gentoo systems that work just about
faultlessly.
However, I have noticed (on Wireshark) very frequent communication btwn the sometimes online Gentoo box
and the more online Debian box.
The communication on non-internet connected local network, but when online with one of the systems.
The Debian box is the defence, the data not really there to ruin...
After having had loss of data for being exposed online, I am offline mostly with Gentoos,
the bigger boxes.

Soo, here's the screenshot of the halted system (I hope I can upload it somewhere)
it's:

Code: Select all

$ ls -ltrh grsec_halts_kernel_130820_0540.jpg
-rw-r--r-- 1 mr mr 3.6M Aug 20 03:46 /Cmn/mr/grsec_halts_kernel_130820_0540.jpg

I don't know yet.
I most certainly don't want to stay online for long with my NSA or some such cause
infected system.
Here's the sha256 in case there is no such option:

Code: Select all

$ sha256sum /Cmn/mr/grsec_halts_kernel_130820_0540.jpg
b39ac0daca6c732438e03dd47396633462333e9281a024736ff9729284facaae  grsec_halts_kernel_130820_0540.jpg
$ identify grsec_halts_kernel_130820_0540.jpg
grsec_halts_kernel_130820_0540.jpg JPEG 3264x2448 3264x2448+0+0 8-bit sRGB 3.721MB 0.010u 0:00.000

I need some rest now. I'm also not a healthy person, so if I take longer, pls have
a look at my posts, I always come back (no red-shaded posts to blame on me).

Miroslav Rovis

I hope I have somehow made it to make this picture of the monitor of panicked Gentoo
available near this post... (I wrote this in advance while offline).

No, I don't see such possibility on forums.grsecurity.net.
So I have to either later come back once I bave posted it somewhere, or wait if I get
a permit by administrator to post it somehow here.
But I have also prepared a downsized version of it:

Code: Select all

$ identify 2013-08-20_05.40.57_1280x1080.jpg
2013-08-20_05.40.57_1280x1080.jpg JPEG 1280x960 1280x960+0+0 8-bit sRGB 848KB 0.000u 0:00.009
$ ls -lh grsec_halts_kernel_130820_0540_1280x1080.jpg
-rw-r--r-- 1 mr mr 828K Aug 20 05:57 grsec_halts_kernel_130820_0540_1280x1080.jpg
$

[PaX Team]

there are many file sharing sites where you can upload your screenshot or just email it to us. in the worst case, just transcribe it into text, seemingly you're such a prolific writer that it should take you even less time than your original report.

[timbgo]

Thank you, Pax Team!
I have, offline, prepared the text as if I knew what you would suggest. Here it goes.

Code: Select all

[250833.610357] general protection fault: 0000 [#1] SMP
[250833.610392] Modules linked in: videobuf_dvb dvb_core cx88_vp3054_i2c cx8802 cx88xx tveeprom btcx_risc videobuf_dma_sg videob
uf core rc_core v4l2_common videodev radeon fbcon bitblit softcursor font cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit drm_kms
_helper ttm snd_hda_codec_hdmi drm snd_hda_codec_realtek snd_hda_intel fb snd_hda_codec fbdev sky2 r8169 snd_hwdep shpchp
[250833.610601] CPU: 3 PID: 3631 Comm: nfsd Not tainted 3.10.5-hardened-r1-130817_04 #2
[250833.610640] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P1.90 07/11/2012
[250833.610690] task: ffff88042d6c8840 ti: ffff88042d6c8d50 task.ti: ffff88042d6c8d50
[250833.610728] RIP: 0010:[<ffffffff8122f1fd>]  [<ffffffff8122f1fd>] lru_put_end+0x26/0x6d
[250833.610774] RSP: 0018:ffff880411b6dd58  EFLAGS: 00010213
[250833.610802] RAX: fefefefefefefefe RBX: ffff8802a26008e8 RCX: fefefefefefefefe 
[250833.610837] RDX: ffff8802a26008f8 RSI: 0000000000220019 RDI: 0000000000000004
[250833.610873] RBP: ffff880411b6dd68 R08: ffff88043fd95c60 R09: 0000000000000000
[250833.610909] R10: 0000000000000000 R11: ffffffff81a42290 R12: 010101020feda532
[250833.610944] R13: ffff8802a26008e8 R14: 0000000000000002 R16: ffff880411aa8000
[250833.610980] FS:  0000029a59d28700(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000
[250833.611021] CS:  0010 DS: 0000 ES: 0000 CR0: 000000000005003b
[250833.611050] CR2: 0000040000000000 CR3: 00000000016a7000 CR4: 00000000000007f0
[250833.611086] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[250833.611121] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[250833.611156] Stack:
[250833.611168]  ffff88043fd95c60 000000003a93b3c5 [... my fingers fell off my hands here...]
[250833.611209]  ffff880411aa8028 000000072bfeff   [... ditto ...]
[250833.611250]  ffff880411b6ddc8 ffff880411aa80   [... ditto ...]
[250833.611291] Call Trace:
[250833.611307]  [<ffffffff8122f83d>] nfsd_cache_      [... || ...]
[250833.611340]  [<ffffffff81227e5b>] nfsd_dispatch    [... || ...]
[250833.611370]  [<ffffffff8165f4df>] svc_process+0x   [... || ...]
[250833.611                                            [... || ...]   
...
...[ some 10 lines skipping here, which if need will be, will do them in next post ]...
...
[250833.616726] Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root
[250833.616782] drm_kms_helper: panic occurred, switching back to text console


EDIT START
Finally! Wed Oct 30 18:15:00 UTC 2013
I offer now the photo that I used for transcibing above, to the readers:
http://www.croatiafidelis.hr/gnu/grsec/2013-08-20_05.40.57_at8-g250_1280x1080.jpg
or maybe it displays fine for you on this site (not for me, it displays cropped for my 1024x768 monitor):

EDIT END

In case either if the picture can and if it cannot be uploaded, this will be useful. In case it
is by the time a later reader read this, he could have found the text only if some
search engine didn't hide from users (as Google often hides) that those words were
to be found here in this text above.

This is that last text displayed on my monitor when the kernel froze.

This above, manual copying work, is just my pledge to show the readers how serious
my desire to contribute in the just and honest side of computing (Grsec/Pax is the
cleanest and the make-or-break point in free computing of today, yes it is![*]),
which for me means possibly free from systematic/regimatic surveillance and abuse.
I actually believe that there probably is all this information somewhere to be
found on my system, as long as I keep it mounted readonly, which I intend to
do...
However, not for more than a day or two or so. I need that worker system of mine.
And for me to be able to do more, I'd need to be told where I could possibly
get to maybe read a tutorial on the internet on this or any other info.

Anybody to help with advice?
If only one small fraction of people whose computers have been protected by Grsec/Pax
showed up with advice/tutorials for their GNU/Linux distro/tips&tricks here,
these forums would teem with great stuff, and even newbies would find their
ways!

And Grsec/Pax developers would be free for their work! Wake up people, don't be selfish.
Let's not allow these people who we all need for Grsec/Pax in our boxes, to overwork and burn.

Along with this Gentoo system that crashed, I certainly cannot stay online for
much more with my compromised Debian box either, which I just cannot trust after
long downloads online such as the Debian weekly builds.

I have my poor user's defences, and I'll probably be able to revert the state
of this or another of my Debian boxes to a hopefully clean state, and I'll
also try and update Debian to the current state of the testing branch, and the
latest grsec/pax patched kernel.

I will need some time for all that, and I'm a late adopter, am now 56, so let's
see how this story goes.
Bear with me.

I sure had to write all this offline...

Miroslav Rovis

==============================================================================
[*] Grsecurity/Pax is the
cleanest and the make-or-break point in free computing of today. Yes it is!
Surely leave out M$ and Apple, they have backdoors and do you in, anytime in
any matter, with your Internet/local/any work on your computer.
GNU/Linux is the OS having the sound, unbreakable backbone of the GNU License,
which is more than just techie open source Google style or worse yet licenses.
So it's both free and open and cannot get, well it should not get, well if it gets, the
world has lost free computing...
So it's open and ... cannot get into some Larry Oracle hands like Java and MySQL
and others...
But Linus sold out to NSA. Yes he did.
It seems he decided he has to remain the number one in the world, even though there's these
guys here, who wrote Grsecuriy/Pax, who beat him.
The only thing that makes your GNU/Linuces viable for your privacy which most every
country vows to uphold in their Constitutions, but most no country in the
world really upholds in practice...
Most every country has some Forth Amendment kind of clause telling the world
how their citizens' privacy is sacrosaint...

But Linus sold out to NSA. Yes he did. And what was a program that NSA wanted
to sell as somebody else's, some now rather forgotten people's from RedHat
Linux probably some decade or more years ago... NSA seem to soon had to admit
that that program wasn't made by those Red Hat developers... I read the
correspondence, and I cannot find that correspondence now, if somebody knows, give
us the link... it's on, I think http://www.lwn.net
btwn Spender, Pax and those little important developers, and even I could figure out they
didn't understand their "own" program...
Anyways, the GNU/Linux developers' world not being made of dupes and dummies as some NSA
chief must have expected, NSA eventually came out and owned up to this program that
is such great friend of Linus Torvalds, which is:
SELinux (Security Enhances Linux)
SELinux, according to these guys, more precisely Spender I know saw that it
was so (read my other posts, I did give a link somewhere), according to these guys Spender
and Pax Team, who I completely support not for any sycophantic reasons, but because they are my,
a poor user, a late adopter of very incomplete competence in the matter, because they are my
only chance to use my computers freely...
SELinux, according to these guys, was back then full of purpose built hooks
for root-kit kind of intervention. Well, what would you expect from a program made by NSA?
That it would be made for your freedom and not for their spying on you under the guise
of a secure system...?

Support is lacking here, for Grsec/Pax, and I mean honest big business (is there any? how
much honesty is there left with, say, Google after it sold out for spying?; and Larry and
Serge did start honestly!)... or at least some medium size businesses... There
must be some left... Or numerous small businesses if there were... And
worldwide, not only U.S. of A. Businesses should, and thanks to those that do,
which you see their logos associate with Grsecurity/Pax! Businesses should
recognize that they all need Grsec/Pax in GNU/Linuces!

But I can assure you, not for knowing it, noo! I'm not an insider, but I look
with eyes without dirt of lies and disguise, by the grace of God, or if you don't feel
you can believe, then, by the virtues of honesty and diligence and sincere insight on things
availabe for seeing for all of us...

But I can assure you, taxpayers' money, and not only U.S. of A., but at least some
European countries too, in some shady ways, is flowing toward... toward
breaking the freedom of GNU/Linux, via SELinux or other stuff... for the sake
of surveillance.

SELinux may have even metamorphosizes in some ways...
The rootkit ready hooks may even have been near perfectly hidden by now...
Hooks so NSA and other big subjects of the kind might get their hold on
GNU/Linux boxes when they need do so...

That's where Linus Torvalds sold us!

The only thing that makes your GNU/Linuces viable for you to use them to be free
and do things on Internet freely, and freely live your lives which often requires free
computing, such as free unsurveilled communication worldwide...
The only thing that makes your GNU/Linuces viable for so much is Grsec/Pax!
Go ask bigger boys then me about it.
If they don't lie, they will confirm my words.

This truth above needs to be spread!
Newbies need to know this!
Again, newbies need to know this!
There is some free speech left in the leader, arrogant and abusive leader that
the U.S. of A. has become, but still the leader country, although not for long more...
In the leader country and lots of other contry that pretty much follow it.a
Not for long more... You are breaking on the inside, dear U.S. Americans, what about you
Veterans who you take to wars for no reason, and discard like rags when they break,
what about you homeless, your crap GMO food, you filthy banksters' elite of dirt...
But there is still some free speech.
If you keep quiet about these truths, dear reader, they'll manage to take away
from us the last bastion of defence of free computing, and that is GNU/Linux...
==============================================================================

So the NSA or somesuch subject didn't succeed on my box, Grsec/Pax defended my
computer...
That's the suspicion of mine. I can't prove that, but sure I can't let you
forget that the wholesale spying on all talk, all mail, all communication
whatsoever, in shameless denial of privacy is on most of the whole
world, very big-brotherly Orwellian, which makes my suspicio so very possible!
Don't forget Edward Snowden and his revelations ever!
Sure it could be some rogue individual hacker, but they don't break where
there's no money (and there isn't any here), unless they are paid money to
break... Soo...
Now back to what I wrote much further above.
I need advice what to look up in the box that crashed and that I'll keep
mounted readonly (the partition which I cannot disk dump backup)
for a day or two or three, I don't know how long I am going to wait...
I did dd'ed all the system partions. I'll only wait if any of the readers
gets me somewhere, maybe address of some tutorial, where I could possibly
look up for things related to this probable attack, on the data partiton.
Because the data partition is some 600GB, and I need it for my work, so this is
urgent advice or it'll be late...
Surely I will run clamav on it, but not much more do I know what to do...
On the other hand, I'll be able to loop-mount the dd'd system partitions even
probably a month or two or more from now, because I'll keep them longer for
some late advice maybe.
And in such way, if you are a late reader of this line and could help, I
probaly still have the snapshots of the the exact state of my system partition
at the time of the crash.

Looking short term, I'll now do usual Debian updates and check and report Grsec/Pax
install on it. And it'll take longish too...

Miroslav Rovis (again I sign this, I'm broken with tiredness, if things are
unfinished, I may or may not try to edit, and note those edits with capital
EDIT letters if I do, but the work I have on my hands, and it's not all computing
related, is bigger than the time I have available)

[spender]

Hi Miroslav,

You've actually found a real bug (potential vulnerability) in the upstream Linux kernel. This was detected thanks to a recent addition to grsecurity contributed by Mathias Krause: slab object sanitization. As mentioned in its config help, it's also useful for detecting use-after-free vulnerabilities, as it's done here. It uses the fill pattern of 0xfe on amd64, because on following a sanitized pointer of this pattern, 0xfefefefefefefefe will be dereferenced, causing a GPF due to it being a non-canonical address (uppermost bits must be either 0xffff or 0x0000). I'm 99% sure this is exactly what happened here, as you can see by the oops type and contents of rax and rcx registers, but we can confirm it easily if you give us the "Code: <hex digits here>" line appearing at the end of the oops message, or by providing the corresponding vmlinux.

Is this issue reproducible for you at all? We'll likely need to report this one upstream to have it fixed, as it'll be much more easily fixed by someone with intimate knowledge of NFS. Having some clear, small, reproducible testcase would help that person fix the problem.

Thanks,
-Brad

[timbgo]

Thank you!
Glad that I'm useful.
Already at the time of my previous post I sent the image to you, Spender.
But, judging by you reply, you seem not to have got it.
And just now, I also sent it, to you again, but also to pageexec at freemail dot hu
But I have screencasts to prove it, and also wireshark captures.

Code: Select all

$ sha256sum ws_130820_2227.pcapng Screen_130820_2226_debinv38.mkv
03db6a9f34fdb477fb4ebd64036d577e6c1ea2a502be29378bfa4172a2203ca1  ws_130820_2227.pcapng
0224d7aa6a00beee8f5b742d2b99cbbb7a9f9e424ade8426034aa6ba385d4c69  Screen_130820_2226_debinv38.mkv
$

I will now urgently postpone what I thought I would first do, and try to more fully respond to what you said I needed to do. Which means I first have to properly understand what you told me, which is not so trivial to me...
Wait, I understood this one. I need to send you the vmlinuz that crashed.
I'll do it next. If I don't pronto report otherwise here it has been sent.
Miroslav Rovis

[spender]

Hi Miroslav,

We've confirmed based on what you provided that it was indeed a use-after-free bug that you triggered (caught by grsecurity).

Thanks,
-Brad

[timbgo]

To your address and to Pax's address I now sent the vmliuz too.
I can't figure if you received the image or not.
And did you now received a gpg-signed vmlinuz in question?
So I don't need to wake on this to be in the clear?
Miroslav Rovis

But, like I said I'll be back once I have understook what more I need to do which is not trivial for me.

[spender]

Hi,

Yes, I've received three mails here.

-Brad

[timbgo]

Hi!

I'm 99% sure this is exactly what happened here, as you can see by the oops type and contents of rax and rcx registers,

I wish I could see but it's mumbo, mostly, for me. Never mind!
You probably mean what is after the hardware and module listing, and those RIP, RSP, RAX, RBP all the way to DR0 and DR3 lines...
And after the Stack: (three lines)
And after the Call Trace: (exactly ten lines)
This code:

Code: Select all

[250833.611598] Code: ba 2c 24 3f c3 55 48 89 e5 53 48 89 fb 41 50 48 8b 05 18 0e 86 00 48 8b 4b 10 48 8d 53 10 bf 04 00 00 00 48 89 43 58 48 8b 43 18 <48> 89 41 08 48 89 08 b9 c0 d4 01 00 48 8b 05 08 c3 b8 00 48 c7

EDIT START
Finally! Wed Oct 30 18:19:35 UTC 2013
Compare
http://www.croatiafidelis.hr/gnu/grsec/2013-08-20_05.40.57_at8-g250_1280x1080.jpg
or maybe it displays fine for you on this site (not for me, it displays cropped for my 1024x768 monitor):

EDIT END

But you need to check it against the screenshot (by mobile camera) taken of my monitor, which I'll probably find out if you receive once I'm back online, for correctness...
If that is what you are talking?
Namely I guess the whole screen is what you refer to as the Oops message (because I didn't locate and "oops" word on it, but that is what it probably is...
And now for the newbies.
Esp. those reading this much later on. I'll finish the manual copying of the whole screen. Just I ne
ed time more...

Miroslav Rovis

[timbgo]

Is this issue reproducible for you at all? We'll likely need to report this one upstream to have it fixed, as it'll be much more easily fixed by someone with intimate knowledge of NFS. Having some clear, small, reproducible testcase would help that person fix the problem.
-Brad

I'll be glad to be even more useful, but how do I reproduce it?
I have the same kernel, well, just compiled locally, on three more Gentoo systems.
How could I reproduce it.
Only this one that some attacker, probably, from the live internet connection from the Debian system, interfered with, only this Gentoo sytem, that itself was online (for eix update, and layman whatever... downloading the packages from Gentoo repositories) of all my Gentoo system, crashed...

[[ Only this one Gentoo system that some attacker, probably, from the live internet connection from the Debian system, interfered with, through local non-internet-connected network that all the systems are on... ]]

Miroslav Rovis

[timbgo]

What Spender says "As mentioned in its config help"
(https://forums.grsecurity.net/viewtopic.php?f=3&t=3709&p=13413#p13407
, I think refers to, if looked up, for readers' convenience, on this page:
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options
it seems to me refers to:

Miscellaneous hardening features

Sanitize all freed memory

PAX_MEMORY_SANITIZE

Yes, I read all the guides, and Gentoo has proper guides on this, Debian is sorely lacking most any for now...
And I sure selected that one! It's source of pride for me my having configured it properly that I don't mind Pax Team teasing me about my prolific writing :
https://forums.grsecurity.net/viewtopic.php?f=3&t=3709&p=13413#p13400
.

Anyways, for the newbies newbier than me, I'll finish off the text-reconstruction of the Oops frozen page, all in its own post, complete, next.

Just let me go back to Debian: no guides, and huge population of users! So half-computer literate me being, in comparison to these giants that condescended to converse with me above, I have not configured it in my Debian Grsecurity/Pax enabled kernel.
Here:

Code: Select all

$ grep PAX_MEMORY_SANITIZE /boot/config-3.10.5-grsec-130807
$

(that's empty string returned)
Too much work to figure all so quickly! Will be back to report if I fixed my Debian, as this simply is a matter of survival for me. I'm like a sparrow, could not live in any "Not Such Agancies" cages. (as they recently explained on Russia Today, where great American homeland and offshore dissidents often are interviewed, "No Such Agancy" was the nickname for NSA since 1952 when U.S. of A.'s president and world war criminal Harry Truman established it).

All the time, the Gentoo box in which the above suspicious kernel crash occurred, and where, my thanks here also go to Grsecurity/Pax Gentoo GNU/Linux implementers, the non-SELinux hardened team (because, sadly, Gentoo is not SELinux free as offer to the uninformed, and newbies easily end up with those NSA's hooks for the spies, in the kernel)... all the time the Gentoo box in question was off-line, safely, more precisely would-be safely away from the internet and its lurks and all kinds of its malicious subjects, some big, even very big like the "No Such Agancy", some whatever size, down to minuscule...

That Gentoo box was off and away from the internet, but was, as I previously said, the only one that was online for download of the new packages from Gentoo repositoritories, some week ago now, and back from then, a month, and some two months ago, for same kind of download. I haven't reverted it into clean state yet (in my what I call poor user's defence, clean state is reverting it from previous system backup and installing the new packages not via online, but from existing local downloads of those) in probably a few weeks, so there's where some intrusion may have gained a foothold.

Now, the exact processes that to me as user seem to bear connection to the suspicious crash, were moving this file:
debian-testing-amd64-DVD-11.iso
that I downloaded through due procedure using the jigdo files from:
http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-dvd/
Upon checking the sums, I noticed that, while the other DVD-XX.iso files, all the first 10, were of correct checksum, this one wasn't.
Wait, not in the Debian box where I downloaded it. The jigdo program didn't complain, No, said "The checksum is good!". But on the Gentoo box where I moved it.
Because in my poor user's defence against various no-such-agencies or other lurks and malicious subjects, I use cloning systems and installing almost only offline. This one dirty? I'll use the next clone that I created off line earlier... How cloning is done, look up my posts on Gentoo. There I am user MiroR, Gentoo I haven't noticed that they delete users' posts. And for the cloning sure you need network and more machines... Old is fine, for internet access (if it's not very old)!
Seeing the DVD-11.iso was not of correct checksum, and I still have that somehow compromised one, and I'll keep it for months from now, here's that wrong checksum:
No, I'm giving you no checksum. I'm jumping into my mouth instead. Because the checksum is exactly as it should be.
I still have System Rescue CD started from usb stick on that system, and checked and all the sums are correct. They are in the data partition mounted readonly, sure. Still waiting for possible advice to be able to restart using that system.
The system was compromised and it did show wrong checksum, but that was something wrong with the system, not with the DVD-11 of the Debian weekly testing branch! Curious!
I can confirm that before God and the Heaven, because I have the old SHA256SUM.my where I calculate sums in when I check them!
This is the first time in my life that I see the program sha256sum return erroneously wrong value while the value is correct in reality, for some suspicious, probably malicious, activity on my system! Curious!

I would like to know what happened in my kernel that I sent to Spender and Pax Team via email.
I would only like, I don't hold the big guys and the giants of bound to tell us here, I'm proud anyway to have been able to help!

So any of you big guys, if you remember, tell us more, in as possibly user-understandable talk as you can!

Or my peer common users, if you find anywhere talk about this file:

vmlinuz-3.10.5-hardened-r1-130817_04

and related to this bug, give us the link here, because that is the kernel in question I sent to Brad and Pax Team.

Thank you!

I'll also make a note about this on Gentoo GNU/Linux forums, where I am user MiroR. Let as much as possible of the GNU/Linux population of users know what protection Grsecurity/Pax provides to common users like me, along with M$ Skype (pls. find link somewhere in some of my previous posts if you don't yet know about the would-be-covert use of Grsec/Pax by Microsoft) and all the others!

And now, as I promised many lines ago above, I need to type out the rest of the Oops page next. Ouch!

May God bless all the readers!

Miroslav Rovis,
Zagreb, Croatia

[timbgo]

Code: Select all

[250833.610357] general protection fault: 0000 [#1] SMP
[250833.610392] Modules linked in: videobuf_dvb dvb_core cx88_vp3054_i2c cx8802 cx88xx tveeprom btcx_risc videobuf_dma_sg videobuf core rc_core v4l2_common videodev radeon fbcon bitblit softcursor font cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit drm_kms_helper ttm snd_hda_codec_hdmi drm snd_hda_codec_realtek snd_hda_intel fb snd_hda_codec fbdev sky2 r8169 snd_hwdep shpchp
[250833.610601] CPU: 3 PID: 3631 Comm: nfsd Not tainted 3.10.5-hardened-r1-130817_04 #2
[250833.610640] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P1.90 07/11/2012
[250833.610690] task: ffff88042d6c8840 ti: ffff88042d6c8d50 task.ti: ffff88042d6c8d50
[250833.610728] RIP: 0010:[<ffffffff8122f1fd>]  [<ffffffff8122f1fd>] lru_put_end+0x26/0x6d
[250833.610774] RSP: 0018:ffff880411b6dd58  EFLAGS: 00010213
[250833.610802] RAX: fefefefefefefefe RBX: ffff8802a26008e8 RCX: fefefefefefefefe 
[250833.610837] RDX: ffff8802a26008f8 RSI: 0000000000220019 RDI: 0000000000000004
[250833.610873] RBP: ffff880411b6dd68 R08: ffff88043fd95c60 R09: 0000000000000000
[250833.610909] R10: 0000000000000000 R11: ffffffff81a42290 R12: 010101020feda532
[250833.610944] R13: ffff8802a26008e8 R14: 0000000000000002 R16: ffff880411aa8000
[250833.610980] FS:  0000029a59d28700(0000) GS:ffff88043fd80000(0000) knlGS:0000000000000000
[250833.611021] CS:  0010 DS: 0000 ES: 0000 CR0: 000000000005003b
[250833.611050] CR2: 0000040000000000 CR3: 00000000016a7000 CR4: 00000000000007f0
[250833.611086] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[250833.611121] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[250833.611156] Stack:
[250833.611168]  ffff88043fd95c60 000000003a93b3c5 ffff880411b6ddc8 ffffffff8122f83d
[250833.611209]  ffff880411aa8028 000000072bfeff68 0000000600000003 02d18804be52cde3   
[250833.611250]  ffff880411b6ddc8 ffff880411aa8000 ffffffff816f3eb8 ffff8801e9407018
[250833.611291] Call Trace:
[250833.611307]  [<ffffffff8122f83d>] nfsd_cache_lookup+0x36d/0x5e5
[250833.611340]  [<ffffffff81227e5b>] nfsd_dispatch+0x69/0x182
[250833.611370]  [<ffffffff8165f4df>] svc_process+0x42f/0x5c3
[250833.611399]  [<ffffffff812270b7>] ? nfsd_destroy+0x6b/0x6b
[250833.611424]  [<ffffffff812270b7>] ? nfsd_destroy+0x6b/0x6b
[250833.611453]  [<ffffffff81067b12>] kthread+0x94/0x9c
[250833.611482]  [<ffffffff81067a7e>] ? __kthread_parkme+0x66/0x66
[250833.611508]  [<ffffffff8169b682>] ret_from_fork+0x72/0xa0
[250833.611540]  [<ffffffff81067a7e>] ? __kthread_parkme+0x66/0x66
[250833.611598] Code: ba 2c 24 3f c3 55 48 89 e5 53 48 89 fb 41 50 48 8b 05 18 0e 86 00 48 8b 4b 10 48 8d 53 10 bf 04 00 00 00 48 89 43 58 48 8b 43 18 <48> 89 41 08 48 89 08 b9 c0 d4 01 00 48 8b 05 08 c3 b8 00 48 c7
[250833.611772] RIP  [<ffffffff81067a7e>] lru_put_end+0x26/0x6d
[250833.611802]  RSP <ffff880411b6dd58>
[250833.616726] Kernel panic - not syncing: grsec: halting the system due to suspicious kernel crash caused by root
[250833.616782] drm_kms_helper: panic occurred, switching back to text console


EDIT START
Wed Oct 30 18:19:35 UTC 2013, a little later
http://www.croatiafidelis.hr/gnu/grsec/2013-08-20_05.40.57_at8-g250_1280x1080.jpg
or maybe these images will display fine for you on this site (not for me, it displays cropped for my 1024x768 monitor):


And... And there I remember I made another photo, but can't find where I write about it, this one:
http://www.croatiafidelis.hr/gnu/grsec/2013-08-22_16.14.06_at8-g250_1280x1080.jpg
If any reader knows where that one fits, give us the link. I'n too busy now to read it all.
DITTO as for the picture above:

EDIT END

[timbgo]

A case of actual protection of my Gentoo box by Grsecurity
http://forums.gentoo.org/viewtopic-t-967806.html

[timbgo]

I have work to finish here, in this topic, but am still in no condition to do it.
The other side of the same problem (in my SOHO which so far is saved and still safe thanks to Grsec/Pax) is this topic:
https://forums.grsecurity.net/viewtopic.php?f=3&t=3712

Some of the problems that I need to solve include whether Debian can do the work that I need it to do at all.
There is nearly always "no PIE", no Position Independent Exetutable support in the Debian toolchain.
Pls. it is about this, which I also need to solve for the other OS to be used for my SOHO, on the slower machines, where the Gsntoo long-time compilations would prolong the installation to unacceptable, I'm afraid, it is about this:
https://forums.grsecurity.net/viewtopic.php?f=3&t=2131

I am thinking of a Debian based system, the gNewSense distro, and let's have a look if Richard Stallman's team's practice is as good as his own, the GNU and FSF founder's views, which I very much wish to be the case, I really do.

So I subscribed to gNewSense mailing list and sent them a query:
https://lists.nongnu.org/archive/html/gnewsense-users/2013-08/msg00053.html

Because Debian is currently having serious issues with the testing branch (also the available 2013-08-19 builds don't work for me, and that's an understatement):
http://cdimage.debian.org/cdimage/weekly-builds/amd64/
Lots of "...build failed with error 1 at 2013-08-26..." there.
I'm really not relishing, really I wish Debian would shine in the future, but could it also be that so it happens when you stray from the right path?

I can confirm that after those problems that occurred when Debian was connected both to my... Wait, this belongs to the other side, the Debian side. I go now and write there about what I can confirm.
Wrote:
https://forums.grsecurity.net/viewtopic.php?f=3&t=3709&p=13455#p13455

[timbgo]

There has been discussion about Grsecurity in reagard to Debian and the Debian based
gNewSense.
I have been trying for one and half hours to reply to this email of Karl Goetz
https://lists.nongnu.org/archive/html/gnewsense-users/2013-09/msg00000.html
The unsuccessfully tried to send message's sum:
fc98a9d80192d18c7a88b0b265643dd1d5e20c3cba725bae08d46dfc9fd63dee