Closed vobst closed 11 months ago
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...
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 9f9afbf
. Thank you again for bringing it to our attention and the detailed information you provided.
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 snippetIt 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: a35afd4f343c10d7f8d1df2cb5eec8364c3dbd5a 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:
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