CVE-2026-89544

SUNRPC: fix gssx_dec_option_array error path bugs

HIGH
7.5
CVSS Score
Published: September 11, 2026 at 07:44 PM UTC
Updated: October 21, 2026 at 01:20 PM UTC
1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.5
Exploit prediction
EPSS 0.6%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gssx_dec_option_array error path bugs Four coupled defects in the gssx XDR option-array decoder make the error paths unsafe: a NULL deref in the caller, a refcount leak on the decoded group_info, and a latent use-after-free that the leak fix would otherwise expose. gssx_dec_option_array() sets oa->count = 1 before allocating oa->data. If that allocation fails, -ENOMEM is returned with oa->count == 1 and oa->data == NULL. All other error paths jump to free_oa: which frees oa->data and NULLs it but also leaves oa->count == 1. The caller trusts the count: gssp_accept_sec_context_upcall() gssx_dec_accept_sec_context() gssx_dec_option_array() /* fails, count=1 data=NULL */ data = res.options.data[0].value /* NULL deref */ Independently, free_creds: releases the partially decoded svc_cred with a bare kfree(creds). gssx_dec_linux_creds() installs a groups_alloc() result into creds->cr_group_info; that object is kvmalloc-backed and refcounted, and only put_group_info() reaches kvfree(). A plain kfree(creds) drops the wrapper and leaks the group_info allocation. The natural fix for the leak is to call free_svc_cred(creds) before kfree(creds), but free_svc_cred() invokes put_group_info() on creds->cr_group_info unconditionally when non-NULL. The existing out_free_groups: path in gssx_dec_linux_creds() already called groups_free() on that pointer without clearing it, so once free_svc_cred() is wired in, the subsequent put_group_info() would touch freed memory. Fix all four together: - Move the oa->count = 1 assignment below the oa->data allocation so it is never set when oa->data is NULL. - Reset oa->count to 0 at free_oa: so count and data stay coherent and the caller sees an empty option array. - Call free_svc_cred(creds) before kfree(creds) at free_creds: so the refcounted cr_group_info is released. free_svc_cred() either NULL-guards each field explicitly (cr_group_info has an if() check) or delegates to a helper that is NULL-safe itself (kfree for the string fields, gss_mech_put() which guards with if(gm) at gss_mech_switch.c:342), so it is safe to call on a partially decoded svc_cred where only cr_uid/cr_gid/cr_group_info have been written and everything else is zero from kzalloc. - In gssx_dec_linux_creds()'s out_free_groups: path, release cr_group_info with put_group_info() rather than groups_free() so the teardown matches free_svc_cred()'s refcount-aware path, and clear the pointer so a later free_svc_cred() on the same creds does not release it a second time.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

3cfcfc102a5e57b021b786a755a38935e357797d4.19.3115.10.2145.15.1535.4.2735e6013ae2c8d420faea553d363935f65badd32c36.1.836.6.236.7.116.8.26.9934212a623cbab851848b6de377eb476718c3e4c9806c2393cd2ab0a8e7bb9ffae02ce20e3112ec4996997d1fb2126feda550d6adcedcbd94911fc69b97c37978ca825557d331c9012e0c1ddc0e42364bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8dd292e884c649f9b1c18af0ec75ca90b390cd044
Vendor states this is fixed in 3ff45361e9469e85c0f86b8e7b82c63e50bab8ef (fixed)
Vendor states this is fixed in 5e9a94539b1ec17a89177d952badfd0d844d694a (fixed)
Vendor states this is fixed in f85a83774d7f4e2ac71c0c384df0dfb6f7d0179a (fixed)
Vendor states this is fixed in fb30241f7ccace372ee83017891549f23a715581 (fixed)
Affected range stops below 4.20, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.11, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.16, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.5, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.12.111 (unaffected)
Vendor states this is fixed in 6.18.51 (unaffected)
Affected range stops below 6.2, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.6.160 (unaffected)
Affected range stops below 6.7, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.8, so it looks safe — our inference, not a vendor statement
Vendor states this is fixed in 6.9 (unaffected)
Vendor states this is fixed in 7.2.4 (unaffected)
Vendor states this is fixed in 7.3 (unaffected)
Vendor states this is fixed in 7.3-rc1 (unaffected)

Remediation

No guide yet

No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.

SSVC — Action Prioritization

SSVCNo known exploitAutomatablePartial impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

7.5HIGHLinux
Vector?

Quick Info

StatusRECEIVED

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card