You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bleeding Edge Kernel versions drop module_sect_attr #1761
This is a struct we currently rely on to extract kernel modules. This structure has been there since the beginning of the kernel but was removed with this commit:
A slack user reported the bug from a preview/bleeding edge Ubuntu kernel, so this will hit mainstream kernels soon enough. I will investigate this week so its fixed for parity.
I hate to say it, but this is a new feature ("support recent kernels") rather than a fix for something that currently works incorrectly, and I don't think it's enough to break the code freeze. It doesn't yet affect mainstream kernels (you said it was bleeding edge), the existing code isn't broken it just can't handle all cases at the moment (which will always be the case in a moving world) and we have to cut at some point. Feel free to get it fixed in develop, and it'll get released in July or August, whenever our next release is due to be rolled.
The updated method for module attributes (the reason for this ticket) is in released Ubuntu preview kernels now, which means over the next couple weeks they will go into stable kernels being used in production. It is also not a silent issue, it fully backtraces all of Vol3 for any Linux analysis as we set the extension for module_sect_attr on load. So even running something like linux.pslist on the kernel (unrelated to module extraction) on an affected symbol table will backtrace the whole framework. This is a bug fix type ticket which is supposed to be the purpose of the gap time between now and the parity release. It really does need to be fixed for parity.
Well, I'll take a look at the PR once it comes out to see how invasive it is, but targetting a fix for something that comes out in two weeks, is still pre-empting the future, so I'm absolutely middle of the line on this and it could go either way...
Yes, but two weeks from now is during the bug release period. Also, that would put 2-3 months of Linux analysis on up to date kernels backtracking and we just be telling people to use devleop for 2 months instead of the release.
Also, we do use the optional classes correctly, and it is good we didn't use it here as its a core data structure that hasn't changed since ~15 years - but of course it gets changed right before release. It would be like EPROCESS suddenly disappearing on Windows.
Ok, I'm glad we chose the right type for the structure, and yes, it's very disappointing they decided to make that change now.
As I said, I take a look and see how risky a change it is, but we have to balance it against putting in the change and us getting it wrong or missing something and breaking volatility (perhaps for every linux image, not just new ones) which is why I'm not giving you a guaranteed yes, or a guaranteed no now, but we need to see what the patch looks like before we decide whether it's better to include it now or not. The fact that it breaks all linux analysis rather than just one plugin does swing things in favour of including it.
So it sounds like the fix would be to make a module_sect_attrs class override, that determines whether it contains the needed classes, and then either processes attrs to yields each of the bin_attributes out of the module_sect_attrs or yields through a direct array of bin_attributes?
I don't think there is a need to tamper with module_sect_attrs, as the attrs array subtype class override (bin_attribute or module_sect_attr) will already handle members checking. This makes it transparent to get_name() callers, like here (because this one does not hardcode module_sect_attr in the subtype):
Activity
ikelos commentedon Apr 8, 2025
I hate to say it, but this is a new feature ("support recent kernels") rather than a fix for something that currently works incorrectly, and I don't think it's enough to break the code freeze. It doesn't yet affect mainstream kernels (you said it was bleeding edge), the existing code isn't broken it just can't handle all cases at the moment (which will always be the case in a moving world) and we have to cut at some point. Feel free to get it fixed in develop, and it'll get released in July or August, whenever our next release is due to be rolled.
ikelos commentedon Apr 8, 2025
It's not a parity release issue since I'm pretty sure volatility 2 will not handle this case.
atcuno commentedon Apr 8, 2025
The updated method for module attributes (the reason for this ticket) is in released Ubuntu preview kernels now, which means over the next couple weeks they will go into stable kernels being used in production. It is also not a silent issue, it fully backtraces all of Vol3 for any Linux analysis as we set the extension for
module_sect_attron load. So even running something like linux.pslist on the kernel (unrelated to module extraction) on an affected symbol table will backtrace the whole framework. This is a bug fix type ticket which is supposed to be the purpose of the gap time between now and the parity release. It really does need to be fixed for parity.ikelos commentedon Apr 8, 2025
Well, I'll take a look at the PR once it comes out to see how invasive it is, but targetting a fix for something that comes out in two weeks, is still pre-empting the future, so I'm absolutely middle of the line on this and it could go either way...
ikelos commentedon Apr 8, 2025
(It also proves we need to be careful about whether we add class overrides or optional class overrides when we add extensions).
atcuno commentedon Apr 8, 2025
Yes, but two weeks from now is during the bug release period. Also, that would put 2-3 months of Linux analysis on up to date kernels backtracking and we just be telling people to use devleop for 2 months instead of the release.
Also, we do use the optional classes correctly, and it is good we didn't use it here as its a core data structure that hasn't changed since ~15 years - but of course it gets changed right before release. It would be like EPROCESS suddenly disappearing on Windows.
ikelos commentedon Apr 8, 2025
Ok, I'm glad we chose the right type for the structure, and yes, it's very disappointing they decided to make that change now.
As I said, I take a look and see how risky a change it is, but we have to balance it against putting in the change and us getting it wrong or missing something and breaking volatility (perhaps for every linux image, not just new ones) which is why I'm not giving you a guaranteed yes, or a guaranteed no now, but we need to see what the patch looks like before we decide whether it's better to include it now or not. The fact that it breaks all linux analysis rather than just one plugin does swing things in favour of including it.
Abyss-W4tcher commentedon Apr 8, 2025
Here are my researches towards a fix, if it can help you determine which way to go.
Doc.
At first glance, the only place where we require "module_sect_attr" is in
get_sections(which by the way doesn't seem referenced anywhere?):volatility3/volatility3/framework/symbols/linux/extensions/__init__.py
Lines 211 to 219 in 842d0e7
sect_attrsis of type module_sect_attrsDiff is here:
->
And the now removed module_sect_attr was:
module_sect_attrwas removed because it was indeed only a proxy to abin_attributestructure through itsbattrmember.Fix
module_sect_attroptionalThen add an optional "bin_attribute" class override with a "get_name" method that should basically only need to mimic
volatility3/volatility3/framework/symbols/linux/extensions/__init__.py
Line 3136 in 842d0e7
Abyss-W4tcher commentedon Apr 8, 2025
I'll potentially update the previous comment if I find anything else, so consider this WiP for today.
ikelos commentedon Apr 8, 2025
So it sounds like the fix would be to make a
module_sect_attrsclass override, that determines whether it contains the needed classes, and then either processes attrs to yields each of thebin_attributes out of themodule_sect_attrs or yields through a direct array ofbin_attributes?Abyss-W4tcher commentedon Apr 9, 2025
I don't think there is a need to tamper with
module_sect_attrs, as theattrsarray subtype class override (bin_attributeormodule_sect_attr) will already handle members checking. This makes it transparent toget_name()callers, like here (because this one does not hardcodemodule_sect_attrin the subtype):volatility3/volatility3/framework/symbols/linux/utilities/module_extract.py
Lines 292 to 306 in 842d0e7
I can make a PR with how I think it could be resolved, so that it would a bit clearer of what would move and if it's too risky or not before 2.26.0.
atcuno commentedon Sep 27, 2025
@Abyss-W4tcher is this ready / close to ready?
Merge pull request #1773 from Abyss-W4tcher/issue_1761_module_sect_at…