GHSA-4VQ6-C2M7-38VX
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
net: bridge: fix soft lockup in br_multicast_query_expired()
When set multicast_query_interval to a large value, the local variable 'time' in br_multicast_send_query() may overflow. If the time is smaller than jiffies, the timer will expire immediately, and then call mod_timer() again, which creates a loop and may trigger the following soft lockup issue.
watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90
This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 up
The multicast_startup_query_interval can also cause this issue. Similar to the commit 99b40610956a ("net: bridge: mcast: add and enforce query interval minimum"), add check for the query interval maximum to fix this issue.
{
"affected": [],
"aliases": [
"CVE-2025-39773"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:43Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix soft lockup in br_multicast_query_expired()\n\nWhen set multicast_query_interval to a large value, the local variable\n\u0027time\u0027 in br_multicast_send_query() may overflow. If the time is smaller\nthan jiffies, the timer will expire immediately, and then call mod_timer()\nagain, which creates a loop and may trigger the following soft lockup\nissue.\n\n watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66]\n CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none)\n Call Trace:\n \u003cIRQ\u003e\n __netdev_alloc_skb+0x2e/0x3a0\n br_ip6_multicast_alloc_query+0x212/0x1b70\n __br_multicast_send_query+0x376/0xac0\n br_multicast_send_query+0x299/0x510\n br_multicast_query_expired.constprop.0+0x16d/0x1b0\n call_timer_fn+0x3b/0x2a0\n __run_timers+0x619/0x950\n run_timer_softirq+0x11c/0x220\n handle_softirqs+0x18e/0x560\n __irq_exit_rcu+0x158/0x1a0\n sysvec_apic_timer_interrupt+0x76/0x90\n \u003c/IRQ\u003e\n\nThis issue can be reproduced with:\n ip link add br0 type bridge\n echo 1 \u003e /sys/class/net/br0/bridge/multicast_querier\n echo 0xffffffffffffffff \u003e\n \t/sys/class/net/br0/bridge/multicast_query_interval\n ip link set dev br0 up\n\nThe multicast_startup_query_interval can also cause this issue. Similar to\nthe commit 99b40610956a (\"net: bridge: mcast: add and enforce query\ninterval minimum\"), add check for the query interval maximum to fix this\nissue.",
"id": "GHSA-4vq6-c2m7-38vx",
"modified": "2026-07-14T15:31:27Z",
"published": "2025-09-11T18:35:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39773"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34171b9e53bd1dc264f5556579f2b04f04435c73"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43e281fde5e76a866a4d10780c35023f16c0e432"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5bf5fce8a0c2a70d063af778fdb5b27238174cdd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/96476b043efb86a94f2badd260f7f99c97bd5893"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bdb19cd0de739870bb3494c815138b9dc30875c4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1547bf460baec718b3398365f8de33d25c5f36f"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.