Indeed however that appears to have very recently changed TrueNAS Software Status | TrueNAS Documentation Hub
I wonder if the TrueNAS Team could use the ‘Announcements’ section to alert the community when a version reaches ‘Mission Critical’ status as that would be very helpful?
Looks like another similar one, dubbed DirtyFrag. another set of modules to block.
I’ve been patiently waiting for the TrueNas software status page to tell me to upgrade from my current 25.04.2.6 to 25.10.3[.1] (I’m extremely conservative, not wanting to bust things and then having to spend hours repairing it by methods I don’t really understand).
I noticed that the advice for me was to upgrade now and hence take care of this vulnerability. Last night I completed the upgrade, then found my GPU wasn’t working, so downgraded, found it was still broken, vaguely remembered something to do with UUIDs from a year ago, tried to run the commands I found (they didn’t work), rebooted into the newer kernel, tried again (they didn’t work) then found that the API had changed and I needed to use -j rather than -job and then I worked through this.
Having had to spend hours repairing this bust system using methods I didn’t really understand, my temper was thus worsened when I realised it was my fault because I had assumed that the enterprise ready upgrade would work with all of my hardware, not realising that my Nvidia card is now out of date.
So - I hope that a minor point backport or whatever it is called will be released because I am now “stuck” on 25.04.2.6 until such a time as I can afford a new graphics card. But, thanks to @Lycestra I was able to implement that local fix and I have done an init script (with help from AI to explain where to find it and implement it) which will keep me “safe” when I occasionally reboot even if TN don’t up-issue.
edit, after several days of reading:
and
and
so if I can summon up the courage, it appears that there’s a way for me to upgrade TN to the latest version whilst maintaining compatibility with older Nvidia drivers (which might include my P620).
I was just looking in to the system.advanced.update method to add kernel parameters, and it should work great in a vacuum, but reality can suck worse.
Calling it as given clobbers whatever kernel_extra_options already exist on the system, so it should be a good practice to check using midclt call system.advanced.config first to see if it’s already blank or not. additionally, if the initcall_blacklist= parameter is already given, I can’t assume you can use it multiple times, as it’s documented to comma-separate the functions you want blocked, so to add more modules, have to check what the list was, and add to it. Also, you must find the name of the init function for the modules to block. not difficult, but also not implicitly the module name plus _init , as shown below for rxrpc module (it looks to be af_rxrpc_init).
my attempts to figure out the init functions of the three listed in the dirtyfrag would result in
midclt call system.advanced.update '{"kernel_extra_options":"initcall_blacklist=algif_aead_init,esp4_init,esp6_init,af_rxrpc_init"}'
and that’s assuming there’s no other kernel_extra_options to be carried in to the command from prior use.
Chiming in, trying to be helpful, in case users already had other kernel parameters vital their continued sanity.
As I write this, version 25.10.3.1 is available for installation as a stable release.
Fortunately, I haven’t encountered any display issues.
The installation went smoothly.
