FKIE_CVE-2025-68319
Vulnerability from fkie_nvd - Published: 2025-12-16 16:16 - Updated: 2026-10-21 13:18| Vendor | Product | Version |
|---|
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/netconsole.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "932c0c7a7ec413399febca5fe3dddf913bb5c924",
"status": "affected",
"version": "df03f830d099f0811281a222aefdd9d400fa0b72",
"versionType": "git"
},
{
"lessThan": "ff70aa7e8cf05745fdba7258952a8bedf33ea336",
"status": "affected",
"version": "df03f830d099f0811281a222aefdd9d400fa0b72",
"versionType": "git"
},
{
"lessThan": "d7d2fcf7ae31471b4e08b7e448b8fd0ec2e06a1b",
"status": "affected",
"version": "df03f830d099f0811281a222aefdd9d400fa0b72",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/netconsole.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "6.9"
},
{
"lessThan": "6.9",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.114",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.17.*",
"status": "unaffected",
"version": "6.17.8",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.18",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetconsole: Acquire su_mutex before navigating configs hierarchy\n\nThere is a race between operations that iterate over the userdata\ncg_children list and concurrent add/remove of userdata items through\nconfigfs. The update_userdata() function iterates over the\nnt-\u003euserdata_group.cg_children list, and count_extradata_entries() also\niterates over this same list to count nodes.\n\nQuoting from Documentation/filesystems/configfs.rst:\n\u003e A subsystem can navigate the cg_children list and the ci_parent pointer\n\u003e to see the tree created by the subsystem. This can race with configfs\u0027\n\u003e management of the hierarchy, so configfs uses the subsystem mutex to\n\u003e protect modifications. Whenever a subsystem wants to navigate the\n\u003e hierarchy, it must do so under the protection of the subsystem\n\u003e mutex.\n\nWithout proper locking, if a userdata item is added or removed\nconcurrently while these functions are iterating, the list can be\naccessed in an inconsistent state. For example, the list_for_each() loop\ncan reach a node that is being removed from the list by list_del_init()\nwhich sets the nodes\u0027 .next pointer to point to itself, so the loop will\nnever end (or reach the WARN_ON_ONCE in update_userdata() ).\n\nFix this by holding the configfs subsystem mutex (su_mutex) during all\noperations that iterate over cg_children.\nThis includes:\n- userdatum_value_store() which calls update_userdata() to iterate over\n cg_children\n- All sysdata_*_enabled_store() functions which call\n count_extradata_entries() to iterate over cg_children\n\nThe su_mutex must be acquired before dynamic_netconsole_mutex to avoid\npotential lock ordering issues, as configfs operations may already hold\nsu_mutex when calling into our code."
},
{
"lang": "es",
"value": "En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:\n\nnetconsole: Adquirir su_mutex antes de navegar por la jerarqu\u00eda de configuraciones\n\nExiste una condici\u00f3n de carrera entre las operaciones que iteran sobre la lista cg_children de userdata y la adici\u00f3n/eliminaci\u00f3n concurrente de elementos de userdata a trav\u00e9s de configfs. La funci\u00f3n update_userdata() itera sobre la lista nt -\u003e userdata_group.cg_children, y count_extradata_entries() tambi\u00e9n itera sobre esta misma lista para contar nodos.\n\nCitando de Documentation/filesystems/configfs.rst:\n\u003e Un subsistema puede navegar por la lista cg_children y el puntero ci_parent para ver el \u00e1rbol creado por el subsistema. Esto puede entrar en conflicto con la gesti\u00f3n de la jerarqu\u00eda por parte de configfs, por lo que configfs utiliza el mutex del subsistema para proteger las modificaciones. Siempre que un subsistema quiera navegar por la jerarqu\u00eda, debe hacerlo bajo la protecci\u00f3n del mutex del subsistema.\n\nSin un bloqueo adecuado, si un elemento de userdata es a\u00f1adido o eliminado concurrentemente mientras estas funciones est\u00e1n iterando, la lista puede ser accedida en un estado inconsistente. Por ejemplo, el bucle list_for_each() puede alcanzar un nodo que est\u00e1 siendo eliminado de la lista por list_del_init(), lo que establece el puntero .next de los nodos para que apunte a s\u00ed mismo, por lo que el bucle nunca terminar\u00e1 (o alcanzar\u00e1 el WARN_ON_ONCE en update_userdata() ).\n\nEsto se soluciona manteniendo el mutex del subsistema configfs (su_mutex) durante todas las operaciones que iteran sobre cg_children.\nEsto incluye:\n- userdatum_value_store() que llama a update_userdata() para iterar sobre cg_children\n- Todas las funciones sysdata_*_enabled_store() que llaman a count_extradata_entries() para iterar sobre cg_children\n\nEl su_mutex debe adquirirse antes que dynamic_netconsole_mutex para evitar posibles problemas de orden de bloqueo, ya que las operaciones de configfs pueden ya mantener su_mutex al llamar a nuestro c\u00f3digo."
}
],
"id": "CVE-2025-68319",
"lastModified": "2026-10-21T13:18:22.140",
"metrics": {},
"published": "2025-12-16T16:16:11.483",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/932c0c7a7ec413399febca5fe3dddf913bb5c924"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/d7d2fcf7ae31471b4e08b7e448b8fd0ec2e06a1b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/ff70aa7e8cf05745fdba7258952a8bedf33ea336"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Deferred"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
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.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
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.