Page error in layer layer_name (Page Fault at entry 0x0 in table page table or directory pointer) #1401
Comments
|
|
|
Hi @manuelsteiner thanks for your report. ./dwarf2json linux --elf /usr/lib/debug/lib/modules/4.18.0-477.21.1.el8_8.x86_64/vmlinux > kernel-4.18.0-477.21.1.el8_8.x86_64.json |
|
Hi, thanks for the assistance! Just to make sure I re-created the symbols without the system map. Also the additionally required files (vmsn in this case) are present in the same directory as the vmem. I have attached the symbols file if it is of any help.
|
|
|
|
I've set up a similar Red Hat 8.8 environment. $ uname -r
4.18.0-477.15.1.el8_8.x86_64Your version is ./vol.py \
-f ./rhel-8-8-x64/rhel-8-8-x64-Snapshot1.vmem \
linux.pslist
Volatility 3 Framework 2.12.0
Progress: 100.00 Stacking attempts finished
OFFSET (V) PID TID PPID COMM CREATION TIME File output
0x9d0301320000 1 1 0 systemd 2024-12-16 00:13:53.005000 UTC Disabled
0x9d0301325080 2 2 0 kthreadd 2024-12-16 00:13:53.005000 UTC Disabled
...
0x9d030436d080 1275 1275 1 agetty 2024-12-16 00:14:00.288245 UTC DisabledWould it be possible for you to share the memory dump you used? Since the crash occurs before listing any processes, it's likely that Volatility3 is incorrectly calculating the ASLR shifts in your case. You might also want to try the proposed changes in PR #1332 |
|
Yeah I can share the VM memory of the VM 'i generated the symbols with, the original memory sadly is part of an ongoing investigation... but hopefully that snapshot is good enough. Here is a zip of the vmem and vsmn files: https://drive.proton.me/urls/V8NQAX3098#LxUsWHvrPVfV In the meantime, I can try and install the kernel you used, generate symbols for it and a memory dump just to make sure I'm not doing anything wrong on my end. Because that kernel should be fine, right? Thanks again for all the help, really appreciate it. |
|
Ok, so I have recreated the memory dumps for the This leads me to believe the memory dump of the original VM I am trying to analyse is indeed corrupt, sadly. |
|
No problem! Let me know if you have better luck. It doesn't appear to be an issue with the framework, but we're happy to assist in making sure everything's done correctly. That said, it might be more efficient to continue this discussion on Slack and close this ticket here. TA. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Hi, I am trying to analyse a Red Hat Enterprise Linux 8.8 memory dump. The dump is in
vmemformat from a VMware virtual machine. I made sure to create the necessary symbols on an identical kernel version albeit on a fresh install of the same Red Hat version.When trying various
linux.plugins, such aslinux.pslistorlinux.psaux, page errors happen. To verify that the generated symbols aren't at fault, I also ran the same plugins on a memory dump created from a a snapshot of the exact machine I created the symbols on (also VMware virtual environment).The difference is that whilst processing the memory from the exact VM on which the symbols were created, at least a few processes show up whilst when trying to analyse the original VM memory, no processes show up.
There is also a difference with the exact error thrown. On the original memory dump, the error is
Page error 0x99dd40bc0904 in layer layer_name (Page Fault at entry 0x0 in table page table), while on the memory dump from the VM on which the symbols were created, it isPage error 0x104 in layer layer_name (Page Fault at entry 0x0 in table page directory pointer).I am not sure if this is still a symbols issue or if volatility is looking to access addresses not available in memory or something else. The symbols are picked up and are banner-matched as far as I can tell.
Any help would be greatly appreciated. Thank you.
Context
Volatility Version: 2.7.0
Operating System: REMnux (Ubuntu 20.04)
Python Version: 3,8.10
Suspected Operating System: Red Hat Enterprise Linux
Command: see example outputs
To Reproduce
Generate the symbols on the Red Hat Linux Enterprise VM.
Example output
linux.psliston the original memory dumpThe text was updated successfully, but these errors were encountered: