-
Notifications
You must be signed in to change notification settings - Fork 480
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing subtype of filp
returned by Lsof
#922
Comments
This issue is stale because it has been open for 200 days with no activity. |
This issue was closed because it has been inactive for 60 days since being marked as stale. |
I'd like to keep this open because I do still want to get to the bottom of it... |
Previously in array_of_pointers we were updating the vol dict for the base pointer type. Now we clone it before modifying it, so we're only interfering with that one type, not any future types. Fixes #922
Hi there, thanks very much for the detailed report and I can only apologize that it's taken us this long to dig into it. It was on our radar, but we didn't communicate that and it didn't have the priority it should have given it was a core issue. You were correct, there was an issue with the way that array_of_pointers was constructing its arrays. It was taking the default pointer type class and updating its subtype (which then affected all subsequent copies of that type, ie, all pointers) whereas it should have cloned it and used only that. I've merged in the appropriate fix as of commit |
Describe the bug
When calling the
list_fds
method of thelsof
plugin the subtype of the returnedfilp
behaves in (at least to me) unexpected ways.According to this snippet
It should always be
symbol_table + constants.BANG + "file"
, i.e.,symbol_table_name1!file
. However, the actual output when running my plugin isi.e., there is a distinct point where it switches - the first time it hits an fd that represents a BPF map. In that case I use the returned file pointer's
private_data
to construct a BpfMap object, which internally does quite a lot of stuff (also involving BTF). However, I would not expect this to change anything in the fd iterator.Context
Volatility Version: a35afd4
Operating System: Kali container on Arch host
Python Version: 3.11.2
Suspected Operating System: self-compiled 6.0.12
Command:
To Reproduce
Steps to reproduce the behavior:
(Note that the project contains a patch to hack around the issue and it gets applied if you use the container)
Expected behavior
To me, the fact that something I do with the
filp
changes the subtype of the iterator for future items is unexpected. I am not familiar enough with your framework or Python to tell if this a mistake on my end, but if it is, I'd like to understand how I can change my code to avoid it.Example output
The text was updated successfully, but these errors were encountered: