grsec-unoff RAP related Call Traces, 171122-1348 oops
(No. 0) 171114-1000-manu 171117-1426-oops 171118-0933-rsys 171118-1030-none 171122-1348-rsys 171123-1254 171123-1530 171124-0102-none 180101-1917-rsync
This one may be RAP related. I've just made a comment on minipli's grsec-unoff about it.
LATER EDIT: Of course it's not. Pls. see the chage of title by minipli in bottom of that comment of mine :-(
But I owe readers there explanation why I think it might have been caused by the later kernel (as I said in that comment).
Firstly, pasting the Call Trace here as well:
Nov 22 13:48:06 gdOv kernel: [53537.165773] PAX: please report this to pageexec@freemail.hu Nov 22 13:48:06 gdOv kernel: [53537.165785] BUG: unable to handle kernel NULL pointer dereference at 00000000000003e8 Nov 22 13:48:06 gdOv kernel: [53537.167255] IP: Nov 22 13:48:06 gdOv kernel: [53537.167262] [] do_blockdev_direct_IO+0x2c9d/0x4fe0 Nov 22 13:48:06 gdOv kernel: PGD 2e33b0000 Nov 22 13:48:06 gdOv kernel: [53537.167264] Nov 22 13:48:06 gdOv kernel: [53537.167265] Oops: 0000 [#1] SMP Nov 22 13:48:06 gdOv kernel: [53537.167269] CPU: 2 PID: 27492 Comm: tshark Not tainted 4.9.61-unofficial+grsec171114-20 #1 Nov 22 13:48:06 gdOv kernel: [53537.167270] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./970 Extreme4, BIOS P2.60 11/11/2013 Nov 22 13:48:06 gdOv kernel: [53537.167271] task: ffff88016ef2b280 task.stack: ffffc9000db84000 Nov 22 13:48:06 gdOv kernel: [53537.167272] RIP: 0010:[ ] Nov 22 13:48:06 gdOv kernel: [53537.167274] [ ] do_blockdev_direct_IO+0x2c9d/0x4fe0 Nov 22 13:48:06 gdOv kernel: [53537.167275] RSP: 0018:ffffc9000db87c48 EFLAGS: 00010246 Nov 22 13:48:06 gdOv kernel: [53537.167275] RAX: 0000000000000000 RBX: ffff88031d963900 RCX: 0000000000000000 Nov 22 13:48:06 gdOv kernel: [53537.167276] RDX: 0000000000000000 RSI: 00000000000003e8 RDI: 00000000ffffffff Nov 22 13:48:06 gdOv kernel: [53537.167277] RBP: ffffc9000db87c98 R08: 00000000ffffffc3 R09: 0000000000000000 Nov 22 13:48:06 gdOv kernel: [53537.167277] R10: ffffffff814958b0 R11: 0000000000000000 R12: ffff88031ecf9c00 Nov 22 13:48:06 gdOv kernel: [53537.167278] R13: ffff88031dba7800 R14: 0000000000000000 R15: 0000000000000000 Nov 22 13:48:06 gdOv kernel: [53537.167279] FS: 000003768b733ec0(0000) GS:ffff88032fd00000(0000) knlGS:0000000000000000 Nov 22 13:48:06 gdOv kernel: [53537.167280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Nov 22 13:48:06 gdOv kernel: [53537.167280] CR2: 00000000000003e8 CR3: 0000000002c26000 CR4: 00000000000006f0 Nov 22 13:48:06 gdOv kernel: [53537.167281] Stack: Nov 22 13:48:06 gdOv kernel: [53537.167282] ffffc9000db87c90 Nov 22 13:48:06 gdOv kernel: [53537.167282] 000000008128a28f 0000000000000000 0000000000000000<3>[53537.167284] 903bb4fa8554f77f Nov 22 13:48:06 gdOv kernel: [53537.167284] ffff88031dba7800 ffff8802e662b6e8 ffff88014d20f800<3>[53537.167285] ffff88031dba7800 Nov 22 13:48:06 gdOv kernel: [53537.167286] 000000000000001b ffffc9000db87ce0 ffffffff812f7fb8<3>[53537.167287] Call Trace: Nov 22 13:48:06 gdOv kernel: [53537.167291] [ ] prepare_binprm+0xc8/0x240 Nov 22 13:48:06 gdOv kernel: [53537.167294] [ ] do_execveat_common.isra.53+0x677/0xd20 Nov 22 13:48:06 gdOv kernel: [53537.167297] [ ] ? __check_object_size+0x178/0x31a Nov 22 13:48:06 gdOv kernel: [53537.167299] [ ] ? strncpy_from_user+0x6f/0x1e0 Nov 22 13:48:06 gdOv kernel: [53537.167301] [ ] ? getname_flags+0x85/0x260 Nov 22 13:48:06 gdOv kernel: [53537.167302] [ ] rap_sys_execve+0x6b/0xa0 Nov 22 13:48:06 gdOv kernel: [53537.167305] [ ] do_syscall_64+0x8d/0x180 Nov 22 13:48:06 gdOv kernel: [53537.167307] [ ] entry_SYSCALL64_slow_path+0x32/0x32 Nov 22 13:48:06 gdOv kernel: [53537.167308] Code: Nov 22 13:48:06 gdOv kernel: [53537.167309] 48 8b b4 24 48 03 00 00 eb 0b a5 65 b7 e6 ff ff ff ff cc cc cc e8 e4 a8 45 00 8b 94 24 54 03 00 00 39 c2 0f 84 b7 08 00 00 4c 8b 24 e8 02 00 00 4d 89 65 50 48 8b bc 24 30 02 00 00 eb 0b 00 <1>[53537.167331] RIP Nov 22 13:48:06 gdOv kernel: [53537.167332] [ ] do_blockdev_direct_IO+0x2c9d/0x4fe0 Nov 22 13:48:06 gdOv kernel: RSP Nov 22 13:48:06 gdOv kernel: [53537.167333] CR2: 00000000000003e8 Nov 22 13:48:06 gdOv kernel: [53537.175251] ---[ end trace 201210643accd5d1 ]--- Nov 22 13:48:06 gdOv kernel: [53537.175253] grsec: banning user with uid 1000 until system restart for suspicious kernel crash Nov 22 13:48:07 gdOv kernel: [53537.445984] grsec: (default:D:/) exec of /sbin/agetty (/sbin/getty 38400 tty6 ) by /sbin/agetty[init:27493] uid/euid:0/0 gid/egid:0/0, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 Nov 22 13:48:07 gdOv kernel: [53538.015583] grsec: (default:D:/) special role admin (id 3) exited by /bin/bash[bash:3958] uid/euid:0/0 gid/egid:0/0, parent /usr/bin/sudo[sudo:3957] uid/euid:0/0 gid/egid:0/0
The explanation is circumstantial. If I run my system only with kernel 4.9.61 with HacKurx's patch, I don't get any Oopses (recorded or not). That has shown to be the case in other two of my systems. But if I boot into 4.9.63 with same-author grsec-unoff patch, I do get an occasional Oops.
But it's actually more complex than that, because I have been having more or less constant trouble with bad providers in my country, and recently I have some indications, maybe even evidence, that they, in the least, facilitate attacks against me (albeit restricted; a provider, especially those bad ones, would cut you off for invented reasons, off from the internet, I mean, the way a water tap is turned off --Julian Assange once compared the internet to that, and said how it was created in such way that it can be managed like that--; [indications that they facilitate restricted attacks againt me] because the law, Croatian law as well, still protects common citizens from utter abuse by providers)... So... since my Oopses happened in the machine that I connect to internet with, and the other two do not connect --it's same MBO machines, and one of them is the master that I build in Air-Gap, the other two are clones of it, including this for-online one that most of the Oopses happened in-- so, since only this one connects to the internet via a bad provider, it is all that much more complex.
Examples of my provider's gratuitous abuses against me their user: inventing me spamming people, banning the use of my CroatiaFidelis.hr email and sending PDFs that can't open in some Linux programs, just so nobody dismisses easily my claims. They are documented. Hard thing, document provider's abuse! But it's undeniable... And some personnel from my provider's, namely the ... joyous guy who caused the nuissance recorded in the video --not the honest postman who delivered the mail, but the sender, of course-- in the first link, should get famous (but I still have compassion for that wrongdoer... it's the main IT company in Croatia, I am ashamed how he is allowed to bahave, because I love my country, and I want providers to be honest in righteous with their customers), so can tell even more openly, for that you'd need to be able to read Croatian in the main page about Croatian Telekom (at and after the video on that page)...
But enough of that. The trace is there with the recount of what happened.
And as far as circumstantial explanation, it's in the entire behavior of the system which can be concluded some facts or indictions about from other traces of this section, such as inexistent in later boots corruption of the XZ-compressed data (see 171114-1000-manu for that, but it also repeated in 171124-0102-none) and other stuff (some of which posted in this section by this time, and some of it not presented yet).
---
The verifiable files necessary for this study, if any, are listed in the main page of this section.
---