vma_wants_writenotify general protection fault #18
Comments
|
What did you do to trigger this? Can you reproduce this on vanilla? |
|
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
|
theLOICofFRANCE
pushed a commit
to theLOICofFRANCE/linux-unofficial_grsec
that referenced
this issue
Apr 26, 2020
commit e39d200fa5bf5b94a0948db0dae44c1b73b84a56 upstream. Reported by syzkaller: BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm] Read of size 8 at addr ffff8803259df7f8 by task syz-executor/32298 CPU: 6 PID: 32298 Comm: syz-executor Tainted: G OE 4.15.0-rc2+ minipli#18 Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 02/16/2016 Call Trace: dump_stack+0xab/0xe1 print_address_description+0x6b/0x290 kasan_report+0x28a/0x370 write_mmio+0x11e/0x270 [kvm] emulator_read_write_onepage+0x311/0x600 [kvm] emulator_read_write+0xef/0x240 [kvm] emulator_fix_hypercall+0x105/0x150 [kvm] em_hypercall+0x2b/0x80 [kvm] x86_emulate_insn+0x2b1/0x1640 [kvm] x86_emulate_instruction+0x39a/0xb90 [kvm] handle_exception+0x1b4/0x4d0 [kvm_intel] vcpu_enter_guest+0x15a0/0x2640 [kvm] kvm_arch_vcpu_ioctl_run+0x549/0x7d0 [kvm] kvm_vcpu_ioctl+0x479/0x880 [kvm] do_vfs_ioctl+0x142/0x9a0 SyS_ioctl+0x74/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The path of patched vmmcall will patch 3 bytes opcode 0F 01 C1(vmcall) to the guest memory, however, write_mmio tracepoint always prints 8 bytes through *(u64 *)val since kvm splits the mmio access into 8 bytes. This leaks 5 bytes from the kernel stack (CVE-2017-17741). This patch fixes it by just accessing the bytes which we operate on. Before patch: syz-executor-5567 [007] .... 51370.561696: kvm_mmio: mmio write len 3 gpa 0x10 val 0x1ffff10077c1010f After patch: syz-executor-13416 [002] .... 51302.299573: kvm_mmio: mmio write len 3 gpa 0x10 val 0xc1010f Reported-by: Dmitry Vyukov <[email protected]> Reviewed-by: Darren Kenny <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Tested-by: Marc Zyngier <[email protected]> Cc: Paolo Bonzini <[email protected]> Cc: Radim Krčmář <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Christoffer Dall <[email protected]> Signed-off-by: Wanpeng Li <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: