UBUNTU-CVE-2026-99135: Medium severity ubuntu/linux-hwe-edge vulnerability
In the Linux kernel, the following vulnerability has been resolved: dm-integrity: fix infinite loop on discard with large tag size When integritymetadata handles a discard, it fills a buffer with DISCARDFILLER and writes it over the tags, maxblocks blocks at a time. If the kmalloc fails, the buffer is the on-stack array checksumsonstack and maxsize is set to HASHMAXDIGESTSIZE. So if the tag size is larger than HASHMAXDIGESTSIZE, maxblocks is zero, bisize is never decremented and the loop never terminates. Fix this by using sizeof(checksumsonstack) as maxsize. The array has MAXTAGSIZE bytes since commit b93b6643e9b5 ("dm integrity: fix a crash with unusually large tag size"), so maxblocks is at least 1.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Set max_size to sizeof(checksums_onstack), including when the kmalloc allocation fails and checksums_onstack is used, so max_blocks is at least 1 and discard processing terminates.
dm-integrity max_size = sizeof(checksums_onstack)
Event History
Frequently Asked Questions
What conditions are required to trigger the infinite loop?
The issue occurs when dm-integrity processes a discard and allocation of its tag-fill buffer fails, causing it to fall back to an on-stack buffer. A tag size larger than HASH_MAX_DIGESTSIZE then makes the computed number of blocks per iteration zero, so the discard request is never consumed.
What is the practical impact of successful exploitation?
The affected discard-processing loop does not terminate, which can cause the relevant kernel operation to hang. The provided data does not establish a privilege-escalation or data-disclosure impact.
Which Ubuntu kernel packages are listed as affected by this record?
The record lists ubuntu/linux, ubuntu/linux-realtime, ubuntu/linux-azure, ubuntu/linux-gcp, ubuntu/linux-azure-fde, ubuntu/linux-gke, ubuntu/linux-riscv, and ubuntu/linux-gkeop.
Is there a workaround when an updated kernel cannot be deployed immediately?
No workaround is provided in the available data. The described fix changes the fallback buffer size calculation to use sizeof(checksums_onstack), ensuring that at least one block is processed per loop iteration.