vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()
In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix use-after-free in vxlan_mdb_flush() vxlan_mdb_flush() iterates over the MDB entries using hlist_for_each_entry_safe(), which only tolerates the removal of the current entry. Contrary to the comment above the loop, the removal of an entry can trigger the removal of another entry. Flushing the remotes of a (*, G) entry also removes the (S, G) entries that were created for its source list, once they are left without remotes: vxlan_mdb_remotes_flush() -> vxlan_mdb_remote_del() -> vxlan_mdb_remote_srcs_del() -> vxlan_mdb_remote_src_del() -> vxlan_mdb_remote_src_fwd_del() -> __vxlan_mdb_del() -> vxlan_mdb_entry_put() Such an entry can be located after the (*, G) entry in the list, as vxlan_mdb_entry_get() returns an existing entry without moving it to the head of the list. This order is obtained by adding the (S, G) entry before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition of the source otherwise fails with -EEXIST. The (S, G) entry is then the entry saved by hlist_for_each_entry_safe() and it is freed while the (*, G) entry is processed. The next iteration calls hlist_del() on it again, writing LIST_POISON1 to LIST_POISON2 [1]. Besides device deletion, the flush is also reachable from RTM_DELMDB with NLM_F_BULK. Fix by re-reading the next entry after the remotes were flushed. The current entry cannot be removed by this flush, as source lists can only be configured on (*, G) entr
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.12.110, 6.18.52, 6.6.157, 7.2.6
- CVEs
- CVE-2026-93250
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 19:34 UTC · Revision 1
Source evidence
vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()
core-osv · Original sourcePublished 24 Sept 2026, 15:51 UTC
In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix use-after-free in vxlan_mdb_flush() vxlan_mdb_flush() iterates over the MDB entries using hlist_for_each_entry_safe(), which only tolerates the removal of the current entry. Contrary to the comment above the loop, the removal of an entry can trigger the removal of another entry. Flushing the remotes of a (*, G) entry also removes the (S, G) entries that were created for its source list, once they are left without remotes: vxlan_mdb_remotes_flush() -> vxlan_mdb_remote_del() -> vxlan_mdb_remote_srcs_del() -> vxlan_mdb_remote_src_del() -> vxlan_mdb_remote_src_fwd_del() -> __vxlan_mdb_del() -> vxlan_mdb_entry_put() Such an entry can be located after the (*, G) entry in the list, as vxlan_mdb_entry_get() returns an existing entry without moving it to the head of the list. This order is obtained by adding the (S, G) entry before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition of the source otherwise fails with -EEXIST. The (S, G) entry is then the entry saved by hlist_for_each_entry_safe() and it is freed while the (*, G) entry is processed. The next iteration calls hlist_del() on it again, writing LIST_POISON1 to LIST_POISON2 [1]. Besides device deletion, the flush is also reachable from RTM_DELMDB with NLM_F_BULK. Fix by re-reading the next entry after the remotes were flushed. The current entry cannot be removed by this flush, as source lists can only be configured on (*, G) entr
osv:CVE-2026-93250
Kernel
Fixed versions: 6.6.157, 6.12.110, 6.18.52, 7.2.6
Complete source record
{
"id": "221f2cdd87d607da8e825e6eeca2d9a4be8d0ea7e7c4dec9781726efe25f4219",
"url": "https://osv.dev/vulnerability/CVE-2026-93250",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()",
"summary": "In the Linux kernel, the following vulnerability has been resolved: vxlan: mdb: Fix use-after-free in vxlan_mdb_flush() vxlan_mdb_flush() iterates over the MDB entries using hlist_for_each_entry_safe(), which only tolerates the removal of the current entry. Contrary to the comment above the loop, the removal of an entry can trigger the removal of another entry. Flushing the remotes of a (*, G) entry also removes the (S, G) entries that were created for its source list, once they are left without remotes: vxlan_mdb_remotes_flush() -> vxlan_mdb_remote_del() -> vxlan_mdb_remote_srcs_del() -> vxlan_mdb_remote_src_del() -> vxlan_mdb_remote_src_fwd_del() -> __vxlan_mdb_del() -> vxlan_mdb_entry_put() Such an entry can be located after the (*, G) entry in the list, as vxlan_mdb_entry_get() returns an existing entry without moving it to the head of the list. This order is obtained by adding the (S, G) entry before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition of the source otherwise fails with -EEXIST. The (S, G) entry is then the entry saved by hlist_for_each_entry_safe() and it is freed while the (*, G) entry is processed. The next iteration calls hlist_del() on it again, writing LIST_POISON1 to LIST_POISON2 [1]. Besides device deletion, the flush is also reachable from RTM_DELMDB with NLM_F_BULK. Fix by re-reading the next entry after the remotes were flushed. The current entry cannot be removed by this flush, as source lists can only be configured on (*, G) entr",
"evidence": "osv:CVE-2026-93250",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.6.157",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.110",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.52",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.6",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "CVE-2026-93250",
"aliases": [
"CVE-2026-93250"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "a3a48de5eade770e911d35291217bdd69ce04ef1"
},
{
"fixed": "f8a9b988e7a7bc674e74e8c901794d792c35689e"
},
{
"fixed": "c7dc26d06f90ca11bbd6114f6a62a67d038816c7"
},
{
"fixed": "3e6b705bc162fc7257645725a7d2cf6c71250318"
},
{
"fixed": "f26400b325bdc2868e40612c4804c82cf8ba6275"
},
{
"fixed": "bc2dc66a6693a78f8c1e6ca2dbebd50f16e2c366"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-93250.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.4.0"
},
{
"fixed": "6.6.157"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.110"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.52"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.2.6"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-93250.json"
}
}
],
"modified": "2026-10-28T02:30:31.704584712Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/3e6b705bc162fc7257645725a7d2cf6c71250318",
"https://git.kernel.org/stable/c/bc2dc66a6693a78f8c1e6ca2dbebd50f16e2c366",
"https://git.kernel.org/stable/c/c7dc26d06f90ca11bbd6114f6a62a67d038816c7",
"https://git.kernel.org/stable/c/f26400b325bdc2868e40612c4804c82cf8ba6275",
"https://git.kernel.org/stable/c/f8a9b988e7a7bc674e74e8c901794d792c35689e",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/93xxx/CVE-2026-93250.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-93250",
"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/93xxx/CVE-2026-93250.json"
}
},
"related_cves": [
{
"value": "CVE-2026-93250",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 498760,
"published_at": "2026-09-24T15:51:15.108+00:00"
}