Look up another CVE · open CVE-2026-89542 in the interactive tracker
CVE-2026-89542
SUNRPC: harden gss_krb5_unwrap_v2 against short tokens
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem net/sunrpc. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89542 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
gss_krb5_unwrap_v2() reads the EC and RRC header fields at ptr+4 and ptr+6 before validating that the token is at least GSS_KRB5_TOK_HDR_LEN (16) bytes long, and its rotate_left() helper passes buf->len - base to xdr_buf_subsegment() without verifying that base <= buf->len. When a caller hands in a sub-16-byte token, or a token whose declared len leaves base past the end of the buffer, three distinct failures follow: gss_krb5_unwrap_v2(offset, len, buf) ptr = buf->head[0].iov_base + offset ec = *(ptr + 4) /* OOB read on short head */ rrc = *(ptr + 6) /* OOB read on short head */ rotate_left(offset + 16, buf, rrc) xdr_buf_subsegment(buf, &subbuf, base, buf->len - base) /* u32 wrap when base > len */ _rotate_left(&subbuf, shift) shift %= buf->len /* divide-by-zero when base == len */ After decryption, the cleanup arithmetic has the same shape: movelen = min_t(unsigned int, buf->head[0].iov_len, len); movelen -= offset + GSS_KRB5_TOK_HDR_LEN + headskip; BUG_ON(offset + GSS_KRB5_TOK_HDR_LEN + headskip + movelen > buf->head[0].iov_len); The BUG_ON re-adds the value just subtracted, so it reduces to min(A, B) > A and is permanently false; it cannot catch the unsigned underflow of movelen, which then drives a ~UINT_MAX-byte memmove(). Add four defense-in-depth guards inside the unwrap core so it is safe regardless of what its callers validate: - reject tokens with len - offset < GSS_KRB5_TOK_HDR_LEN before touching ptr+4/ptr+6; - bail from rotate_left() when buf->len <= base, covering both the underflow and zero-length cases; - return early from _rotate_left() when buf->len is zero, so the shift %= buf->len modulo cannot fault; - replace the dead BUG_ON with a live check that returns GSS_S_DEFECTIVE_TOKEN before the movelen subtraction.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/sunrpc/auth_gss/gss_krb5_wrap.c
- What this is
- KERNEL NFSD, SUNRPC, AND LOCKD SERVERSMAINTAINERS section matched on net/sunrpc/ · linux-nfs@vger.kernel.org · Supported
- Kernel module
- rpcsec_gss_krb5
Check it on the machine
grep -wE 'CONFIG_RPCSEC_GSS_KRB5|CONFIG_SUNRPC|CONFIG_SUNRPC_GSS' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w rpcsec_gss_krb5Prints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sid, bookworm · linux-6.12m
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switches
- CONFIG_RPCSEC_GSS_KRB5, CONFIG_SUNRPC, CONFIG_SUNRPC_GSS
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 9.8 critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- network (AV:N)source
- EPSS
- 0.51%, higher than 42.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/sunrpc
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.35 | 5.10.270 | 299d281c7225 |
| 2.6.35 | 5.15.221 | 84ddbc8d084c |
| 2.6.35 | 6.1.188 | 075d7cfc4df8 |
| 2.6.35 | 6.6.157 | f2591660e0eb |
| 2.6.35 | 6.12.109 | dddcb0f4b7e2 |
| 2.6.35 | 6.18.50 | 806584a4b67a |
| 2.6.35 | 7.2.4 | a7894e10572d |
| 2.6.35 | 7.3 | 6959297aaa95 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:NAttack vector, network
- gss_krb5_unwrap_v2() is reached from nfsd RPCSEC_GSS privacy unwrap (svcauth_gss_accept → svcauth_gss_unwrap_priv → gss_unwrap) on TCP/2049 and from the NFS client gss_unwrap_resp_priv() path on a krb5p Reply, so a remote RPCSEC_GSS peer delivers the crafted wrap token over the network.
- AC:LAttack complexity, low
- A single crafted RPCSEC_GSS DATA/Reply with a sub-16-byte wrap token (KG2_TOK_WRAP, sealed flags, non-zero RRC) deterministically hits the pre-decrypt ptr+4/ptr+6 reads, rotate_left() u32 wrap, and shift%=0 divide-by-zero; no race or attacker-uncontrollable layout is required.
- PR:NPrivileges required, none
- A malicious NFS server on an existing krb5p session needs no account or capability on the victim client to send the crafted Reply into gss_unwrap_resp_priv(). That client-victim path is the highest-severity reachability and requires no privileges on the target.
- UI:NUser interaction, none
- nfsd unwraps the Call in the service thread with no local user action. On the client, gss_unwrap_resp_priv() runs automatically from the RPC receive path once an NFS/RPCSEC_GSS mount exists; no additional mount, click, or open is required at attack time.
- S:UScope, unchanged
- The out-of-bounds accesses, divide-by-zero, and underflowed memmove corrupt host kernel SUNRPC/GSS state on the machine processing the RPC. This is ordinary same-host kernel impact, not a VM escape, IOMMU bypass, or other changed-scope boundary.
- C:HConfidentiality impact, high
- Short tokens make gss_krb5_unwrap_v2() read EC/RRC past the token, and the dead BUG_ON lets unsigned movelen underflow into a ~UINT_MAX-byte memmove() that copies kernel memory beyond the receive head; that unbounded read is C:H per kernel CNA memory-corruption guidance.
- I:HIntegrity impact, high
- The same underflowed memmove() writes near 4GiB through the RPC receive head, an out-of-bounds write exploitable for control-flow hijack. rotate_left() also ignores xdr_buf_subsegment() failure after u32 wrap and then writes through a subbuf whose length has wrapped.
- A:HAvailability impact, high
- _rotate_left() does shift %= buf->len on a zero-length subbuffer (header-only token at the XDR boundary), a divide-by-zero oops/panic; the UINT_MAX memmove and wrapped-length rotate loop hang or oops nfsd/rpciod, and the attacker can repeat the RPC to deny service.