{"dataType":"CVE_RECORD","dataVersion":"5.2","cveMetadata":{"cveId":"CVE-2026-68426","assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","state":"PUBLISHED","assignerShortName":"Linux","dateReserved":"2026-07-30T09:28:09.392Z","datePublished":"2026-08-10T12:04:46.945Z","dateUpdated":"2026-08-17T05:05:22.080Z"},"containers":{"cna":{"providerMetadata":{"orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux","dateUpdated":"2026-08-17T05:05:22.080Z"},"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: fix stale skb->prev after async crypto steals a GSO segment\n\nskb_gso_segment() leaves the segment list head with ->prev pointing at\nthe last segment, an invariant validate_xmit_skb_list() relies on when\nit sets its tail pointer (tail = skb->prev).\n\nWhen validate_xmit_xfrm() walks a GSO list and some segments are stolen\nby async crypto (->xmit() returns -EINPROGRESS), those segments are\nunlinked from the list but the head ->prev is never updated.  If the\nlast segment is the one stolen, the returned head still has ->prev\npointing at it, even though it is now owned by the crypto engine and may\nbe freed.  validate_xmit_skb_list() later does tail->next = skb, writing\nthrough that stale pointer -- a use-after-free.\n\nRepoint skb->prev at the last retained segment before returning."}],"metrics":[{"cvssV3_1":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H","baseScore":9.8,"baseSeverity":"CRITICAL"},"scenarios":[{"lang":"en","value":"AV:N - The bug is in the IPsec transmit path (validate_xmit_xfrm) which processes any skb routed into an offloaded SA, including GRO-aggregated traffic forwarded from remote hosts on an IPsec gateway; xfrm_dev_offload_ok() has no socket/local-origin requirement, so a remote peer's packet stream drives the vulnerable GSO segmentation and async-crypto steal directly.\nAC:L - The attacker drives both preconditions with traffic alone: sustained large GSO flows keep the crypto engine backlogged so ->xmit() returns -EINPROGRESS routinely, and packet volume advances xo->seq.low toward the wrap that forces segmentation; each stolen trailing segment reproduces the stale skb->prev, and the subsequent tail->next write is deterministic once it occurs.\nPR:N - On an IPsec gateway the traffic that triggers the path is forwarded from remote, unauthenticated senders — no account, credentials, or capability on the target host is needed, since the SA and offload are pre-existing administrative configuration rather than something the attacker must set up.\nUI:N - No victim action is required; the vulnerable code runs automatically in softirq context on every qualifying transmit, driven purely by the attacker's packet stream.\nS:U - The corruption is of kernel sk_buff list state within the same host kernel security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - Writing through the stale ->prev is a use-after-free on an skb whose memory the attacker can influence via heap grooming with concurrent traffic; per kernel UAF guidance this yields a high-confidentiality primitive, and the corrupted list can splice engine-owned skbs into the transmit path, exposing freed/reused memory contents on the wire.\nI:H - tail->next = skb is an attacker-influenced pointer write into freed heap memory, and the resulting skb list corruption lets live and engine-owned skbs be chained together; this is classic heap corruption that can be shaped via spraying into an arbitrary write or control-flow hijack.\nA:H - Even without full exploitation the use-after-free write and the double-ownership of a stolen segment cause list corruption, double-free/oops and kernel panic in the softirq transmit path, taking down the gateway."}]}],"affected":[{"product":"Linux","vendor":"Linux","defaultStatus":"unaffected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/xfrm/xfrm_device.c"],"versions":[{"version":"f53c723902d1ac5f0b0a11d7c9dcbff748dde74e","lessThan":"33e1b0d25ca0d2818c635ff80e6aa0d295e08a98","status":"affected","versionType":"git"},{"version":"f53c723902d1ac5f0b0a11d7c9dcbff748dde74e","lessThan":"bbca7cc3b2b4b10afbfee99b81d9ee78f5423046","status":"affected","versionType":"git"},{"version":"f53c723902d1ac5f0b0a11d7c9dcbff748dde74e","lessThan":"3f4c3919baf0944ad96580467c302bc6c7758b00","status":"affected","versionType":"git"}]},{"product":"Linux","vendor":"Linux","defaultStatus":"affected","repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","programFiles":["net/xfrm/xfrm_device.c"],"versions":[{"version":"4.16","status":"affected"},{"version":"0","lessThan":"4.16","status":"unaffected","versionType":"semver"},{"version":"6.18.42","lessThanOrEqual":"6.18.*","status":"unaffected","versionType":"semver"},{"version":"7.1.6","lessThanOrEqual":"7.1.*","status":"unaffected","versionType":"semver"},{"version":"7.2","lessThanOrEqual":"*","status":"unaffected","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"operator":"OR","negate":false,"cpeMatch":[{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"4.16","versionEndExcluding":"6.18.42"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"4.16","versionEndExcluding":"7.1.6"},{"vulnerable":true,"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionStartIncluding":"4.16","versionEndExcluding":"7.2"}]}]}],"references":[{"url":"https://git.kernel.org/stable/c/33e1b0d25ca0d2818c635ff80e6aa0d295e08a98"},{"url":"https://git.kernel.org/stable/c/bbca7cc3b2b4b10afbfee99b81d9ee78f5423046"},{"url":"https://git.kernel.org/stable/c/3f4c3919baf0944ad96580467c302bc6c7758b00"}],"title":"xfrm: fix stale skb->prev after async crypto steals a GSO segment","x_generator":{"engine":"bippy-1.2.0"}}}}