{ "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" } } } }