A short, targeted kernel fix landed this week that closes a subtle but real correctness bug in the SCSI generic driver (sg): the function responsible for finishing a removed request, sg_finish_rem_req, was calling blk_rq_unmap_user while interrupts were disabled — and blk_rq_unmap_user can sleep. The kernel change makes the call with interrupts enabled (or otherwise avoids the no‑sleep context), eliminating a path that could trigger an illegal “sleeping function called from invalid context” or a kernel oops. The issue is tracked as CVE‑2025‑40259 and has been assigned public entries in several vulnerability trackers and the kernel stable trees.
Background / Overview
The Linux SCSI generic driver (sg) sits between userland applications and the block/SCSI stacks, exposing a character-device interface that allows user processes to submit SCSI commands directly to devices. That user‑kernel bridge must carefully manage DMA, memory mappings, and request lifecycles. A subtle change in context handling — specifically, performing an operation that may block while the kernel is in an atomic/no‑sleep context — is a classic source of kernel instability. In this case, sg_finish_rem_req invoked blk_rq_unmap_user, a block layer helper that can sleep under certain conditions. The fix moves the call out of the non‑sleepable path so the kernel no longer risks a sleeping call while interrupts are disabled. The vulnerability description is summarized in public trackers and upstream commits. Why this matters operationally: a sleeping call from an atomic context typically triggers a kernel warning and often leads to a kernel oops or panic. On systems that host critical workloads (storage servers, hypervisor hosts, or appliances that rely on SCSI passthrough), such an oops can interrupt services, require a reboot, or in multitenant settings be triggered by untrusted workloads. Several public trackers and vendor advisories reflect the upstream commit and mark the issue as resolved in stable kernel branches.
The technical problem in plain language
- sg_finish_rem_req is part of the sg driver’s request cleanup path. It performs work to finish a request that has been removed or completed.
- As part of that cleanup, it called blk_rq_unmap_user, a block‑layer helper that unmaps memory regions associated with the bio/request and may perform operations that sleep (for example, if it needs to synchronize with filesystem or block‑layer resources).
- The sg code path in question executed with interrupts disabled (an atomic context), where sleeping is forbidden. Calling a function that can sleep in that context is a correctness bug: the kernel asserts and panics are designed to catch it.
- The fix moves the unmapping to a context where sleeping is allowed (or otherwise enables interrupts for that section), ensuring that blk_rq_unmap_user cannot cause an illegal sleep.
Conceptually, this is a context/contract violation rather than a memory‑corruption bug. The semantics of kernel context (atomic vs. process context) are strict: code that might fault, reschedule, or sleep must run only when sleeping is permitted. Violations produce immediate availability impacts rather than long‑term data corruption or privilege escalation chains — though availability failures in storage subsystems can be severe.
What the public trackers say
Multiple vulnerability trackers published the same concise technical summary: “scsi: sg: Do not sleep in atomic context — sg_finish_rem_req calls blk_rq_unmap_user. The latter function may sleep. Hence, call sg_finish_rem_req with interrupts enabled instead of disabled.” The NVD entry reflects the standard description awaiting fuller enrichment, while community trackers (CVE Details, cvefeed/OpenCVE and others) list the kernel stable commit IDs referenced by the fix. Those references provide the authoritative mapping from CVE to upstream git commits so packagers can verify a fix. SUSE’s tracker and other distributor feeds show the issue flagged and list the upstream description (distribution-specific status entries vary by vendor). Red Hat/knowledgebase and community crash reports show real-world kernel oopses reporting sg_finish_rem_req in backtraces, which corroborates that the problematic path has been observed in field logs.
Why this bug is not trivial to reason about
At first glance the fix is small, but the underlying class of errors is subtle:
- Kernel code uses many micro‑optimizations and context assumptions: a cleanup path may intentionally disable interrupts or hold spinlocks to protect short critical sections. Those micro‑optimizations assume the code inside won’t sleep or fault.
- Block‑layer helpers like blk_rq_unmap_user operate across layers and can perform I/O‑synchronous or allocation work that faults/sleeps. The interaction between device drivers and generic block helpers is delicate — a wrong ordering or context assumption at a boundary can introduce sleep‑from‑atomic bugs.
- The sg driver is frequently exercised in production on servers with heavy I/O. The combination of high activity and rare timing windows makes such faults observable in production as occasional oopses or reproducible traces once the right conditions align. Public kernel backtraces demonstrate sg_finish_rem_req appearing in crash logs, confirming the practical impact.
This class of bug is also notable because it is easy to miss in code review: the called function’s internal behavior (may it sleep? can be non‑obvious without careful tracing of call chains and the block layer’s allocation semantics.
Impact assessment: Availability-focused, local vector
- Primary impact: Availability. The bug can produce kernel warnings, oopses, or panics that disrupt services relying on the host kernel’s storage stack.
- Attack vector: Local / privileged process or guest. Triggering requires code or an operation that walks the sg code path and hits the cleanup logic — for example, a local process issuing SCSI passthrough requests or a privileged guest using device‑backed SCSI channels on a host.
- Exploitability: Moderate for DoS in exposed environments. There is no public evidence this defect enables remote code execution or direct privilege escalation by itself. That said, denial‑of‑service against a host running many tenants or critical services is operationally high‑impact.
Many vulnerabilities fall into two broad buckets: memory‑corruption (potential RCE) and context/logic correctness (availability). CVE‑2025‑40259 is the latter: it’s a correctness bug that can reliably crash or destabilize a host under the right conditions.
Which systems are likely affected
- Any kernel build that includes the sg driver (drivers/scsi/sg) and does not contain the upstream stable fix is potentially affected. Community trackers list the upstream commit IDs that implement the change; packagers should map those commit IDs to kernel package changelogs or CVE advisories in their distribution’s security tracker to determine exposure.
- Production storage hosts, SAN gateways, and hypervisor hosts that expose SCSI passthrough to guests or run processes that perform SG_IO calls are the high‑exposure population.
- Desktop machines that do not use the sg interface or SCSI passthrough are lower priority, though the fix is small and safe to apply broadly. Vendor timelines (distributions, appliance vendors, and embedded OEMs) will vary; vendor‑specific advisories are the authoritative guide for each platform.
Patching and verification
Definitive remediation: install a kernel package that contains the upstream stable commit(s) referenced by the CVE and reboot into the patched kernel. The upstream kernel commits were published and backported into stable trees; distributions will roll them into their kernel packages. Use package changelogs, distribution security advisories, or kernel package metadata to confirm the presence of the specific stable commit ID before marking systems as remediated. Validation steps after patching:
- Confirm the running kernel includes the fix: uname -r and check your distribution’s kernel changelog for the upstream commit IDs referenced in the CVE listing.
- Reproduce previously observed failing traces in a controlled staging environment (do not attempt on production).
- Monitor kernel logs (dmesg, journalctl -k) for at least 7–14 days post‑patch for unusual KERNEL_WARN/OOPS messages related to sg or SCSI paths.
If you cannot patch immediately, temporary mitigations include:
- Restrict which workloads can access SG_IO or SCSI passthrough devices (limit untrusted users or guests).
- Move high‑risk or untrusted guests to patched hosts.
- In lab or low‑performance setups, avoid or disable sg/SG_IO usage where feasible until patched.
Note: changes to device or driver configurations to avoid the path are fragile and risky; they should be treated as temporary mitigations only. The official kernel patch is the correct long‑term fix.
Detection — what to look for in logs
Hunt for kernel messages and oops traces that mention:
- sg_finish_rem_req
- blk_rq_unmap_user
- “sleeping function called from invalid context”
- stack traces that include SCSI/sg and block‑layer frames
Such traces are often deterministic for this class of bug and include the offending function names; collecting and preserving kernel logs and panic traces is important for post‑incident analysis. Red Hat community notes and other field reports show typical backtraces where sg_finish_rem_req appears near the faulting instruction in the oops dump.
Risk trade‑offs and operational advice
- For cloud providers and multi‑tenant hosts: prioritize patching immediately. A single untrusted guest that can trigger SG_IO or certain passthrough sequences could intentionally cause host instability.
- For storage appliances and SAN gateways: schedule a maintenance window to apply updated kernels or vendor firmware as soon as vendor advisories are available and validated.
- For single‑user desktops and controlled lab hosts: risk is lower, but patching remains recommended to eliminate latent instability.
- Testing: apply the updated kernel to a representative pilot group, validate storage paths, live migration (if applicable), snapshot/backup workflows, and performance-sensitive IO before wide deployment.
Operational takeaways:
- This CVE underscores the importance of “context discipline” in kernel code: never call potentially sleeping helpers from atomic contexts.
- Small fixes upstream can have outsized impact on host reliability; timely mapping from upstream commits to distribution packages is essential for rapid remediation.
What changed in the kernel (summary)
The upstream change is intentionally minimal and corrective:
- The sg cleanup path was modified so that blk_rq_unmap_user is invoked from a sleepable context (or the code enables interrupts during that section), removing the illegal call from atomic contexts.
- The patch preserves functional behavior while restoring the kernel‑context contract: operations that may sleep run only when sleeping is permitted.
- Stable commit IDs have been published and propagated to downstream trees; distributions have begun packaging the corrected kernels. Trackers list the commit references so operators can map to distribution packages.
Because the fix is a context/ordering correction rather than a behavioral redesign, the risk of regression is low; nevertheless, operators should still perform standard staged rollouts.
Why you should care: operational context
Even non‑exploitability bugs matter. A kernel oops in the storage path can:
- Interrupt storage I/O, causing application errors, database rollbacks, or service outages.
- Bring hosts out of rotation in high‑availability clusters.
- Force reboots on hosts without automated recovery, requiring manual intervention.
- Amplify risk in multi‑tenant environments where a single malicious or buggy tenant can affect co‑tenants.
The technical root cause — sleep-in-atomic — is a repeatedly seen pattern in kernel reliability issues. Fixing these patterns prevents a long class of availability faults across diverse subsystems.
Practical checklist for administrators
- Inventory: Identify hosts that expose SCSI passthrough or use sg (search for modules named sg or usages of SG_IO).
- Vendor mapping: Check your distribution’s security tracker and kernel package changelogs for the CVE or the upstream stable commit IDs listed by public trackers.
- Patch and reboot: Apply vendor kernel updates that include the upstream fix; perform a staged rollout with verification windows.
- Monitor: After patching, watch kernel logs for any recurrence of the sg_finish_rem_req oops and for unexpected regressions.
- Containment: If you see active oopses and cannot patch immediately, isolate affected hosts from clusters and consider quarantining untrusted guests or user processes that touch SCSI passtrough.
Final assessment and closing analysis
CVE‑2025‑40259 is a narrow, correctness‑class vulnerability in the Linux kernel’s SCSI generic (sg) driver. It does not introduce a memory‑corruption primitive for arbitrary code execution; its primary threat is
host availability through illegal sleeping in atomic context. Because the triggered symptom is a kernel oops or panic, the operational impact can be immediate and severe for storage‑critical hosts and multi‑tenant infrastructure.
The remediation is simple and authoritative: install a kernel that contains the upstream stable commit(s) that move blk_rq_unmap_user calls out of atomic contexts (or enable interrupts for that work). Operators should treat this as a patch‑and‑verify task — prioritize hosts that handle untrusted workloads or that are infrastructure critical for services. Public trackers and distribution advisories list the upstream commits and reflect the issue’s resolution; map those commits to your vendor packages before wide deployment. Caveat: while public trackers and stable commits corroborate the technical description, distribution and vendor backport timelines vary. Validate the mapping from upstream commits to your distribution’s kernel packages before declaring remediation complete. If you require detailed mapping to a specific vendor package or assistance locating the exact stable commit in a vendor kernel, consult your distribution’s security advisory or support channel for the authoritative package-level guidance.
Conclusion
This fix is an important example of defensive kernel engineering: removing sleeping calls from atomic contexts preserves host stability without user‑visible feature changes. For administrators of storage hosts, virtual machine hosts with device passthrough, and critical appliances, the correct operational response is simple and clear — apply the patched kernel, verify SCSI/sg behavior in staging, and roll out with standard monitoring. The cost of inaction is avoidable host instability; the cost of patching is a routine kernel update and test cycle.
Source: MSRC
Security Update Guide - Microsoft Security Response Center