__fput unable to handle kernel paging request at ffffffbfa02c6430 #19
Comments
|
I'd say at least some of my issues are due to attacks... On another system this same kernel, so far: no issues. |
|
I wrote touching this and other of issues I opened at: |
|
I think you have a lot of modules. Because that should be "y", not "m" (more safe) in your kernel config. 1] Did you get the ip address of the attacker in your log or by GRKERNSEC_PROC_IPADDR? |
|
Let me reply to some of your questions below.
On 171125-20:45+0000, Loïc wrote:
I think you have a lot of modules.
Use the following command to identify your drivers:
`lspci -vvvv | grep Kernel | cut -d : -f 2 | sort | uniq`
just:
# lspci -vvvv | grep Kernel | cut -d : -f 2 | sort | uniq
(i.e.: without backticks)
Because that should be "y", not "m" (more safe) in your kernel config.
It's what I do for kernel for my own use, only my hardware, and no separately
compiled modules, running in my Air-Gapped currently, compiled later, named:
# uname -r
4.9.65-unofficial+grsec171124-23
But the one you're looking at, is what I'm trying to prepare for ambitious
newbies in either:
Grsecurity/Pax installation on Devuan GNU/Linux
https://dev1galaxy.org/viewtopic.php?id=596
or:
Grsecurity/Pax installation on Debian GNU/Linux
http://forums.debian.net/viewtopic.php?f=16&t=108616&p=658841#p658841
and that's the kernel that I'd like to work for most of users, if I manage to
prepare it correctly (and I'd be more greatful if you or minipli or some other
more knowledgeable contributor here looks at it before I can recommend it for
Devuan/Debian users (of course, only if any of you find it worthwhile, and if
keep in good form to be able to prepare it every so often; corsac kernel is
precious absolutely, but I like to do the testing of the new kernels, well, new
LTS grsec-unoff kernels).
And that kernel is named:
$ uname -r
4.9.65-unofficial+grsec171124-19
$
And this one has to have most modules enabled for the above reason.
1] Did you get the ip address of the attacker in your log or by GRKERNSEC_PROC_IPADDR?
I've been busy writing to Devuan ML, but... (read on)
2] Do you use wireshark every time you use the network?
...but I run https://github.com/miroR/uncenz whenever I connect online, and I
do have all the traces, will work them with
https://github.com/miroR/tshark-streams and
https://github.com/miroR/tshark-hosts-conv on top of looking them up with
Wireshark, as soon as I manage to get to you and to minipli more info that you
asked for (well, the other info, step by step, this point 2] of yours later).
2] Do you use virtualization?
I do have it enabled, but haven't been using it in Devuan yet. I did in Gentoo
previously. Have no Gentoo now (other than an old dd'dumped image or two,
dd'dumped images that I use for cloning, I mean).
I'll look up the /var/log/kern.log to get more info for the next question, by
@minipli, for me to reply:
vma_wants_writenotify general protection fault
#18 (comment)
What did you do to trigger this? Can you reproduce this on vanilla?
Regards!
--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
|
If anybody bets, yes, it happened as I went online, and after just minutes online altogether this day, in two separate sessions... (this is third short session today)... |
|
The last comment is a different bug. It traps in schedule(). Please create a new issue for that one if you're able to reproduce it with a recent kernel. Please also mind the closing thoughts of #13 (comment). |
Pasting it here for completeness:
Well, the report follows... As promised, I tested the memory of the system in question. The looks of all the stages contain the same input throughout the screen, except for So, to report on the memory of the computer in which almost all the Call Traces happened (almost none happened in the Air-Gapped master machine, which is same hardware, same memory modules, same processor, and I repeat: my guess is it has to do with likely some exploits introduced from the network, namely (almost) only this clone machine has had all the Call Traces, while master and another clone --but which is not connected to online ever-- had almost none of those Call Traces. So, I repeat, I believe those Call Traces have little to do with programming errors in grsecurity, rather it's some exploits and/or use of the Amd64 PSP functionality. Remember I have a very bad provider who does not really respects its users, and like to squash a user here and there a little occasionally... But, alright, here follows the report on the memory, requested by minipli. I will only need to fill in these, the top right corner of the screen: in some 5 different times that I took (some are a little approximative: while I was copying, the numbers would change). ( showing the successful or failing result. So... And the final screen is... There... Those call traces were, apparently. not caused by bad memory. Unless I'm missing something, in which case, pls. do tell, @minipli, @HacKurx, other kind and knowledgeable reader. |
|
Let me reply to this part of #13 (comment)
Because apparently, same "unable to handle kernel paging request at " can be found also in that now justly closed issue (my fault: mixing different bugs, sorry!) also, as minipli already referenced it, at: I'm not online all the time. And I always first start my https://github.com/miroR/uncenz program first, so I have all the traces (but alas, not enough time to study them, and also they are local traces).... |
|
Nothing in particular was going on in the system, IIRC, this is the regular cron last lines before the crash: But then in less than two more minutes, I try to run mplayer on a recorded video, the screen goes blank, black actually: and the trace happens: This is just the reboot: |
|
In the comment further up in this issue: I have, relatively recently figured out what I today explained in the comment to @HacKurx 's pull at: And let me bring the old suspicion that verified --but in the way I forgot to consider at the fime of my checking of the memory with memtest86+ above in this issue... This was correct. @minipli wrote in #13 (comment):
Actually this particular suspicion was very very true:
Only it wasn't the memory, but the stupid cooling paste... Aarrrggh! |
|
Can you reproduce this with kernel 4.18? And as I repeat "Sorry but you can't expect us to solve your problems because we have more important things to solve." With kind regards, Loic |
|
@HacKurx wrote in reply to me (my comment immediately previous to there):
No, I'm not trying to ask for help! And to me, reporting what goes wrong is an obbligation in FOSS, not something to not do... I was trying to explain that the picture is not as bad as all the bugs/attacks/failing hardware/something-else tended to paint it... @HacKurx wrote also:
I can try and find time, and install 4.18... But gimme more time, I'm working all the time... Unfortunately, not all the time that I would want to have can I dedicate to grsec... However much that I find it still, even incomplete as we currently have in deppersec, one of the best things in GNU/Linux... I can try... This is not a promise to do it, but a strong desire and a promise to try to do it... Pls. tell me, is there anything ready to try out from minipli or your? Just to test, no code perusal (at this time) from me. |
|
@HacKurx: Would testing it with the Devuan/Debian stock kernel: |
No news from Minipli so I can't speak for him. Dapperlinux is to be followed with interest indeed ;) |
Nov 25 06:15:10 gdOv kernel: [ 6127.027227] BUG: unable to handle kernel paging request at ffffffbfa02c6430
Nov 25 06:15:10 gdOv kernel: [ 6127.029802] IP: [] __fput+0xbf/0x220
Nov 25 06:15:10 gdOv kernel: [ 6127.031149] PGD 1bec067
Nov 25 06:15:10 gdOv kernel: [ 6127.031161] PUD 0
Nov 25 06:15:10 gdOv kernel: [ 6127.032506]
Nov 25 06:15:10 gdOv kernel: [ 6127.033855] Oops: 0000 [#1] SMP
Nov 25 06:15:10 gdOv kernel: [ 6127.035216] Modules linked in: nfnetlink_queue nfnetlink_log nfnetlink bluetooth rfkill 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 videobuf2_dvb dvb_core wm8775 ir_rc5_decoder ir_lirc_codec lirc_dev rc_hauppauge tuner_simple tuner_types tda9887 tda8290 tuner edac_mce_amd edac_core kvm_amd cx88_alsa cx8800 cx8802 kvm cx88xx videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 tveeprom v4l2_common mxm_wmi videobuf2_core irqbypass amdkfd evdev videodev radeon pcspkr k10temp serio_raw media snd_hda_codec_realtek snd_hda_codec_generic ttm drm_kms_helper snd_hda_intel drm i2c_algo_bit sp5100_tco fb_sys_fops nuvoton_cir
Nov 25 06:15:10 gdOv kernel: [ 6127.041723] rc_core syscopyarea sysfillrect sg sysimgblt snd_hda_codec acpi_cpufreq wmi shpchp snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore button 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 firewire_ohci r8169 firewire_core mii crc_itu_t sky2 pata_atiixp ahci libahci ohci_hcd xhci_pci ehci_pci ehci_hcd xhci_hcd libata i2c_piix4 usbcore scsi_mod fjes
Nov 25 06:15:10 gdOv kernel: [ 6127.049145] CPU: 1 PID: 29962 Comm: tshark Not tainted 4.9.65-unofficial+grsec171124-19 #1
Nov 25 06:15:10 gdOv kernel: [ 6127.051097] 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 06:15:10 gdOv kernel: [ 6127.053120] task: ffff880051d7c5c0 task.stack: ffffc9000da28000
Nov 25 06:15:10 gdOv kernel: [ 6127.055128] RIP: 0010:[] [] __fput+0xbf/0x220
Nov 25 06:15:10 gdOv kernel: [ 6127.057197] RSP: 0018:ffffc9000da2bdc0 EFLAGS: 00010246
Nov 25 06:15:10 gdOv kernel: [ 6127.059245] RAX: ffffffbfa02c63c0 RBX: ffff880085932c00 RCX: 0000000000000001
Nov 25 06:15:10 gdOv kernel: [ 6127.061356] RDX: ffff880085932cd8 RSI: 0000000000000010 RDI: ffff880085932c00
Nov 25 06:15:10 gdOv kernel: [ 6127.063411] RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000
Nov 25 06:15:10 gdOv kernel: [ 6127.065374] R10: ffff880085932c10 R11: 0000000000000000 R12: ffff8801248401e8
Nov 25 06:15:10 gdOv kernel: [ 6127.067307] R13: ffff8803216900a0 R14: ffff8800757447d0 R15: ffff8801248401e8
Nov 25 06:15:10 gdOv kernel: [ 6127.069179] FS: 0000030bfe92aec0(0000) GS:ffff88032fc80000(0000) knlGS:0000000000000000
Nov 25 06:15:10 gdOv kernel: [ 6127.071043] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 25 06:15:10 gdOv kernel: [ 6127.072818] CR2: ffffffbfa02c6430 CR3: 00000000017e5000 CR4: 00000000000006f0
Nov 25 06:15:10 gdOv kernel: [ 6127.074626] Stack:
Nov 25 06:15:10 gdOv kernel: [ 6127.076448] ffff880085932c10 ffff880085932c00 ffff880051d7c5c0 ffffffff828b5df0
Nov 25 06:15:10 gdOv kernel: [ 6127.078290] 0000000000000000 ffff880051d7cd60 ffff880085a0a800 ffffffff81078e54
Nov 25 06:15:10 gdOv kernel: [ 6127.080172] ffff880051d7cd94 ffff880051d7c5c0 ffffc9000da2be68 ffff88031ef82140
Nov 25 06:15:10 gdOv kernel: [ 6127.082044] Call Trace:
Nov 25 06:15:10 gdOv kernel: [ 6127.083915] [] ? task_work_run+0x74/0xa0
Nov 25 06:15:10 gdOv kernel: [ 6127.085843] [] ? do_exit+0x2f1/0xb80
Nov 25 06:15:10 gdOv kernel: [ 6127.087739] [] ? return_from_SYSCALL_64+0xd/0x73
Nov 25 06:15:10 gdOv kernel: [ 6127.089663] [] ? do_group_exit+0x49/0xb0
Nov 25 06:15:10 gdOv kernel: [ 6127.091527] [] ? sys_exit_group+0xb/0x10
Nov 25 06:15:10 gdOv kernel: [ 6127.093367] [] ? entry_SYSCALL_64_fastpath+0x17/0xa8
Nov 25 06:15:10 gdOv kernel: [ 6127.095141] Code: d8 00 00 00 48 39 c2 0f 85 13 01 00 00 48 89 df e8 47 36 05 00 f6 43 41 20 0f 85 1b 01 00 00 48 89 df e8 b5 92 0a 00 48 8b 43 28 <48> 8b 40 70 48 85 c0 74 08 48 89 de 4c 89 e7 ff d0 48 89 df e8
Nov 25 06:15:10 gdOv kernel: [ 6127.098876] RIP [] __fput+0xbf/0x220
Nov 25 06:15:10 gdOv kernel: [ 6127.100696] RSP
Nov 25 06:15:10 gdOv kernel: [ 6127.102533] CR2: ffffffbfa02c6430
Nov 25 06:15:10 gdOv kernel: [ 6127.112137] ---[ end trace 0d9c001ca28ee136 ]---
Nov 25 06:15:10 gdOv kernel: [ 6127.112139] grsec: banning user with uid 1000 until system restart for suspicious kernel crash
Nov 25 06:15:10 gdOv kernel: [ 6127.112351] Fixing recursive fault but reboot is needed!
The text was updated successfully, but these errors were encountered: