https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Wed, 30 Sep 2026 07:47:49 +0000 https://vulnerability.circl.lu/vuln/cve-2025-21781 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>batman-adv: fix panic during interface removal</p> <p>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.</p> <p>But there isn&#39;t a guarantee that the hard if will remain associated with a soft interface up until the work is finished.</p> <p>This fixes a crash triggered by reboot that looks like this:</p> <p>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</p> <p>(the batadv_v_mesh_free call is misleading, and does not actually happen)</p> <p>I was able to make the issue happen more reliably by changing hardif_neigh-&gt;bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix.</p> <p>[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>batman-adv: fix panic during interface removal</p> <p>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.</p> <p>But there isn&#39;t a guarantee that the hard if will remain associated with a soft interface up until the work is finished.</p> <p>This fixes a crash triggered by reboot that looks like this:</p> <p>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</p> <p>(the batadv_v_mesh_free call is misleading, and does not actually happen)</p> <p>I was able to make the issue happen more reliably by changing hardif_neigh-&gt;bat_v.metric_work work to be delayed work. This allowed me to track down and confirm the fix.</p> <p>[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]</p> https://vulnerability.circl.lu/vuln/cve-2025-21781