vma_wants_writenotify general protection fault

[miroR]

Nov 25 00:34:24 gdOv kernel: [ 4174.947170] general protection fault: 0000 [#1] SMP
Nov 25 00:34:24 gdOv kernel: [ 4174.947275] Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_tcpudp xt_conntrack iptable_filter iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw ip_tables x_tables cx22702 isl6421 cx24123 cx88_dvb cx88_vp3054_i2c wm8775 videobuf2_dvb dvb_core ir_lirc_codec ir_rc5_decoder lirc_dev rc_hauppauge tuner_simple tuner_types tda9887 edac_mce_amd edac_core kvm_amd kvm mxm_wmi irqbypass amdkfd tda8290 radeon ttm tuner drm_kms_helper cx8800 cx8802 cx88_alsa cx88xx pcspkr evdev tveeprom videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 v4l2_common videobuf2_core drm snd_hda_codec_realtek snd_hda_codec_generic videodev serio_raw snd_hda_intel snd_hda_codec k10temp media snd_hda_core snd_hwdep snd_pcm snd_timer snd i2c_algo_bit soundcore fb_sys_fops syscopyarea
Nov 25 00:34:24 gdOv kernel: [ 4174.958058]  sysfillrect wmi sysimgblt shpchp sg sp5100_tco nuvoton_cir rc_core button acpi_cpufreq ext4 crc16 jbd2 fscrypto mbcache xts gf128mul algif_skcipher af_alg dm_crypt dm_mod sr_mod cdrom sd_mod ata_generic uas usb_storage ohci_pci psmouse r8169 mii firewire_ohci firewire_core crc_itu_t sky2 ahci pata_atiixp libahci ohci_hcd xhci_pci ehci_pci ehci_hcd xhci_hcd libata i2c_piix4 usbcore scsi_mod fjes
Nov 25 00:34:24 gdOv kernel: [ 4174.979696] CPU: 3 PID: 4130 Comm: Xorg Not tainted 4.9.65-unofficial+grsec171124-19 #1
Nov 25 00:34:24 gdOv kernel: [ 4174.985496] 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 25 00:34:24 gdOv kernel: [ 4174.991416] task: ffff88031d49e800 task.stack: ffffc9000a250000
Nov 25 00:34:24 gdOv kernel: [ 4174.997404] RIP: 0010:[<ffffffff8115a534>]  [<ffffffff8115a534>] vma_wants_writenotify+0x94/0xc0
Nov 25 00:34:24 gdOv kernel: [ 4175.003510] RSP: 0018:ffffc9000a253c90  EFLAGS: 00010287
Nov 25 00:34:24 gdOv kernel: [ 4175.009523] RAX: ff880320b34800ff RBX: 8000000000000027 RCX: 4000000000000000
Nov 25 00:34:24 gdOv kernel: [ 4175.015566] RDX: 0000000000000020 RSI: 2000000000000000 RDI: ffff88031c92e48f
Nov 25 00:34:24 gdOv kernel: [ 4175.021537] RBP: ffff8802e1154cc0 R08: ffff8802e1154cc0 R09: 00000000140440bb
Nov 25 00:34:24 gdOv kernel: [ 4175.027532] R10: 8000000000000027 R11: ffff88031eab6860 R12: 00003ffffffff278
Nov 25 00:34:24 gdOv kernel: [ 4175.033505] R13: 00000000140440bb R14: 0000000000000001 R15: 00000374bb7cf000
Nov 25 00:34:24 gdOv kernel: [ 4175.039453] FS:  00000374bb7b6a40(0000) GS:ffff88032fd80000(0000) knlGS:0000000000000000
Nov 25 00:34:24 gdOv kernel: [ 4175.045452] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 25 00:34:24 gdOv kernel: [ 4175.051399] CR2: 0000040000000000 CR3: 00000000017e9000 CR4: 00000000000006f0
Nov 25 00:34:24 gdOv kernel: [ 4175.057441] Stack:
Nov 25 00:34:24 gdOv kernel: [ 4175.063448]  ffffffff8115a594 00000000140440bb 00000374bb7cf000 ffff88031d4959
Nov 25 00:34:24 gdOv kernel: [ 4175.069591]  ffff880320eea100 ffffffff8115c27f ffff88031f278d00 00000000001015
Nov 25 00:34:24 gdOv kernel: [ 4175.075826]  0000000000000000 ffff8802e1154cc0 00000000140440bb ffff8802e1154c
Nov 25 00:34:24 gdOv kernel: [ 4175.082147] Call Trace:
Nov 25 00:34:24 gdOv kernel: [ 4175.088447]  [<ffffffff8115a594>] ? vma_set_page_prot+0x34/0x60
Nov 25 00:34:24 gdOv kernel: [ 4175.094845]  [<ffffffff8115c27f>] ? mmap_region+0x2cf/0x6d0
Nov 25 00:34:24 gdOv kernel: [ 4175.101240]  [<ffffffff8115cbe0>] ? do_mmap+0x560/0x620
Nov 25 00:34:24 gdOv kernel: [ 4175.107598]  [<ffffffff81142259>] ? vm_mmap_pgoff+0xb9/0x100
Nov 25 00:34:24 gdOv kernel: [ 4175.113854]  [<ffffffff8115a3d9>] ? sys_mmap_pgoff+0x1a9/0x270
Nov 25 00:34:24 gdOv kernel: [ 4175.119941]  [<ffffffff811b68e8>] ? sys_ioctl+0x58/0x80
Nov 25 00:34:24 gdOv kernel: [ 4175.125885]  [<ffffffff8154fdb9>] ? entry_SYSCALL_64_fastpath+0x17/0xa8
Nov 25 00:34:24 gdOv kernel: [ 4175.131808] Code: c0 74 a4 48 8b 80 f8 00 00 00 48 85 c0 74 98 48 8b 38 48 c7 0 00 00 8b 40 18 f7 d0 83 e0 01 c3 e8 a7 0d 08 00 
Nov 25 00:34:24 gdOv kernel: [ 4175.144458] RIP  [<ffffffff8115a534>] vma_wants_writenotify+0x94/0xc0
Nov 25 00:34:24 gdOv kernel: [ 4175.150683]  RSP <ffffc9000a253c90>
Nov 25 00:34:24 gdOv kernel: [ 4175.180523] ---[ end trace f27b58d845ba30f4 ]---
Nov 25 00:34:24 gdOv kernel: [ 4175.180541] grsec: banning user with uid 1000 until system restart for suspici

[minipli]

What did you do to trigger this? Can you reproduce this on vanilla?

[miroR]

On 171125-18:14+0000, minipli wrote: What did you do to trigger this? Can you reproduce this on vanilla?

I got the logs, and they will tell you. Hmmh... let me see. I'll try and keep it short here, and once I prepare the (yet non-existent) page: https://www.croatiafidelis.hr/foss/cap/cap-171117-grsec-RAP-Oops/grsec-oops-171125-0034.php then I'll possibly try make it explanatory for non-advanced (possibly new) users to follow as well. LATER NOTE: Sorry, it didn't go that way... there just were too important aspects to explain that did not fit in few sentences only... But, oh, no! I wasn't doing anything... I was sleeping (Europe CET here, but my logs are in UTC)... I was already sleeping for one hour or so... I remember that much. So there may and may not be much in the logs. I can however, send the logs to you and to @HacKurx, in private email. Just say if you want them! And my pretty strong belief is it's something from some other part of the system, some cache or such (read near bottom for more), I need to point out here that I run hardware that may be close to or just of the year 2013 when AMD started including PSP in their processors: https://libreboot.org/faq.html#amd ... See here, there is my then new hardware, it's the hardware, MBO and proc of the systems of the Call Traces of mine of these days: Use old amd64 gentoo image on new amd64 hardware, possible? https://forums.gentoo.org/viewtopic-t-940916.html But just what, how do I know what caused that?... The following is important for understanding also. This system, as far as the HDD, is not the same as the one with the previous Call Traces. I changed the HDD. It is, however, still the unchanged system as the system of the previous traces as far as everything else, MBO, Ethers, RAM, you name it. I had cloned onto this HDD the same dd images as onto the previous HDD which I put into this same machine first, and had all those issues shown in the Call Traces previous to 25 of November... The machine, with the previous HDD in, must have been worked on by attackers, by AMD PSP/or its precursor, and by other means --I hope I'll manage to say more on that on the above linked grsec-oops-171125-0034.php page.-- But the guy(s) must have gotten tired to do it all over with the new HDD... Hi, guy(s)! Great work! Interesting work! Except you failed to b0rk my systems... That last Call Trace very early into the 25th of November probably happened out of something that remained in the system from previously, not from the fresh, clean from being cloned from my Air-Gapped machine, HDD, that I prepared and booted a few hours earlier. Because no more breakages since then... And in three different systems! One running my only-my-hardware no-outside modules 4.9.65, that's the Air-Gapped machine, other two, clones of the Air-Gapped machine, running all-modules-separately-available 4.9.65 kernel that I'd like to offer to newbies of Devuan/Debian. No more traces, no more breakages since then in any of the three systems! The theory that it's something not on HDD that caused this Call Trace is corroborated by very bad and persistent (but only up to a point after which it vanishes) apparent corrruption of the kernel, so inexistent corruption, as you can read at: grsec-unoff (RAP) related Call Traces, 171124-0102 oops https://www.croatiafidelis.hr/foss/cap/cap-171117-grsec-RAP-Oops/grsec-oops-171124-0102.php Doesn't it? No real corruption, and shows like one... And pls. notice that previously to switching back to BIOS, during my EFI weeks the boot partition was unencrypted! So the full disk encryption thwarted attacker(s)' plans very badly (for him/them)! But, of course, there is no firm evidence... A little more evidence there might show once I work out the network traces... I hope I haven't been too (verbosely) exhaustive... As far as your question, Mathias (minipli is Mathias Krause):

Can you reproduce this on vanilla?

I couldn't reproduce this, I don't think... I could install vanilla, but what should I do to try and reproduce it? Maybe if you see the logs... (if you want me to send them to you) I did have exec_logging and audit_chdir enabled right after setting the new HDD up, so maybe you find some suspectful binary execution somewhere... Regards! -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr