CVE-2026-53304

What it actually does

This is a local denial-of-service flaw in the Linux kernel SCSI generic driver. The sg module parameter def_reserved_size is intended to be constrained to 0 through 1,048,576 bytes, but direct writes to /sys/module/sg/parameters/def_reserved_size could bypass the validation path. Supplying an invalid value, such as a negative number, can cause the sg driver to enter a soft-lockup condition when a /dev/sgX device is opened, leaving a CPU stuck in kernel code. The issue does not directly provide remote code execution, privilege escalation, or data disclosure; its primary impact is local system availability degradation or hang.

Why it matters to the business

An attacker who already has sufficient local privileges to modify kernel module parameters and access SCSI generic devices could intentionally destabilize a Linux host. This can interrupt workloads that depend on the affected system, including storage, backup, tape, scanner, virtualization, or device-management operations using SCSI generic interfaces. Current public risk indicators are low: EPSS is very low, the issue is not in the CISA KEV catalog, it is not known to be used in ransomware campaigns, and no mature public exploit is indicated. However, on critical Linux infrastructure, a local denial-of-service primitive can still be operationally significant if abused after an initial compromise.

How an attack unfolds

Exploitation requires local access with permission to write to the sg kernel module parameter exposed through sysfs, typically requiring root-level privileges or equivalent administrative capability. The attacker sets def_reserved_size to an invalid value outside the expected range, then opens a SCSI generic character device such as /dev/sg0. During the open operation, the kernel enters the sg_open path and attempts to build the reserved buffer using the invalid value. This can trigger a soft lockup, with watchdog messages reporting a CPU stuck in kernel execution in functions such as sg_build_reserve, sg_add_sfp, and sg_open. The result is a denial of service rather than compromise of confidentiality or integrity.

How to fix it

Apply the vendor kernel update that includes validation for direct writes to the sg def_reserved_size module parameter, implemented through module_param_cb or equivalent parameter validation. Use distribution-provided fixed kernels when available and reboot into the updated kernel. If an immediate update is not available, reduce exposure by unloading or disabling the sg module where it is not required, restricting access to /dev/sg* devices to only trusted administrative users and service accounts, preventing containers and untrusted workloads from accessing host /sys/module or SCSI generic devices, and monitoring or blocking writes to /sys/module/sg/parameters/def_reserved_size. Ensure the runtime value of def_reserved_size remains within the documented range of 0 to 1,048,576.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix for sg def_reserved_size parameter validation. Verify the active value with cat /sys/module/sg/parameters/def_reserved_size and ensure it is within 0 to 1,048,576. Review file permissions and access controls for /sys/module/sg/parameters/def_reserved_size and /dev/sg* to ensure only trusted administrators can modify or use them. In a controlled non-production test system, validate that attempts to set an out-of-range value are rejected and do not change the parameter. After patching, check dmesg, journalctl, or kernel logs for absence of new soft-lockup messages referencing sg_build_reserve, sg_add_sfp, or sg_open.

Typical attack path

1. Gain local administrative or equivalent privileged access to a Linux system with the sg SCSI generic driver available.
2. Confirm that /sys/module/sg/parameters/def_reserved_size is writable and that one or more /dev/sgX devices are present or accessible.
3. Write an invalid value outside the supported 0 to 1,048,576 range to /sys/module/sg/parameters/def_reserved_size.
4. Open a SCSI generic device such as /dev/sg0 to trigger the vulnerable sg_open code path.
5. Cause a kernel soft lockup, resulting in CPU stall, service degradation, system instability, or the need for administrative recovery.

How to detect it

Look for evidence of prior writes to the sg module parameter and subsequent kernel soft-lockup events. Relevant sources include auditd logs, Linux kernel logs, dmesg output, journald, syslog, EDR process telemetry, command history, and file-integrity monitoring for sysfs writes. Search for writes to /sys/module/sg/parameters/def_reserved_size, especially values below 0 or above 1048576, followed by opens of /dev/sg0, /dev/sg1, or other /dev/sg* devices. Kernel logs may show watchdog soft-lockup messages with call traces containing sg_build_reserve, sg_add_sfp, sg_open, chrdev_open, or do_dentry_open. Because the activity may be performed by shell commands or scripts, review root shell histories and process execution records for echo, printf, tee, or redirection targeting the def_reserved_size sysfs parameter. Treat unexplained soft lockups on systems with the sg module loaded as suspicious until administrative maintenance or benign misconfiguration is ruled out.

• /sys/module/sg/parameters/def_reserved_size
• /dev/sg0
• /dev/sg1
• /dev/sg2
• /dev/sg3
• echo -1 > /sys/module/sg/parameters/def_reserved_size
• tee /sys/module/sg/parameters/def_reserved_size
• watchdog: BUG: soft lockup
• BUG: soft lockup - CPU
• sg_build_reserve
• sg_add_sfp
• sg_open
• chrdev_open
• do_dentry_open
• vfs_open
• path_openat
• __x64_sys_openat

What your security team should do

• Prioritize patching Linux systems where the sg module is loaded and where SCSI generic devices are used for storage, backup, device management, virtualization, or hardware pass-through.
• Inventory hosts exposing /sys/module/sg/parameters/def_reserved_size and /dev/sg* devices, especially shared servers and systems running containers or untrusted workloads.
• Restrict write access to kernel module parameters and restrict /dev/sg* device access to trusted administrative users only.
• Add audit or EDR monitoring for writes to /sys/module/sg/parameters/def_reserved_size and for suspicious access to /dev/sg* devices.
• Investigate any kernel watchdog soft-lockup events involving sg_build_reserve, sg_add_sfp, or sg_open as potential attempted exploitation or unsafe administrative activity.
• If sg is not operationally required, disable or unload the module to remove the vulnerable attack surface.