UBUNTU-CVE-2026-89544: Use After Free

In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix gssxdecoptionarray 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 groupinfo, and a latent use-after-free that the leak fix would otherwise expose. gssxdecoptionarray() 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 freeoa: which frees oa->data and NULLs it but also leaves oa->count == 1. The caller trusts the count: gsspacceptseccontextupcall() gssxdecacceptseccontext() gssxdecoptionarray() / fails, count=1 data=NULL / data = res.options.data[0].value / NULL deref / Independently, freecreds: releases the partially decoded svccred with a bare kfree(creds). gssxdeclinuxcreds() installs a groupsalloc() result into creds->crgroupinfo; that object is kvmalloc-backed and refcounted, and only putgroupinfo() reaches kvfree(). A plain kfree(creds) drops the wrapper and leaks the groupinfo allocation. The natural fix for the leak is to call freesvccred(creds) before kfree(creds), but freesvccred() invokes putgroupinfo() on creds->crgroupinfo unconditionally when non-NULL. The existing outfreegroups: path in gssxdeclinuxcreds() already called groupsfree() on that pointer without clearing it, so once freesvccred() is wired in, the subsequent putgroupinfo() 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 freeoa: so count and data stay coherent and the caller sees an empty option array. - Call freesvccred(creds) before kfree(creds) at freecreds: so the refcounted crgroupinfo is released. freesvccred() either NULL-guards each field explicitly (crgroupinfo has an if() check) or delegates to a helper that is NULL-safe itself (kfree for the string fields, gssmechput() which guards with if(gm) at gssmechswitch.c:342), so it is safe to call on a partially decoded svccred where only cruid/crgid/crgroupinfo have been written and everything else is zero from kzalloc. - In gssxdeclinuxcreds()'s outfreegroups: path, release crgroupinfo with putgroupinfo() rather than groupsfree() so the teardown matches freesvccred()'s refcount-aware path, and clear the pointer so a later freesvccred() on the same creds does not release it a second time.