fix: linux 6.19 taint_flag.module removal - #2009
Conversation
| ): | ||
| if is_module and not taint_flag.module: | ||
| # https://lore.kernel.org/all/20251022082938.26670-1-petr.pavlu@suse.com/T/#u: "taint/module: Remove unnecessary taint_flag.module field" | ||
| if is_module and taint_flag.has_member("module") and not taint_flag.module: |
There was a problem hiding this comment.
Will this flag lots of false positives now, or was the taint_flag.module just a belt and braces check to reduce a few rare false positives?
There was a problem hiding this comment.
In my limited understanding, and based on the lore message, no, it shouldn't produce false positives.
The commit message claims that the per-module flags are always those added to module.taints by calls to add_taint_module().
Cross-checking those calls, they (8) exist inside the following:
Along with a single direct set_bit() in inherit_taint()
The only flags that can reach mod->taints are P F O C E K N all of them already had the .module = true;
Actually, the error ran the other way around; the flags T and J were marked as per-module by mistake, which prompted the removal
d6dc439 to
b32cfa4
Compare
|
While we're at it, fix RANDSTRUCT as well Silly me, marked FWCTL as a per-module... 🤡 |
Linux 6.19 removed the
taint_flag.moduleattribute: https://lore.kernel.org/all/20251022082938.26670-1-petr.pavlu@suse.com/T/#uAs such, when running
linux.lsmodfor a snapshot of linux 6.19+ the whole framework backtraces:Also, update the taint table, and introduce a new taint flag
J:https://docs.kernel.org/admin-guide/tainted-kernels.html#table-for-decoding-tainted-state
Taints continue to appear when running
linux.lsmodon a random snapshot: