Cloudanix VulnDB

CVE-2026-89550

Critical · 9.8

CVSS

9.8

EPSS

0.5%

Published

Sep 11, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A missing check in the code that handles secure network login tokens for file sharing can let an attacker crash servers without needing any login credentials.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Full Compromise
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Insufficient lower-bound validation on the opaque length supplied in svcauth_gss_unwrap_priv allows a krb5 token of length 0-16 bytes to reach gss_krb5_unwrap_v2, where header reads and rotate_left operate on a zero-length sub-buffer, resulting in division by zero.

Why it matters to the business

Remote unauthenticated attackers can crash NFS/RPC servers that use Kerberos authentication, causing denial of service and potential loss of file-service availability until the server is restarted.

How an attack unfolds

An attacker establishes a krb5-authenticated RPC session and sends a GSS token whose length field is set to 16 bytes or less; the server passes the short buffer unchanged into the krb5 v2 unwrap path, triggering the divide-by-zero in rotate_left before any integrity check occurs.

How to fix it

Apply the upstream patch that inserts an explicit minimum-length check (len <= GSS_KRB5_TOK_HDR_LEN) immediately after the existing upper-bound check in svcauth_gss_unwrap_priv; rebuild and deploy the updated kernel on all affected systems.

How to confirm the fix worked

Confirm the presence of the new length check in the kernel source or running binary; test by replaying a token with length 16 and verifying the server returns unwrap_failed instead of crashing.

Typical attack path

  1. Connect to an RPC service that uses svcauth_gss with krb5
  2. Send a GSS token with wire length <= GSS_KRB5_TOK_HDR_LEN
  3. Trigger gss_unwrap -> gss_krb5_unwrap_v2 -> rotate_left with zero-length buffer
  4. Cause kernel division-by-zero and panic or oops

How to detect it

Monitor kernel logs for division-by-zero oops or panic messages originating from gss_krb5_unwrap_v2 or rotate_left; correlate with incoming RPC traffic containing GSS tokens on ports 2049 or other NFS endpoints.

  • divide by zero in rotate_left
  • gss_krb5_unwrap_v2
  • svcauth_gss_unwrap_priv
  • GSS_KRB5_TOK_HDR_LEN

What your security team should do

  • Prioritize kernel updates on all systems exposing NFS/RPC services over untrusted networks
  • Enable kernel panic logging and watchdog mechanisms to accelerate detection of exploitation attempts
  • Review firewall rules to restrict RPC ports to trusted clients until patches are applied

The record

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: svcauth_gss: enforce krb5 token minimum length svcauth_gss_unwrap_priv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gss_unwrap(): if (len > xdr_stream_remaining(xdr)) goto unwrap_failed; offset = xdr_stream_pos(xdr); ... maj_stat = gss_unwrap(ctx, offset, offset + len, buf); The wire value `len` flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gss_unwrap(). For a krb5 v2 context that lands in gss_krb5_unwrap_v2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotate_left() before any integrity check. With a sub-header length the header reads run past the token, and _rotate_left()'s `shift %= buf->len` path can divide by zero when buf->len has been driven to zero by the truncated token. A header-only token (len == 16) is equally invalid: with a non-zero RRC field and the opaque blob ending at the XDR buffer boundary, rotate_left() builds a zero-length subbuffer, reaching the same division. Reject the token at the server entry point before it reaches the krb5 unwrap core. A valid sealed RFC 4121 token must contain the 16-byte header plus at least some encrypted payload. Fix by adding a minimum-length check immediately after the existing upper-bound check: if (len <= GSS_KRB5_TOK_HDR_LEN) goto unwrap_failed;

Affected packages

Ecosystem Package Introduced Fixed