xsk: Fix fragment node deletion to prevent buffer leak
In the Linux kernel, the following vulnerability has been resolved: xsk: Fix fragment node deletion to prevent buffer leak After commit b692bf9a7543 ("xsk: Get rid of xdp_buff_xsk::xskb_list_node"), the list_node field is reused for both the xskb pool list and the buffer free list, this causes a buffer leak as described below. xp_free() checks if a buffer is already on the free list using list_empty(&xskb->list_node). When list_del() is used to remove a node from the xskb pool list, it doesn't reinitialize the node pointers. This means list_empty() will return false even after the node has been removed, causing xp_free() to incorrectly skip adding the buffer to the free list. Fix this by using list_del_init() instead of list_del() in all fragment handling paths, this ensures the list node is reinitialized after removal, allowing the list_empty() to work correctly.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.18.17, 6.19.7
- CVEs
- CVE-2026-23326
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 6 Nov 2026, 00:32 UTC · Revision 1
Source evidence
xsk: Fix fragment node deletion to prevent buffer leak
core-osv · Original sourcePublished 25 Mar 2026, 10:27 UTC
In the Linux kernel, the following vulnerability has been resolved: xsk: Fix fragment node deletion to prevent buffer leak After commit b692bf9a7543 ("xsk: Get rid of xdp_buff_xsk::xskb_list_node"), the list_node field is reused for both the xskb pool list and the buffer free list, this causes a buffer leak as described below. xp_free() checks if a buffer is already on the free list using list_empty(&xskb->list_node). When list_del() is used to remove a node from the xskb pool list, it doesn't reinitialize the node pointers. This means list_empty() will return false even after the node has been removed, causing xp_free() to incorrectly skip adding the buffer to the free list. Fix this by using list_del_init() instead of list_del() in all fragment handling paths, this ensures the list node is reinitialized after removal, allowing the list_empty() to work correctly.
osv:CVE-2026-23326
Kernel
Fixed versions: 6.18.17, 6.19.7
Complete source record
{
"id": "83998e43672254eac8d3904be95aedb8bf4a167e595eab2dee9b5c8205780cd9",
"url": "https://osv.dev/vulnerability/CVE-2026-23326",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "xsk: Fix fragment node deletion to prevent buffer leak",
"summary": "In the Linux kernel, the following vulnerability has been resolved: xsk: Fix fragment node deletion to prevent buffer leak After commit b692bf9a7543 (\"xsk: Get rid of xdp_buff_xsk::xskb_list_node\"), the list_node field is reused for both the xskb pool list and the buffer free list, this causes a buffer leak as described below. xp_free() checks if a buffer is already on the free list using list_empty(&xskb->list_node). When list_del() is used to remove a node from the xskb pool list, it doesn't reinitialize the node pointers. This means list_empty() will return false even after the node has been removed, causing xp_free() to incorrectly skip adding the buffer to the free list. Fix this by using list_del_init() instead of list_del() in all fragment handling paths, this ensures the list node is reinitialized after removal, allowing the list_empty() to work correctly.",
"evidence": "osv:CVE-2026-23326",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.18.17",
"evidence": "/affected/1/ranges"
},
{
"value": "6.19.7",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-23326",
"aliases": [
"CVE-2026-23326"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "560c974b7ccd95bb9ff20df77f6654283e45c9c6"
},
{
"fixed": "5172adf9efb8298a52f4dcdc3f98d4d9d1e06a6d"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "fd5614763805d6f386bd07cc53558f88b1b1eb62"
},
{
"fixed": "2a9ea988465ece5b6896b1bdc144170a64e84c35"
}
]
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "b692bf9a7543af7ad11a59d182a3757578f0ba53"
},
{
"fixed": "645c6d8376ad4913cbffe0e0c2cca0c4febbe596"
},
{
"fixed": "b38cbd4af5034635cff109e08788c63f956f3a69"
},
{
"fixed": "60abb0ac11dccd6b98fd9182bc5f85b621688861"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-23326.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.17"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "6.19.7"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-23326.json"
}
}
],
"modified": "2026-10-28T02:30:45.878873944Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/2a9ea988465ece5b6896b1bdc144170a64e84c35",
"https://git.kernel.org/stable/c/5172adf9efb8298a52f4dcdc3f98d4d9d1e06a6d",
"https://git.kernel.org/stable/c/60abb0ac11dccd6b98fd9182bc5f85b621688861",
"https://git.kernel.org/stable/c/645c6d8376ad4913cbffe0e0c2cca0c4febbe596",
"https://git.kernel.org/stable/c/b38cbd4af5034635cff109e08788c63f956f3a69",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/23xxx/CVE-2026-23326.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-23326",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/23xxx/CVE-2026-23326.json"
}
},
"related_cves": [
{
"value": "CVE-2026-23326",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 513510,
"published_at": "2026-03-25T10:27:19.021+00:00"
}