batman-adv: fix panic during interface removal
In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix panic during interface removal Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished. But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished. This fixes a crash triggered by reboot that looks like this: Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (the batadv_v_mesh_free call is misleading, and does not actually happen) I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix. [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 5.10.235, 5.15.179, 5.4.291, 6.1.129, 6.12.16, 6.13.4, 6.6.79
- CVEs
- CVE-2025-21781
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 16:14 UTC · Revision 1
Source evidence
batman-adv: fix panic during interface removal
core-osv · Original sourcePublished 27 Feb 2025, 02:18 UTC
In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix panic during interface removal Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished. But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished. This fixes a crash triggered by reboot that looks like this: Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (the batadv_v_mesh_free call is misleading, and does not actually happen) I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix. [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]
osv:CVE-2025-21781
Kernel
Fixed versions: 5.4.291, 5.10.235, 5.15.179, 6.1.129, 6.6.79, 6.12.16, 6.13.4
Complete source record
{
"id": "4e586851c3360f35505745c906dfa2306706d0d7dbff2d824f2ddb8434db08e6",
"url": "https://osv.dev/vulnerability/CVE-2025-21781",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "batman-adv: fix panic during interface removal",
"summary": "In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix panic during interface removal Reference counting is used to ensure that batadv_hardif_neigh_node and batadv_hard_iface are not freed before/during batadv_v_elp_throughput_metric_update work is finished. But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished. This fixes a crash triggered by reboot that looks like this: Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20 (the batadv_v_mesh_free call is misleading, and does not actually happen) I was able to make the issue happen more reliably by changing hardif_neigh->bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix. [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]",
"evidence": "osv:CVE-2025-21781",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "5.4.291",
"evidence": "/affected/1/ranges"
},
{
"value": "5.10.235",
"evidence": "/affected/1/ranges"
},
{
"value": "5.15.179",
"evidence": "/affected/1/ranges"
},
{
"value": "6.1.129",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.79",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.16",
"evidence": "/affected/1/ranges"
},
{
"value": "6.13.4",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2025-21781",
"aliases": [
"CVE-2025-21781"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "c833484e5f3872a38fe232c663586069d5ad9645"
},
{
"fixed": "167422a07096a6006599067c8b55884064fa0b72"
},
{
"fixed": "ce3f1545bf8fa28bd05ec113679e8e6cd23af577"
},
{
"fixed": "f0a16c6c79768180333f3e41ce63f32730e3c3af"
},
{
"fixed": "7eb5dd201695645af071592a50026eb780081a72"
},
{
"fixed": "072b2787321903287a126c148e8db87dd7ef96fe"
},
{
"fixed": "2c3fb7df4cc6d043f70d4a8a10f8b915bbfb75e7"
},
{
"fixed": "522b1596ea19e327853804da2de60aeb9c5d6f42"
},
{
"fixed": "ccb7276a6d26d6f8416e315b43b45e15ee7f29e2"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-21781.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.6.0"
},
{
"fixed": "5.4.291"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.5.0"
},
{
"fixed": "5.10.235"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.11.0"
},
{
"fixed": "5.15.179"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "5.16.0"
},
{
"fixed": "6.1.129"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.79"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.16"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.13.4"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2025-21781.json"
}
}
],
"modified": "2026-10-28T02:30:37.285496442Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/072b2787321903287a126c148e8db87dd7ef96fe",
"https://git.kernel.org/stable/c/167422a07096a6006599067c8b55884064fa0b72",
"https://git.kernel.org/stable/c/2c3fb7df4cc6d043f70d4a8a10f8b915bbfb75e7",
"https://git.kernel.org/stable/c/522b1596ea19e327853804da2de60aeb9c5d6f42",
"https://git.kernel.org/stable/c/7eb5dd201695645af071592a50026eb780081a72",
"https://git.kernel.org/stable/c/ccb7276a6d26d6f8416e315b43b45e15ee7f29e2",
"https://git.kernel.org/stable/c/ce3f1545bf8fa28bd05ec113679e8e6cd23af577",
"https://git.kernel.org/stable/c/f0a16c6c79768180333f3e41ce63f32730e3c3af",
"https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html",
"https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/21xxx/CVE-2025-21781.json",
"https://nvd.nist.gov/vuln/detail/CVE-2025-21781",
"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/2025/21xxx/CVE-2025-21781.json"
}
},
"related_cves": [
{
"value": "CVE-2025-21781",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 504553,
"published_at": "2025-02-27T02:18:24.013+00:00"
}