In the Linux kernel, the following vulnerability has been resolved:
xfrm: fix stale skb->prev after async crypto steals a GSO segment
skbgsosegment() leaves the segment list head with ->prev pointing at the last segment, an invariant validatexmitskblist() relies on when it sets its tail pointer (tail = skb->prev).
When validatexmitxfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated. If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed. validatexmitskblist() later does tail->next = skb, writing through that stale pointer -- a use-after-free.
Repoint skb->prev at the last retained segment before returning.
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.
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - copy IV using skcipher ivsize
AFALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.
ccpaescomplete() restores AESBLOCKSIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer.
Use cryptoskcipherivsize() to copy only the algorithm's IV length.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix possible infinite loop in fib6selectpath()
Found while auditing the same pattern Sashiko reported in rt6fillnode() [1]. Apply the same fix as commit f8d8ce1b515a ("ipv6: fix possible infinite loop in fib6infousesdev()").
Writers holding tb6lock can listdelrcu(&first->fib6siblings) without waiting for RCU readers; first->fib6siblings.next then still points into the old ring and this softirq-side walker never reaches &first->fib6siblings as its terminator. fib6purgert() always WRITEONCE()s first->fib6nsiblings to 0 before listdelrcu(), so an inside-loop check is a reliable detach signal.
[1] https://sashiko.dev/#/patchset/20260526020227.4857-1-jiayuan.chen%40linux.dev