CVE-2025-68348
NoneCVSS
—
EPSS
0.2%
Published
Dec 24, 2025
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel could slowly waste memory during certain disk operations, eventually making systems less stable until the kernel is updated.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Denial Of Service
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Memory leak occurs in __blkdev_issue_zero_pages when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending: bio_alloc() happens before the signal check, so the loop exits without freeing or chaining the allocated bio.
Why it matters to the business
Repeated triggering can gradually exhaust kernel memory on Linux systems that perform block-device zeroing operations, leading to degraded performance, instability, or crashes over time; the issue has low exploitation probability and is not known to be used in ransomware.
How an attack unfolds
An attacker with local access or the ability to trigger block zero operations under conditions where a fatal signal can be made pending causes the kernel to leak bio structures without recovery; the flaw was present in the stable Linux kernel tree prior to the referenced commit and requires no special privileges beyond those needed to initiate the affected I/O path.
How to fix it
Update the Linux kernel to the commit 453e4b0c84d0db1454ff0adf655d91179e6fca3a or later; rebuild and deploy the patched kernel across affected systems.
How to confirm the fix worked
Confirm the running kernel contains commit 453e4b0c84d0db1454ff0adf655d91179e6fca3a; recompile with the fix and verify that signal-pending zero-page operations no longer leak memory via slab or kmemleak checks.
Typical attack path
- Obtain local execution or trigger block-device zeroing operations
- Arrange for a fatal signal to be pending at the time the zero-pages function runs
- Cause repeated allocation of bios that are never freed or chained
- Accumulate leaked memory until system resources are exhausted
How to detect it
Review kernel memory statistics and slab allocator usage for unexpected growth in bio-related objects during block zero operations; examine system logs for repeated fatal signal handling around block I/O paths.
What your security team should do
- Prioritize kernel updates on all Linux hosts that use block-device zeroing paths
- Monitor memory usage trends on production systems until patches are applied
- Include the fixed commit in automated kernel build and deployment pipelines
The record
In the Linux kernel, the following vulnerability has been resolved: block: fix memory leak in __blkdev_issue_zero_pages Move the fatal signal check before bio_alloc() to prevent a memory leak when BLKDEV_ZERO_KILLABLE is set and a fatal signal is pending. Previously, the bio was allocated before checking for a fatal signal. If a signal was pending, the code would break out of the loop without freeing or chaining the just-allocated bio, causing a memory leak. This matches the pattern already used in __blkdev_issue_write_zeroes() where the signal check precedes the allocation.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|---|---|---|
| Linux | Kernel | 6.11.0 | 6.12.63 |
| openSUSE:Leap 16.0 | dtb-aarch64 | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-64kb | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-azure | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-default | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-default-base | 0 | 6.12.0-160000.26.1.160000.2.7 |
| openSUSE:Leap 16.0 | kernel-docs | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-kvmsmall | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-obs-build | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-obs-qa | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-rt | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-source | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-syms | 0 | 6.12.0-160000.26.1 |
| openSUSE:Leap 16.0 | kernel-zfcpdump | 0 | 6.12.0-160000.26.1 |
| openSUSE:Tumbleweed | kernel-source | 0 | 6.18.5-1.1 |
| openSUSE:Tumbleweed | kernel-source-longterm | 0 | 6.18.16-1.1 |
Related vulnerabilities
- CVE-2026-23226 In the Linux kernel, the following vulnerability has been resolved: ksmbd: add chann_lock… Also affects Kernel
- CVE-2026-23225 In the Linux kernel, the following vulnerability has been resolved: sched/mmcid: Don't… Also affects Kernel
- CVE-2026-23230 In the Linux kernel, the following vulnerability has been resolved: smb: client: split… Also affects Kernel
- CVE-2026-23224 In the Linux kernel, the following vulnerability has been resolved: erofs: fix UAF issue… Also affects Kernel
- CVE-2026-23227 In the Linux kernel, the following vulnerability has been resolved: drm/exynos: vidi: use… Also affects Kernel
- CVE-2026-23223 In the Linux kernel, the following vulnerability has been resolved: xfs: fix UAF in… Also affects Kernel
- CVE-2026-23228 In the Linux kernel, the following vulnerability has been resolved: smb: server: fix leak… Also affects Kernel
- CVE-2026-23229 In the Linux kernel, the following vulnerability has been resolved: crypto: virtio - Add… Also affects Kernel