CVE-2026-45857

What it actually does

This is a local denial-of-service flaw in the Linux kernel csiostor SCSI storage driver. In a specific error-handling path, the driver can attempt to update statistics through a NULL rn pointer, causing a kernel NULL pointer dereference. On affected systems where the csiostor driver is present and reachable, a low-privileged local attacker may be able to trigger a kernel oops or panic, disrupting system availability. The issue does not indicate confidentiality loss, integrity modification, or direct privilege escalation.

Why it matters to the business

Successful exploitation can crash or destabilize Linux systems that rely on the affected storage driver, causing application downtime, failed jobs, interrupted storage access, or host reboots. The risk is most relevant to servers using the csiostor driver or hardware paths that load it; systems that do not include or load this driver are unlikely to be exposed. This vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, has very low EPSS probability, and currently has no known public exploit maturity, so remediation should be prioritized based on driver exposure and workload criticality rather than broad internet-scale exploitation risk.

How an attack unfolds

An attacker first needs local access to an affected Linux system. They then interact with storage or SCSI functionality in a way that causes the csiostor driver to enter an error path where the rn object is NULL. Before the fix, that error path still invokes statistics-handling logic that dereferences rn, producing a kernel NULL pointer dereference. Depending on kernel panic settings and system configuration, the result may be a kernel oops, hung storage path, service disruption, or full system crash/reboot. There is no evidence from the provided intelligence that this vulnerability is being exploited by named threat actors or active campaigns.

How to fix it

Apply a Linux kernel update from the operating system or distribution vendor that includes the upstream csiostor NULL pointer dereference fix. Because no fixed package versions were provided in the input, use the vendor advisory or kernel changelog for the deployed distribution to identify the exact corrected kernel build. Reboot into the patched kernel after installation. If immediate patching is not possible and the driver is not required, reduce exposure by unloading and blacklisting the csiostor module, removing unused Chelsio/SCSI storage hardware paths, or restricting local shell access to trusted administrators. Avoid relying on application-layer controls alone because the vulnerable code is in kernel space.

How to confirm the fix worked

Confirm the system is running a patched kernel, not merely that the package is installed. Validate with kernel package inventory and runtime kernel version checks such as uname -r, distribution package metadata, and vendor security advisory mapping. Check whether the affected driver is present or loaded using commands such as lsmod | grep csiostor, modinfo csiostor, and test -d /sys/module/csiostor. Review boot configuration to confirm the patched kernel is selected after reboot. For mitigated systems, confirm the csiostor module is not loaded and is blacklisted if the hardware path is not required. Review recent kernel logs for NULL pointer dereference, oops, panic, or call traces involving csiostor to determine whether exposure may have already caused instability.

Typical attack path

1. Obtain low-privileged local access to a Linux host where the csiostor driver is installed and loaded.
2. Identify that the affected SCSI/storage driver path is reachable, usually because the relevant storage hardware or module is active.
3. Trigger storage or SCSI operations that cause the driver to follow the vulnerable error-handling path with a NULL rn pointer.
4. The driver attempts to update statistics through the NULL pointer and causes a kernel NULL pointer dereference.
5. The host experiences a kernel oops, panic, reboot, or storage-service disruption, resulting in denial of service.

How to detect it

To assess possible prior exploitation or impact, review kernel and system logs for crashes or oops events involving the csiostor driver. Relevant sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore artifacts, and centralized EDR or SIEM telemetry that collects kernel panic events. Look for NULL pointer dereference messages, kernel oops records, panic/reboot events, and call traces that include csiostor functions or the csiostor.ko module. Correlate those events with local user sessions, sudo activity, storage-management commands, container workload launches, or repeated unexplained host reboots. Because this is a denial-of-service issue, evidence may appear as instability rather than file creation, persistence, credential theft, or outbound command-and-control traffic.

• BUG: kernel NULL pointer dereference
• Oops:
• Kernel panic - not syncing
• csiostor
• csiostor.ko
• /sys/module/csiostor
• csio_scsi
• CSIO_INC_STATS
• Call Trace:
• RIP:

What your security team should do

• Inventory Linux systems for the csiostor kernel module and prioritize hosts where it is loaded or required for storage access.
• Patch exposed systems with the vendor-provided kernel update and reboot into the fixed kernel.
• If patching is delayed and the driver is unnecessary, unload and blacklist csiostor as a temporary mitigation.
• Prioritize production storage hosts, virtualization hosts, and systems with strict availability requirements, even though broad exploitation likelihood is currently low.
• Restrict local interactive access and untrusted workload execution on systems where the affected driver remains loaded.
• Monitor kernel logs for NULL pointer dereference, oops, panic, or call traces involving csiostor.
• After remediation, verify both package state and the running kernel version, and ensure no host continues booting an older vulnerable kernel.