Cloudanix VulnDB

CVE-2026-89726

None

CVSS

—

EPSS

0.2%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A small error in how the Linux kernel measures certain text strings could let an attacker peek at or disturb memory just outside the allowed area, which might cause crashes or leaks on affected systems.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Exposure
Component
OS kernel
Class
Memory Corruption
Remediation
Patch
Effort
Low
Patch risk
Low

What it actually does

Off-by-one out-of-bounds read in ucs2_strnlen() caused by checking the current character before verifying the caller-supplied maximum length, allowing one ucs2_char_t past the provided bound when the input lacks a NUL terminator inside the limit.

Why it matters to the business

Kernel memory corruption or information disclosure risk on systems processing UCS2 strings without proper termination, potentially leading to instability or data exposure in affected Linux environments; low exploitation likelihood reduces immediate urgency.

How an attack unfolds

An attacker supplies a non-NUL-terminated UCS2 buffer to a caller of ucs2_strnlen() with a length bound that does not contain a terminator, causing the function to read one element past the end of the supplied buffer before the length check occurs.

How to fix it

Apply the upstream kernel patch that moves the length test before the character dereference in ucs2_strnlen(); rebuild and deploy the corrected kernel image; no per-package fixed versions supplied in available data.

How to confirm the fix worked

Confirm the source change in lib/ucs2_string.c tests the length limit prior to accessing the current character; run existing kernel selftests for ucs2_string functions and verify no out-of-bounds access under crafted non-terminated inputs.

Typical attack path

  1. Identify code paths invoking ucs2_strnlen() on untrusted or attacker-controlled UCS2 data
  2. Craft input buffer lacking NUL within the declared maximum length
  3. Trigger the length check to dereference one element beyond the buffer limit
  4. Observe resulting kernel memory read for leak or crash

How to detect it

Search kernel logs and crash reports for oops or warnings referencing ucs2_strnlen or ucs2_string; inspect any user-space interfaces that pass UCS2 buffers to the kernel for length-related faults.

What your security team should do

  • Prioritize patching Linux kernels that include the vulnerable ucs2_strnlen() implementation
  • Monitor kernel update channels for the committed fix and schedule deployment
  • Review any custom code paths that call ucs2_strnlen() on external UCS2 data for additional bounds hardening

The record

In the Linux kernel, the following vulnerability has been resolved: lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen() Patch series "lib/ucs2_string.c: fix out-of-bounds read in ucs2_strnlen()", v2. This series fixes an off-by-one out-of-bounds read in ucs2_strnlen(). The first patch is the real fix, the second patch comes as a bonus and fixes the code indentation. This patch (of 2): ucs2_strnlen() checks the current character before checking whether the caller-provided maximum length has been reached. If the input is not NUL-terminated within that bound, the loop can read one ucs2_char_t past the limit. Test the length before dereferencing to prevent an off-by-one out-of-bounds read.

Affected packages

Ecosystem Package Introduced Fixed