linux.kmsg.Kmsg returning Page error about volatility3 HOT 24 CLOSED

@eve-mem Wow thanks for this amazing report 👏

Ok, let's work in your PR.
Please, update the code as you said, using context.object. Also, please replace contexts.Module.create with the following lines before someone takes it as an example.

diff --git a/volatility3/framework/plugins/linux/kmsg.py b/volatility3/framework/plugins/linux/kmsg.py
index 3f7345bd..548bbdc9 100644
--- a/volatility3/framework/plugins/linux/kmsg.py
+++ b/volatility3/framework/plugins/linux/kmsg.py
@@ -64,10 +64,8 @@ class ABCKmsg(ABC):
     ):
         self._context = context
         self._config = config
-        vmlinux = context.modules[self._config["kernel"]]
-        self.layer_name = vmlinux.layer_name  # type: ignore
-        symbol_table_name = vmlinux.symbol_table_name  # type: ignore
-        self.vmlinux = contexts.Module.create(context, symbol_table_name, self.layer_name, 0)  # type: ignore
+        self.vmlinux = context.modules[self._config["kernel"]]
+        self.layer_name = self.vmlinux.layer_name  # type: ignore
         self.long_unsigned_int_size = self.vmlinux.get_type("long unsigned int").size

If you change that and works in both, kaslr/nokaslr kernels, and after the @ikelos approval, I think we are ready to merge your PR.
Then, we just have to wait for the d2j bug to get fixed, and it should work everywhere.

Thanks again to both @eve-mem and @4n6-fl for reporting this bug

from volatility3.

Hmmmm, I don't think so, we could put more friendly warning messages around

File "/home/nfsuper/volatility/volatility3/framework/plugins/linux/kmsg.py", line 357, in run
ringbuffers = self.vmlinux.object_from_symbol(symbol_name="prb").dereference()

to catch it more gracefully, but otherwise it looks like a straight up null pointer dereference. More than that you'll need to chat to the linux guys...

from volatility3.

@4n6-fl - if it helps at all I've made a branch on my fork here with the changes. https://github.com/eve-mem/volatility3/tree/linux_kmsg_issue_1055

It's just these changes which might be easier to see here: 831e6cf

I don't think this is the final fix for the issue, more testing will be needed, but I'm interested to know if this fixes the page fault with your sample.

from volatility3.

Hey @eve-mem thank you very much for your time.. great great job! very impressive!
I'm following your progress on this. It is just I wanted to find some time to have a look at it and give you a more accurate answer.

On the one hand, regarding vmlinux, I actually not sure why I wrote those lines like that :) ... I tested it and it should be enough with just doing what's below.

diff --git a/volatility3/framework/plugins/linux/kmsg.py b/volatility3/framework/plugins/linux/kmsg.py
index 3f7345bd..548bbdc9 100644
--- a/volatility3/framework/plugins/linux/kmsg.py
+++ b/volatility3/framework/plugins/linux/kmsg.py
@@ -64,10 +64,8 @@ class ABCKmsg(ABC):
     ):
         self._context = context
         self._config = config
-        vmlinux = context.modules[self._config["kernel"]]
-        self.layer_name = vmlinux.layer_name  # type: ignore
-        symbol_table_name = vmlinux.symbol_table_name  # type: ignore
-        self.vmlinux = contexts.Module.create(context, symbol_table_name, self.layer_name, 0)  # type: ignore
+        self.vmlinux = context.modules[self._config["kernel"]]
+        self.layer_name = self.vmlinux.layer_name  # type: ignore
         self.long_unsigned_int_size = self.vmlinux.get_type("long unsigned int").size

In my tests, that works in all previous kernels, so it's better to make it simpler.

On the other hand, I'm not convinced about the absolute=True.
What doesn't make sense to me is that without theabsolute=True it works with older kernels. So, something should have changed. I still cannot find what's that... Everything looks the same in the kernel but there must be something we are not seeing yet.
I want to debug the kernel to double check that. I will probably do that tomorrow and I will let you know.

On a related note, I faced this dwarf2json bug with newer kernels. I wonder if you didn't have the same issue when you tested it.
I'm concerned if the fact that the dwarf info in vmlinux is now using Dwarf v5 could be the cause of something else, apart from the bitfields.

from volatility3.

Hi @4n6-fl thanks for reporting this.
In the meantime, and for better clarity, could you please update the description and replace "linux.iomem.IOMem" with "linux.kmsg.Kmsg".
Cheers

from volatility3.

Hi there,
I tried the solution @gcmoreira offered, but unfortunately it got the same error as before.
@eve-mem after pushing the changes you suggested I get the following error:
Traceback (most recent call last):
File "/home/nfsuper/volatility/./vol.py", line 10, in
volatility3.cli.main()
File "/home/nfsuper/volatility/volatility3/cli/init.py", line 790, in main
CommandLine().run()
File "/home/nfsuper/volatility/volatility3/cli/init.py", line 447, in run
renderersargs.renderer.render(constructed.run())
File "/home/nfsuper/volatility/volatility3/cli/text_renderer.py", line 193, in render
grid.populate(visitor, outfd)
File "/home/nfsuper/volatility/volatility3/framework/renderers/init.py", line 241, in populate
for level, item in self._generator:
File "/home/nfsuper/volatility/volatility3/framework/plugins/linux/kmsg.py", line 427, in _generator
for values in ABCKmsg.run_all(context=self.context, config=self.config):
File "/home/nfsuper/volatility/volatility3/framework/plugins/linux/kmsg.py", line 110, in run_all
yield from kmsg_inst.run()
File "/home/nfsuper/volatility/volatility3/framework/plugins/linux/kmsg.py", line 396, in run
facility, level, timestamp, caller = self.get_prefix(info)
File "/home/nfsuper/volatility/volatility3/framework/plugins/linux/kmsg.py", line 169, in get_prefix
obj.level,
File "/home/nfsuper/volatility/volatility3/framework/objects/init.py", line 960, in getattr
member = template(context=self._context, object_info=object_info)
File "/home/nfsuper/volatility/volatility3/framework/objects/templates.py", line 96, in call
return self.vol.object_class(
File "/home/nfsuper/volatility/volatility3/framework/objects/init.py", line 521, in new
return int.new(cls, ((value & ((1 << end_bit) - 1)) >> start_bit)) # type: ignore
ValueError: negative shift count

might be related to previous changes I did ?

from volatility3.

@4n6-fl that's because this bug in dwarf2json .

What I proposed won't fix this issue. It was related to one of the changes @eve-mem suggested.

from volatility3.

Hey @gcmoreira,

I didn't get the volatilityfoundation/dwarf2json#49 issue - happy to share the ISF with you, what's the best way? It is a kernel I complied myself, my guess would be it's v4 still due to my set up. I need to restore the VMs from backup but when that's done I can share the full vmlinux with you if it's helpful.

With check_syscall it's okay, I get results.

$ python vol.py -f v6.1.15.dmp -r pretty linux.check_syscall
Volatility 3 Framework 2.5.2
Formatting...0.00               Stacking attempts finished
  |  Table Address | Table Name | Index | Handler Address |                           Handler Symbol
* | 0xffff81e002e0 |      64bit |     0 |  0xffff8890bff0 |                           __x64_sys_read
* | 0xffff81e002e0 |      64bit |     1 |  0xffff8890c100 |                          __x64_sys_write
* | 0xffff81e002e0 |      64bit |     2 |  0xffff889090b0 |                           __x64_sys_open
* | 0xffff81e002e0 |      64bit |     3 |  0xffff88906880 |                          __x64_sys_close
* | 0xffff81e002e0 |      64bit |     4 |  0xffff88911fe0 |                        __x64_sys_newstat
* | 0xffff81e002e0 |      64bit |     5 |  0xffff88911da0 |                       __x64_sys_newfstat
<snip>

The reason that check_syscall is okay is that in _get_table_info it uses vmlinux.get_symbol to get the symbol. That returns the address without any KASLR shift applied.

Then later when the object is made the shift gets applied and now it's the correct location.

I think when you make objects with the address from the symbols you don't need absolute=True, it's only if you pull (or calculate) the address from somewhere in the sample itself do you need the absolute=True - without it the shift is being applied twice - once by the OS when it put the address in memory in the first place and then again by vol later during the analysis.

You can see that with this volshell snippet. The address from get_symbol and address isn't shifted and then when the object is made it is then shifted.

(layer_name) >>> vmlinux = context.modules["kernel"]
(layer_name) >>> vmlinux.get_symbol('sys_call_table').address
281472860685024
(layer_name) >>> vmlinux.get_absolute_symbol_address('sys_call_table') 
281472984416992
(layer_name) >>> sys_call_table_obj = vmlinux.object_from_symbol(symbol_name="sys_call_table")
(layer_name) >>> sys_call_table_obj.vol.offset
281472984416992

For walk_internal_list I can't test it with my current sample, the head for keyboard_notifier_list is just null for me. I don't know enough about it to know if that's normal - but it stops me digging into it. Hopefully in my other samples I can find one that does.

(layer_name) >>> vmlinux = context.modules["kernel"]
(layer_name) >>> knl_addr = vmlinux.object_from_symbol("keyboard_notifier_list")
(layer_name) >>> knl = vmlinux.object(
...             object_type="atomic_notifier_head",
...             offset=knl_addr.vol.offset,
...             absolute=True,
...         )
(layer_name) >>> dt(knl)    
symbol_table_name1!atomic_notifier_head (16 bytes)
 0x0 :   lock     symbol_table_name1!spinlock     0xffff8a001900
 0x8 :   head     symbol_table_name1!pointer      0

However in this case it's dealing with pointers that come from memory so I would expect that absolute=True is needed. You can see even in the keyboard_notifiers plugin itself that knl is being made using the actual offset of knl_addr so the absolute=True is used.

I think you could swap it around like this for the same effect without needing to make that knl_addr object.

diff --git a/volatility3/framework/plugins/linux/keyboard_notifiers.py b/volatility3/framework/plugins/linux/keyboard_notifiers.py
index 72273a77..78ffd3e6 100644
--- a/volatility3/framework/plugins/linux/keyboard_notifiers.py
+++ b/volatility3/framework/plugins/linux/keyboard_notifiers.py
@@ -44,7 +44,7 @@ class Keyboard_notifiers(interfaces.plugins.PluginInterface):
         )

         try:
-            knl_addr = vmlinux.object_from_symbol("keyboard_notifier_list")
+            knl_addr = vmlinux.get_absolute_symbol_address("keyboard_notifier_list")
         except exceptions.SymbolError:
             knl_addr = None

@@ -57,7 +57,7 @@ class Keyboard_notifiers(interfaces.plugins.PluginInterface):

         knl = vmlinux.object(
             object_type="atomic_notifier_head",
-            offset=knl_addr.vol.offset,
+            offset=knl_addr,
             absolute=True,
         )

I can't properly check the check_afinfo plugin with my sample as it's too new. E.g. the same as #1052 and #832.

However I think it's the same boat as check_syscall . It uses get_symbol to get the symbol with no KASLR and then makes the object without absolute=True, therefore the shift is then applied so the object is in the right place.

I need to get my VM restored so I have a few more samples to work from. I'd love to be able to look into Keyboard notifiers and check afinfo more.

I'm happy to test and try anything else you had in mind, just let me know how I can help.

In my view to fix the issue for @4n6-fl we need to update kmsg to have the objects made in the right place and also fix the volatilityfoundation/dwarf2json#49 problem. (and right now it feels like volatilityfoundation/dwarf2json#49 is the bigger more wider problem)

from volatility3.

Hi @gcmoreira to answer you question above, the Check_syscall plugin works without any error, the linux.check_afinfo does not work, I did open a bug report for it but we just concluded that the kernel version was not supported.

from volatility3.

Your changes in #1061 looks good.

Regarding older kernels, please submit a different issue so that we can review that separately.

Re: your ISF profile. The reason why you didn't get volatilityfoundation/dwarf2json#49 is because you compiled the kernel with a GNU CC version older than the one Ubuntu uses for compiling the kernel. So, the Dwarf version generated by your CC is < 5, probably Dwarf 2, while newer GNU CC generates Dwarf 5 debug info.

from volatility3.

That makes a lot of sense, I'd installed the oldest version of Debian i could and then tried making kernels until it wouldn't work anymore. Thanks!

from volatility3.

Hi @4n6-fl

Thank you for continuing to submit issues - it is extremely helpful!

Your error is hitting the very first part of the code to try and get to the buffer: https://github.com/volatilityfoundation/volatility3/blob/develop/volatility3/framework/plugins/linux/kmsg.py#L357

However it looks like it can't be read so you won't be able to get any results. (I imagine other plugins, pslist etc work etc, rather than a core problem with the memory dump).

That all being said you're memory dump is from a fairly recent Linux kernel:
Linux version 6.2.0-1013-aws (buildd@bos03-amd64-006) (x86_64-linux-gnu-gcc-11 (Ubuntu 11.4.0-1ubuntu122.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) 1322.04.1-Ubuntu SMP Fri Sep 8 17:29:56 UTC 2023 (Ubuntu 6.2.0-1013.1322.04.1-aws 6.2.16)

It may be the case that the buffers etc have moved around since 5.10 (what the plugin is targeting) and 6.2.16 (your sample). If that's true then we can (hopefully) update the plugin and you might be in luck. I'll need to have a quick look over the changes in the kernel to see if that has happened. (Equally one of the core devs might already know the answer as they tend to know most things... paging @ikelos as generally knowledgeable about all things, and @atcuno and @gcmoreira for their huge Linux knowledge.)

If nothing else we can update the plugin to give a helpful error message if indeed the prb symbol is actually not readable.

from volatility3.

A very quick check of a few modern samples I have and I hit the same error in mine so I can recreate it, which makes it easier to look into.

from volatility3.

Yes - at the very least a nicer warning would be useful. I'm hoping that there are changes in the kernel which means we can update the plugin to support them.

from volatility3.

hiya @4n6-fl - could you try this patch and see if it works for you? It's just changing a few lines and it seems to have fixed the issue on my sample.

I can make a branch on my fork if it's easier.

I don't think anything changed in the kernel. I think there was a problem with when the vmlinux module was being added, the offset wasn't being copied over, and then later a few objects were getting made with absolute addresses, but the absolute flag wasn't set. I've not tested to see if this breaks older samples (I'd hope not) but if this fixes your problem I can dig into it more and test

diff --git a/volatility3/framework/plugins/linux/kmsg.py b/volatility3/framework/plugins/linux/kmsg.py        
index 3f7345bd..cf9d8b8a 100644
--- a/volatility3/framework/plugins/linux/kmsg.py
+++ b/volatility3/framework/plugins/linux/kmsg.py
@@ -67,7 +67,9 @@ class ABCKmsg(ABC):
         vmlinux = context.modules[self._config["kernel"]]
         self.layer_name = vmlinux.layer_name  # type: ignore
         symbol_table_name = vmlinux.symbol_table_name  # type: ignore
-        self.vmlinux = contexts.Module.create(context, symbol_table_name, self.layer_name, 0)  # type: ignore
+        self.vmlinux = contexts.Module.create(
+            context, symbol_table_name, self.layer_name, vmlinux.offset
+        )  # type: ignore
         self.long_unsigned_int_size = self.vmlinux.get_type("long unsigned int").size

     @classmethod
@@ -365,12 +367,14 @@ class KmsgFiveTen(ABCKmsg):
             offset=desc_ring.descs,
             subtype=self.vmlinux.get_type("prb_desc"),
             count=desc_count,
+            absolute=True,
         )
         info_arr = self.vmlinux.object(
             object_type="array",
             offset=desc_ring.infos,
             subtype=self.vmlinux.get_type("printk_info"),
             count=desc_count,
+            absolute=True,
         )

         # See kernel/printk/printk_ringbuffer.h

Edit to show the output.

Before:

$ python vol.py -f v6.1.15.dmp linux.kmsg
Volatility 3 Framework 2.5.2
Progress:  100.00               Stacking attempts finished
facility        level   timestamp       caller  line


Volatility was unable to read a requested page:
Page error 0xffff82253380 in layer layer_name (Page Fault at entry 0x0 in table page table)

        * Memory smear during acquisition (try re-acquiring if possible)
        * An intentionally invalid page lookup (operating system protection)
        * A bug in the plugin/volatility3 (re-run with -vvv and file a bug)

No further results will be produced

After:

$ python vol.py -f v6.1.15.dmp linux.kmsg
Volatility 3 Framework 2.5.2
Progress:  100.00               Stacking attempts finished
facility        level   timestamp       caller  line

kern    notice  0.000000        Task(0) Linux version 6.1.15-vol (root@deb10) (gcc (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP PREEMPT_DYNAMIC Sat Mar 11 14:59:42 EST 2023
kern    info    0.000000        Task(0) Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.15-vol root=UUID=c46e3962-8fa4-4620-af46-dfff4bb49610 ro quiet splash resume=UUID=9ede18ae-c5a0-4e05-992b-04786c06c80e
kern    info    0.000000        Task(0) x86/fpu: x87 FPU will use FXSAVE
kern    info    0.000000        Task(0) signal: max sigframe size: 1440
kern    info    0.000000        Task(0) BIOS-provided physical RAM map:
kern    info    0.000000        Task(0) BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
kern    info    0.000000        Task(0) BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
kern    info    0.000000        Task(0) BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
kern    info    0.000000        Task(0) BIOS-e820: [mem 0x0000000000100000-0x00000000bffd9fff] usable
kern    info    0.000000        Task(0) BIOS-e820: [mem 0x00000000bffda000-0x00000000bfffffff] reserved
kern    info    0.000000        Task(0) BIOS-e820: [mem 0x00000000feffc000-0x00000000feffffff] reserved
kern    info    0.000000        Task(0) BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved
kern    info    0.000000        Task(0) BIOS-e820: [mem 0x0000000100000000-0x000000013fffffff] usable
kern    info    0.000000        Task(0) NX (Execute Disable) protection: active
kern    info    0.000000        Task(0) SMBIOS 2.8 present.
kern    info    0.000000        Task(0) DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
kern    info    0.000000        Task(0) Hypervisor detected: KVM
kern    info    0.000000        Task(0) kvm-clock: Using msrs 4b564d01 and 4b564d00
kern    info    0.000001        Task(0) kvm-clock: using sched offset of 118876718327327 cycles
kern    info    0.000006        Task(0) clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
kern    info    0.000012        Task(0) tsc: Detected 2099.998 MHz processor
<SNIP>

from volatility3.

@gcmoreira thanks for taking a look and giving your advice. I did think it was odd it made a whole new vmlinux. My first little fix when testing was doing exactly that, just grabbing the existing one as you've done there.

For me with older kernels I'd have it work fine without the absolute flag, but I thought that was because there was no shifting happening, so absolute or not it goes to the same address. I've been caught out in the past with absolute addresses in the past basically where taking an address from something actually running then always needed to be absolute or it'll get shifted.

Not sure exactly with this one - need to do more testing.

Thanks again for taking a look.

It does look like @4n6-fl unlocks the next issue with the symbols however, so either way it's not fixed yet.

from volatility3.

@gcmoreira - here's an example to show you want I mean re the absolute=True side of things.

Try running through these set in volshell on a few of your samples. Any that have a vmlinux.offset of 0 won't show any difference, but where there is an offset the object made without the absolute=True will be in the wrong place, and be referencing some random address.

# grab vmlinux
vmlinux = context.modules["kernel"]
# show vmlinux ofset
vmlinux.offset
# get offset for the first task
task_offset = ps()[0].vol.offset
# build a task using that offset, don't set absolute
task = vmlinux.object(object_type="task_struct", offset=task_offset)
# build a task using that offset, do set absolute
abs_task = vmlinux.object(object_type="task_struct", offset=task_offset, absolute=True)
# show the offset of where the non absolute object has been made
task.vol.offset
# show the offset of where the absolute object has been made
abs_task.vol.offset
# does the non absolute object match the true object?
task.vol.offset == ps()[0].vol.offset
# does the absolute object match the true object?
abs_task.vol.offset == ps()[0].vol.offset
task.tgid
abs_task.tgid

Here is a sample with no shifting, and you can see it's all fine:

(layer_name) >>> vmlinux = context.modules["kernel"]
(layer_name) >>> vmlinux.offset
0
(layer_name) >>> task_offset = ps()[0].vol.offset
(layer_name) >>> task = vmlinux.object(object_type="task_struct", offset=task_offset)
(layer_name) >>> abs_task = vmlinux.object(object_type="task_struct", offset=task_offset, absolute=True)
(layer_name) >>> task.vol.offset
149534111516480
(layer_name) >>> abs_task.vol.offset
149534111516480
(layer_name) >>> task.vol.offset == ps()[0].vol.offset
True
(layer_name) >>> abs_task.vol.offset == ps()[0].vol.offset
True
(layer_name) >>> task.tgid
1
(layer_name) >>> abs_task.tgid
1

Where here there is an offset and you can see that without the absolute it's all wrong.

(layer_name) >>> vmlinux = context.modules["kernel"]
(layer_name) >>> vmlinux.offset
123731968
(layer_name) >>> task_offset = ps()[0].vol.offset
(layer_name) >>> task = vmlinux.object(object_type="task_struct", offset=task_offset)
(layer_name) >>> abs_task = vmlinux.object(object_type="task_struct", offset=task_offset, absolute=True)
(layer_name) >>> task.vol.offset
154723101822656
(layer_name) >>> abs_task.vol.offset
154722978090688
(layer_name) >>> task.vol.offset == ps()[0].vol.offset
False
(layer_name) >>> abs_task.vol.offset == ps()[0].vol.offset
True
(layer_name) >>> task.tgid
0
(layer_name) >>> abs_task.tgid
1

from volatility3.

Hey @eve-mem
I see,very interesting, so... as far as I understand what you are saying is that's related to KASLR, right?

In that case, there are other plugins that might be affected as well. These are the ones I found, but there may be more:

• Check_afinfo plugin

• Check_syscall plugin

• LinuxUtilities::walk_internal_list which is only called from the Keyboard_notifiers plugin

Could you (@4n6-fl or @eve-mem ) please confirm that we have the same issue also with some/all of those plugins?

On the other hand, could you (@eve-mem) provide which dwarf2json version you used in that successful output you showed above and if it's possible send your ISF to me?
I'm assuming, for some reason, you didn't have issues with dwarf2json/issues/49, right?

from volatility3.

I forgot to add - I messaged @ikelos a little about making objects, to check I was thinking about it in the right way. He pointed out that it's probably best in some's cases to make objects via the context rather than the module.

e.g. like this in the elf plugin:

That method probably makes the most sense here too, and then we don't have to worry about absolute or not? I'd imagine in most cases where the absolute=True is actually needed - I'd probably be better off using the context instead. Am I thinking about that in the right way?

Let me know if I'm not making sense - and thanks once again to all of you for your kind help and support with this all.

from volatility3.

I forgot to add - I messaged @ikelos a little about making objects, to check I was thinking about it in the right way. He pointed out that it's probably best in some's cases to make objects via the context rather than the module.

@eve-mem Yeah, I also noticed that some plugins use context.object. If that function handles both cases, kaslr/nokaslr, and is less error-prone, we should definitely opt for that instead.

from volatility3.

I didn't get the volatilityfoundation/dwarf2json#49 issue - happy to share the ISF with you, what's the best way? It is a kernel I complied myself, my guess would be it's v4 still due to my set up. I need to restore the VMs from backup but when that's done I can share the full vmlinux with you if it's helpful.

Thanks @eve-mem I only need the ISF, please attach it to this ticket in a compressed file.

from volatility3.

I'll try and give it a look over later this week or on Sunday...

from volatility3.

I'll get on those changes and make a PR. Thanks for all of the advice.

from volatility3.

Hello @gcmoreira - I've made a draft PR here with those changes. It works on my sample now. Let me know what you think it - hopefully it's what you had in mind. If you think it's okay I can mark it as ready.

In my testing my changes with older kernels I found that kmsg would not work on an older sample using the current develop branch (e.g. the changes in #1061 don't cause the problem, it was already that way). Which is related but a different issue to this one. Would a new issue be useful, or would it be better to fix both in one go? I think I have some ideas on how go about fixing that.

$ python vol.py -f linux-sample-1.dmp banners
Volatility 3 Framework 2.5.2
Progress:  100.00               PDB scanning finished
Offset  Banner

0x1400070       Linux version 3.2.0-4-amd64 ([email protected]) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.57-3+deb7u2

$ python vol.py -f linux-sample-1.dmp linux.kmsg
Volatility 3 Framework 2.5.2
Progress:  100.00               Stacking attempts finished
facility        level   timestamp       caller  line
ERROR    volatility3.plugins.linux.kmsg: Unsupported Netfilter kernel implementation

Lastly here is that ISF you were interested in. I hope it helps: v6.1.15.zip

I can share the actual vmlinux file if you need it.

from volatility3.