(“Copy Fail”) Mitigation and Remediation Guidance for StorNext Appliances and Clients

SUMMARY 
Quantum has identified that StorNext environments running Linux-based operating systems may be affected by CVE‑2026‑31431, commonly referred to as “Copy Fail.”  The vulnerability impacts Linux kernel functionality introduced broadly across Linux distributions beginning in 2017. 
 
Internal testing has confirmed that the following kernel parameter mitigation successfully blocks exploitation by disabling the vulnerable algif_aead initialization path: 
initcall_blacklist=algif_aead_init 
 
StorNext has been validated as compatible with both the kernel parameter mitigation and the permanent kernel fix where StorNext is available.  No operational issues were identified in testing. 
 
Note that the mitigation steps will require a reboot of the machine. Plan accordingly. 
 
APPLIES TO 

• Quantum StorNext clients 
• Xcellis Workflow Director (XWD) Gen 1 
• Xcellis Workflow Extender (XWE) Gen 1 
• Xcellis Workflow Director Gen 2 
• Xcellis Workflow Extender Gen 2 
• Xcellis Workflow Director Gen 3 
• Xcellis Workflow Extender Gen 3 

 

AFFECTED PRODUCTS 
The following product categories should be considered potentially affected: 

Product StorNext Version Boot System Mitigation Required
XWD / XWE Gen 1 & Gen 2 7.1.X – 7.2.5 BIOS GRUB (40_custom) update
XWD / XWE Gen 1 & Gen 2 7.2.6+ BIOS None — permanent kernel fix included
XWD / XWE Gen 3 7.2.0 – 7.2.5 UEFI GRUB (40_custom) update
XWD / XWE Gen 3 7.2.6+ UEFI None — permanent kernel fix included
StorNext Linux Clients Various Mitigation available; permanent kernel fix available (see StorNext Compatibility Guide)

 

DETERMINING SYSTEM TYPE 
For Xcellis systems, you will need to determine the boot system (BIOS or UEFI) and the installed StorNext version. 

Determine if your system is running BIOS or UEFI boot mode: 

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS 

Example internal validation showed: 

•  Older Gen 1 and Gen 2 Xcellis systems boot using BIOS 
•  Newer Gen3 Xcellis systems boot using UEFI 

Determine the version of StorNext running on your system: 
cat /opt/DXi/version_info

Example result of a system running StorNext 7.2.4: 
Major=7 
Minor=2 
Patch=4 
LCR= 
Port= 
Build=24463 
Version=7.2.4-24490 
Platform=BHG

 

MITIGATION QUICK REFERENCE 

Hardware Generation StorNext Version Boot Mode Step 1: GRUB Update Action Required
Gen 1 / Gen 2 7.1.X – 7.2.5 BIOS Required See Section 2
Gen 1 / Gen 2* 7.2.6+ BIOS
Gen 3† 7.2.0 – 7.2.5 UEFI Required See Section 3
Gen 3* 7.2.6+ UEFI
Linux Clients < 7.2.6 Various See Section 1

 

*Note: At the time of writing, StorNext 7.2.6 has not currently been released 

† Note: Gen 3 Xcellis systems only ship with StorNext 7.2.X and do not support 7.1.X.

Upgrade Note: Upgrading from StorNext 7.1.X to 7.2.0–7.2.5 changes the OS from CentOS Linux 7 to Rocky Linux 8.7. After such an upgrade, the GRUB configuration will be reset. Customers must re-apply both mitigation steps (Section 2) after completing the upgrade. Upgrading to 7.2.6 eliminates the need for any mitigation. 

MITIGATION GUIDANCE 
 
Section 1 – StorNext Linux Client recommendation 
Consult mitigation directions for your client OS.  
 
Section 2 –  Xcellis Workflow Director / Extender Gen 1 and Gen 2 
    StorNext 7.1.X - 7.2.5 (CentOS Linux 7 / Rocky Linux 8.7, BIOS) mitigation 

Gen 1 / Gen 2 Xcellis systems require mitigation for supported StorNext version 7.1.X - 7.2.5. No mitigation is required for 7.2.6 or later — the permanent kernel fix is included. 

NOTE: After upgrading to any StorNext version earlier than 7.2.6, the GRUB configuration will be reset. You must re-apply both steps below. No mitigation is required for 7.2.6 or later — the permanent kernel fix is included.

2a. Backup Existing Configuration 
cp /etc/grub.d/40_custom /scratch/saved/40_custom.orig 
 
2b. Edit GRUB Configuration 
Edit: 
/etc/grub.d/40_custom 
Add the following parameter to all linux16 boot lines: 
initcall_blacklist=algif_aead_init 
Example: 
linux16 /vmlinuz-... quiet nvme_core.multipath=Y LANG=en_US.UTF-8 initcall_blacklist=algif_aead_init 
 
2c. Rebuild GRUB Configuration 
/usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg

2d. Reboot 
systemctl reboot 

NOTE: A full systemctl reboot is required to update the kernel command line options. Reloading the kernel with kexec does not apply the mitigation. 
 
2e. Verify 
cat /proc/cmdline 
Verify that the mitigation parameter is present. 
 
2f. Optional Functional Verification 
This test requires the af_alg kernel module to be loaded.  First confirm the module is present: 
modprobe af_alg 
If modprobe af_alg fails, the test result will not reflect the mitigation state.  Once af_alg is confirmed loaded, run: 
python3 -c "import socket; socket.socket(38,5,0).bind(('aead','gcm(aes)',0,0))" 2>/dev/null && echo EXPOSED || echo BLOCKED 
If the mitigation is active, you will see BLOCKED. If it is not active, then you will see EXPOSED. If there are errors, then the af_alg may not be loaded and the test cannot be run.

Upgrades: 
When upgrading between versions, the GRUB configuration will be reset to its original state. After the upgrade is complete, re-apply the appropriate mitigation steps based on your target version: 

Note: The python snippet that validates mitigation strategies will not work with the permanent remediation as the af_alg socket will not be blocked. The updated kernel fixes the bug and allows normal af_alg module use. 

Section 3 – Xcellis Workflow Director / Extender Gen 3 — StorNext 7.2.0 through 7.2.5 (Rocky Linux 8.7, UEFI) mitigation 
Gen 3 Xcellis systems exclusively support StorNext 7.2.X and do not support 7.1.X. No mitigation is required for 7.2.6 or later — the permanent kernel fix is included. 

NOTE: Mitigation steps are very similar to Gen 1 / Gen 2 but have 2 important distinctions. 1. The grub line for Gen 3 will start with just linux and not linu16 like Gen 1 / Gen 2. The grub.cfg file to rebuild will be in /boot/efi/EFI/rocky/grub.cfg instead of /boot/grub2/grub.cfg that is required for Gen 1/ Gen 2.

3a. Backup Existing Configuration 
cp /etc/grub.d/40_custom /scratch/saved/40_custom.orig 

3b. Edit GRUB Configuration 
Edit: 
/etc/grub.d/40_custom 
Add the following parameter to all linux boot lines: 
initcall_blacklist=algif_aead_init 
Example: 
linux /vmlinuz-... quiet nvme_core.multipath=Y LANG=en_US.UTF-8 initcall_blacklist=algif_aead_init 

3c. Rebuild GRUB Configuration 
/usr/sbin/grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg 
 
3d. Reboot 
systemctl reboot 
 
NOTE: A full systemctl reboot is required to update the kernel command line options. Reloading the kernel with kexec does not apply the mitigation. 
 
3e. Verify 
cat /proc/cmdline 
Confirm that the mitigation parameter is active.

3f. Optional Functional Verification 
This test requires the af_alg kernel module to be loaded.  First confirm the module is present: 
modprobe af_alg 
If modprobe af_alg fails, the test result will not reflect the mitigation state.  Once af_alg is confirmed loaded, run: 
python3 -c "import socket; socket.socket(38,5,0).bind(('aead','gcm(aes)',0,0))" 2>/dev/null && echo EXPOSED || echo BLOCKED 
If the mitigation is active, you will see BLOCKED. If it is not active, then you will see EXPOSED. If there are errors, then the af_alg may not be loaded and the test cannot be run. 

A permanent fix is available for StorNext Linux clients by updating the kernel to include a patch that will fix CVE‑2026‑31431. See the NIST notification here: https://nvd.nist.gov/vuln/detail/CVE-2026-31431. A permanent remediation for Xcellis nodes will have a fix in the kernel in version 7.2.6. 
 
The kernel module builds correctly with the updated kernel; StorNext filesystems can be created and mounted normally, and full test suite validation has been completed successfully. No StorNext-specific action is required beyond the standard operating system update procedure. 

Update Procedure for Linux Clients 
Install new kernel: 
Apply the kernel update using your distribution's standard package manager 
Reboot the system to load the updated kernel: 
systemctl reboot 
 
Verify 
uname -r 
Confirm if the kernel version shown matches or exceeds your distribution’s recommended kernel version. 
Note: The python snippet that validates mitigation strategies will not work with the permanent remediation as the af_alg socket will not be blocked. The updated kernel fixes the bug and allows normal af_alg module use.

Note: The kernel parameter mitigation described in the MITIGATION GUIDANCE section remains valid and may be appropriate for StorNext Linux client systems that cannot immediately apply the kernel update. 

OPERATIONAL IMPACT 
Internal testing confirmed that neither the kernel parameter mitigation nor the RHEL 9.7 kernel errata introduced functional issues affecting: 
•  CVFS operation 
•  StorNext services 
•  Standard client connectivity 
•  No performance impact detected 
 
ROLLBACK PROCEDURE 
If operational issues are encountered, revert using the saved backup configuration files: 
• Restore original GRUB or systemd configuration 
• Rebuild GRUB configuration if necessary 
• Reboot system 
 
RECOMMENDATIONS 
Quantum recommends that customers: 
•  
StorNext Linux clients: apply the kernel errata as the preferred permanent resolution 
•  Xcellis appliances: apply the kernel parameter mitigation as documented above 
•  Validate changes in non-production environments where possible 
•  Coordinate maintenance windows for required reboots 
•  Monitor future Quantum advisories for remediation guidance covering additional platforms 
 
ADDITIONAL NOTES 
Because CVE‑2026‑31431 affects a Linux kernel component broadly present across many Linux distributions since 2017, customers running distributions or versions not covered by this bulletin should monitor: 
•  Operating system vendor advisories and errata for their specific distribution and version 
•  Distribution-specific kernel updates addressing CVE‑2026‑31431 
•  Future Quantum advisories for permanent remediation guidance covering additional platforms 


CONTACT INFORMATION 
In North America, call 1-800-284-5101.  In EMEA, call toll free +800-7826-8888 or direct +49 6131 324 185. In Asia Pacific, call 
+800-7826-8887. You will need your system serial number. For additional contact information, go to http://www.quantum.com/serviceandsupport/get-help/index.aspx#contact-support