Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-56599 (GCVE-0-2024-56599)
Vulnerability from cvelistv5 – Published: 2024-12-27 14:51 – Updated: 2026-05-11 20:55| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5 , < 27d5d217ae7ffb99dd623375a17a7d3418d9c755
(git)
Affected: 5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5 , < 27fda36eedad9e4ec795dc481f307901d1885112 (git) Affected: 5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5 , < 6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921 (git) Affected: 5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5 , < b35de9e01fc79c7baac666fb2dcb4ba7698a1d97 (git) Affected: 5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5 , < 543c0924d446b21f35701ca084d7feca09511220 (git) Affected: 5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5 , < 95c38953cb1ecf40399a676a1f85dfe2b5780a9a (git) |
guessed | |
| Linux | Linux |
Affected:
3.11
Unaffected: 0 , < 3.11 (semver) Unaffected: 5.10.237 , ≤ 5.10.* (semver) Unaffected: 5.15.181 , ≤ 5.15.* (semver) Unaffected: 6.1.127 , ≤ 6.1.* (semver) Unaffected: 6.6.70 , ≤ 6.6.* (semver) Unaffected: 6.12.5 , ≤ 6.12.* (semver) Unaffected: 6.13 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T20:50:35.314Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/ath/ath10k/sdio.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "27d5d217ae7ffb99dd623375a17a7d3418d9c755",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "27fda36eedad9e4ec795dc481f307901d1885112",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "b35de9e01fc79c7baac666fb2dcb4ba7698a1d97",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "543c0924d446b21f35701ca084d7feca09511220",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "95c38953cb1ecf40399a676a1f85dfe2b5780a9a",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/ath/ath10k/sdio.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.11"
},
{
"lessThan": "3.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.237",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.181",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.127",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.70",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.237",
"versionStartIncluding": "3.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.181",
"versionStartIncluding": "3.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.127",
"versionStartIncluding": "3.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.70",
"versionStartIncluding": "3.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.5",
"versionStartIncluding": "3.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13",
"versionStartIncluding": "3.11",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0027rmmod ath10k\u0027, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0027rmmod ath10k\u0027, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n -\u003eath10k_core_unregister\n \u2026\u2026\n -\u003eath10k_core_stop\n -\u003eath10k_hif_stop\n -\u003eath10k_sdio_irq_disable\n -\u003eath10k_hif_power_down\n -\u003edel_timer_sync(\u0026ar_sdio-\u003esleep_timer)\n -\u003eath10k_core_destroy\n -\u003eath10k_mac_destroy\n -\u003eieee80211_free_hw\n -\u003ewiphy_free\n \u2026\u2026\n -\u003ewiphy_dev_release\n -\u003edestroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0027t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189"
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T20:55:34.718Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/27d5d217ae7ffb99dd623375a17a7d3418d9c755"
},
{
"url": "https://git.kernel.org/stable/c/27fda36eedad9e4ec795dc481f307901d1885112"
},
{
"url": "https://git.kernel.org/stable/c/6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921"
},
{
"url": "https://git.kernel.org/stable/c/b35de9e01fc79c7baac666fb2dcb4ba7698a1d97"
},
{
"url": "https://git.kernel.org/stable/c/543c0924d446b21f35701ca084d7feca09511220"
},
{
"url": "https://git.kernel.org/stable/c/95c38953cb1ecf40399a676a1f85dfe2b5780a9a"
}
],
"title": "wifi: ath10k: avoid NULL pointer error during sdio remove",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-56599",
"datePublished": "2024-12-27T14:51:05.866Z",
"dateReserved": "2024-12-27T14:03:06.011Z",
"dateUpdated": "2026-05-11T20:55:34.718Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-56599",
"date": "2026-09-16",
"epss": "0.00234",
"percentile": "0.14492"
},
"microsoft_vex": {
"current_release_date": "2026-02-18T01:33:21.000Z",
"cve": "CVE-2024-56599",
"id": "msrc_CVE-2024-56599",
"initial_release_date": "2024-12-02T00:00:00.000Z",
"product_status:fixed": "4",
"product_status:known_affected": "4",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "wifi: ath10k: avoid NULL pointer error during sdio remove",
"url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2024-56599.json",
"version": "2"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2024-56599\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2024-12-27T15:15:19.307\",\"lastModified\":\"2026-06-17T08:12:30.777\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nwifi: ath10k: avoid NULL pointer error during sdio remove\\n\\nWhen running \u0027rmmod ath10k\u0027, ath10k_sdio_remove() will free sdio\\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\\nis set to yes, kernel panic will happen:\\nCall trace:\\n destroy_workqueue+0x1c/0x258\\n ath10k_sdio_remove+0x84/0x94\\n sdio_bus_remove+0x50/0x16c\\n device_release_driver_internal+0x188/0x25c\\n device_driver_detach+0x20/0x2c\\n\\nThis is because during \u0027rmmod ath10k\u0027, ath10k_sdio_remove() will call\\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\\nwill finally be called in ath10k_core_destroy(). This function will free\\nstruct cfg80211_registered_device *rdev and all its members, including\\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\\n\\nAfter device release, destroy_workqueue() will use NULL pointer then the\\nkernel panic happen.\\n\\nCall trace:\\nath10k_sdio_remove\\n -\u003eath10k_core_unregister\\n \u2026\u2026\\n -\u003eath10k_core_stop\\n -\u003eath10k_hif_stop\\n -\u003eath10k_sdio_irq_disable\\n -\u003eath10k_hif_power_down\\n -\u003edel_timer_sync(\u0026ar_sdio-\u003esleep_timer)\\n -\u003eath10k_core_destroy\\n -\u003eath10k_mac_destroy\\n -\u003eieee80211_free_hw\\n -\u003ewiphy_free\\n \u2026\u2026\\n -\u003ewiphy_dev_release\\n -\u003edestroy_workqueue\\n\\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\\nthe work queue buffer first and then free pointer of work queue by\\nath10k_core_destroy(). This order matches the error path order in\\nath10k_sdio_probe().\\n\\nNo work will be queued on sdio workqueue between it is destroyed and\\nath10k_core_destroy() is called. Based on the call_stack above, the\\nreason is:\\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\\nSleep timer will be deleted before ath10k_core_destroy() in\\nath10k_hif_power_down().\\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\\nbus, so ath10k_sdio_hif_tx_sg() won\u0027t be called anymore.\\n\\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath10k: evitar error de puntero NULL durante la eliminaci\u00f3n de sdio Al ejecutar \u0027rmmod ath10k\u0027, ath10k_sdio_remove() liberar\u00e1 la cola de trabajo de sdio mediante destroy_workqueue(). Pero si CONFIG_INIT_ON_FREE_DEFAULT_ON est\u00e1 configurado en s\u00ed, se producir\u00e1 un p\u00e1nico del kernel: Rastreo de llamada: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c Esto se debe a que durante \u0027rmmod ath10k\u0027, ath10k_sdio_remove() llamar\u00e1 a ath10k_core_destroy() antes de destroy_workqueue(). wiphy_dev_release() finalmente se llamar\u00e1 en ath10k_core_destroy(). Esta funci\u00f3n liberar\u00e1 la estructura cfg80211_registered_device *rdev y todos sus miembros, incluidos wiphy, dev y el puntero de sdio workqueue. Luego, el puntero de sdio workqueue se establecer\u00e1 en NULL debido a CONFIG_INIT_ON_FREE_DEFAULT_ON. Despu\u00e9s de liberar el dispositivo, destroy_workqueue() usar\u00e1 el puntero NULL y luego se producir\u00e1 el p\u00e1nico del kernel. Rastreo de llamadas: ath10k_sdio_remove -\u0026gt;ath10k_core_unregister \u2026\u2026 -\u0026gt;ath10k_core_stop -\u0026gt;ath10k_hif_stop -\u0026gt;ath10k_sdio_irq_disable -\u0026gt;ath10k_hif_power_down -\u0026gt;del_timer_sync(\u0026amp;ar_sdio-\u0026gt;sleep_timer) -\u0026gt;ath10k_core_destroy -\u0026gt;ath10k_mac_destroy -\u0026gt;ieee80211_free_hw -\u0026gt;wiphy_free \u2026\u2026 -\u0026gt;wiphy_dev_release -\u0026gt;destroy_workqueue Es necesario llamar a destroy_workqueue() antes de ath10k_core_destroy(), primero liberar el b\u00fafer de la cola de trabajo y luego liberar el puntero de la cola de trabajo mediante ath10k_core_destroy(). Este orden coincide con el orden de la ruta de error en ath10k_sdio_probe(). No se pondr\u00e1 en cola ning\u00fan trabajo en la cola de trabajo de sdio entre su destrucci\u00f3n y la llamada a ath10k_core_destroy(). Seg\u00fan la pila de llamadas anterior, el motivo es el siguiente: solo ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() y ath10k_sdio_irq_disable() pondr\u00e1n en cola el trabajo en la cola de trabajo de sdio. El temporizador de suspensi\u00f3n se eliminar\u00e1 antes de ath10k_core_destroy() en ath10k_hif_power_down(). ath10k_sdio_irq_disable() solo se llamar\u00e1 en ath10k_hif_stop(). ath10k_core_unregister() llamar\u00e1 a ath10k_hif_power_down() para detener el bus hif, por lo que ya no se llamar\u00e1 ath10k_sdio_hif_tx_sg(). Probado en: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"drivers/net/wireless/ath/ath10k/sdio.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5\",\"lessThan\":\"27d5d217ae7ffb99dd623375a17a7d3418d9c755\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5\",\"lessThan\":\"27fda36eedad9e4ec795dc481f307901d1885112\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5\",\"lessThan\":\"6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5\",\"lessThan\":\"b35de9e01fc79c7baac666fb2dcb4ba7698a1d97\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5\",\"lessThan\":\"543c0924d446b21f35701ca084d7feca09511220\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5\",\"lessThan\":\"95c38953cb1ecf40399a676a1f85dfe2b5780a9a\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"drivers/net/wireless/ath/ath10k/sdio.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"3.11\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"3.11\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.10.237\",\"lessThanOrEqual\":\"5.10.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.181\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.127\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.70\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.5\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.13\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-476\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"6.12.5\",\"matchCriteriaId\":\"75E05E0A-C898-433A-8E50-6D9EC8646A64\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/27d5d217ae7ffb99dd623375a17a7d3418d9c755\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/27fda36eedad9e4ec795dc481f307901d1885112\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/543c0924d446b21f35701ca084d7feca09511220\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/95c38953cb1ecf40399a676a1f85dfe2b5780a9a\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b35de9e01fc79c7baac666fb2dcb4ba7698a1d97\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\"}]}}",
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2025-11-21T13:58:29+00:00",
"cve": "CVE-2024-56599",
"id": "CVE-2024-56599",
"initial_release_date": "2024-12-27T00:00:00+00:00",
"product_status:known_not_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: wifi: ath10k: avoid NULL pointer error during sdio remove",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-56599.json",
"version": "3"
}
}
}
CERTFR-2025-AVI-0559
Vulnerability from certfr_avis - Published: 2025-07-04 - Updated: 2025-07-04
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et une atteinte à la confidentialité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.04",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.10",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2022-3640",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3640"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2021-47211",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47211"
},
{
"name": "CVE-2021-47260",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47260"
},
{
"name": "CVE-2023-52664",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52664"
},
{
"name": "CVE-2021-47576",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47576"
},
{
"name": "CVE-2024-36945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
},
{
"name": "CVE-2024-42230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42230"
},
{
"name": "CVE-2024-46812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46812"
},
{
"name": "CVE-2024-46821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46821"
},
{
"name": "CVE-2024-46753",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46753"
},
{
"name": "CVE-2024-46787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46787"
},
{
"name": "CVE-2024-49958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49958"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2024-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50116"
},
{
"name": "CVE-2024-50157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50157"
},
{
"name": "CVE-2024-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53051"
},
{
"name": "CVE-2024-53144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53144"
},
{
"name": "CVE-2024-8805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8805"
},
{
"name": "CVE-2024-53222",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53222"
},
{
"name": "CVE-2024-56551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56551"
},
{
"name": "CVE-2024-56599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56599"
},
{
"name": "CVE-2024-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53168"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-56664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56664"
},
{
"name": "CVE-2024-56608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56608"
},
{
"name": "CVE-2025-21666",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21666"
},
{
"name": "CVE-2025-21669",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21669"
},
{
"name": "CVE-2025-21670",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21670"
},
{
"name": "CVE-2025-21674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21674"
},
{
"name": "CVE-2025-21675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21675"
},
{
"name": "CVE-2025-21676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21676"
},
{
"name": "CVE-2025-21678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21678"
},
{
"name": "CVE-2025-21682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21682"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2024-57948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57948"
},
{
"name": "CVE-2025-21647",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21647"
},
{
"name": "CVE-2025-21665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21665"
},
{
"name": "CVE-2025-21667",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21667"
},
{
"name": "CVE-2025-21668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21668"
},
{
"name": "CVE-2025-21680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21680"
},
{
"name": "CVE-2025-21681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21681"
},
{
"name": "CVE-2025-21683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21683"
},
{
"name": "CVE-2025-21673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21673"
},
{
"name": "CVE-2024-47726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47726"
},
{
"name": "CVE-2024-56721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56721"
},
{
"name": "CVE-2025-21684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21684"
},
{
"name": "CVE-2025-21689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21689"
},
{
"name": "CVE-2025-21690",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21690"
},
{
"name": "CVE-2025-21692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21692"
},
{
"name": "CVE-2025-21697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21697"
},
{
"name": "CVE-2025-21699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21699"
},
{
"name": "CVE-2024-57949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57949"
},
{
"name": "CVE-2024-57951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57951"
},
{
"name": "CVE-2025-21694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21694"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2025-21715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21715"
},
{
"name": "CVE-2025-21719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21719"
},
{
"name": "CVE-2025-21728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21728"
},
{
"name": "CVE-2025-21753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21753"
},
{
"name": "CVE-2025-21767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21767"
},
{
"name": "CVE-2025-21795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21795"
},
{
"name": "CVE-2025-21799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21799"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2025-21772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21772"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2024-57924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57924"
},
{
"name": "CVE-2024-57834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57834"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2024-57978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57978"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-57981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57981"
},
{
"name": "CVE-2024-57986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57986"
},
{
"name": "CVE-2024-58001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58001"
},
{
"name": "CVE-2024-58007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58007"
},
{
"name": "CVE-2024-58010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58010"
},
{
"name": "CVE-2024-58016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58016"
},
{
"name": "CVE-2024-58017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58017"
},
{
"name": "CVE-2024-58020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58020"
},
{
"name": "CVE-2024-58034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58034"
},
{
"name": "CVE-2024-58051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58051"
},
{
"name": "CVE-2024-58052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58052"
},
{
"name": "CVE-2024-58055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58055"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2024-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58063"
},
{
"name": "CVE-2024-58069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58069"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2024-58076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58076"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2024-58085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58085"
},
{
"name": "CVE-2024-58086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58086"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2025-21707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21707"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-21711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21711"
},
{
"name": "CVE-2025-21722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21722"
},
{
"name": "CVE-2025-21726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21726"
},
{
"name": "CVE-2025-21727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21727"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-21736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21736"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2025-21745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21745"
},
{
"name": "CVE-2025-21748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21748"
},
{
"name": "CVE-2025-21749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21749"
},
{
"name": "CVE-2025-21758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21758"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2025-21761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21761"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2025-21764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21764"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2025-21766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21766"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21779"
},
{
"name": "CVE-2025-21781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21781"
},
{
"name": "CVE-2025-21782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21782"
},
{
"name": "CVE-2025-21787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21787"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-21804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21804"
},
{
"name": "CVE-2025-21806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21806"
},
{
"name": "CVE-2025-21811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21811"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21820"
},
{
"name": "CVE-2025-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21823"
},
{
"name": "CVE-2025-21826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21826"
},
{
"name": "CVE-2025-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21830"
},
{
"name": "CVE-2025-21835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21835"
},
{
"name": "CVE-2023-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52927"
},
{
"name": "CVE-2024-58002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58002"
},
{
"name": "CVE-2024-58005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58005"
},
{
"name": "CVE-2024-58079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58079"
},
{
"name": "CVE-2025-21844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21844"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2025-21848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21848"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2025-21859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21859"
},
{
"name": "CVE-2025-21862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21862"
},
{
"name": "CVE-2025-21865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21865"
},
{
"name": "CVE-2025-21866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21866"
},
{
"name": "CVE-2025-21871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21871"
},
{
"name": "CVE-2025-21877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21877"
},
{
"name": "CVE-2025-21878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21878"
},
{
"name": "CVE-2024-57977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57977"
},
{
"name": "CVE-2024-58090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58090"
},
{
"name": "CVE-2025-21721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21721"
},
{
"name": "CVE-2025-21875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21875"
},
{
"name": "CVE-2025-21887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21887"
},
{
"name": "CVE-2025-21898",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21898"
},
{
"name": "CVE-2025-21904",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21904"
},
{
"name": "CVE-2025-21905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21905"
},
{
"name": "CVE-2025-21909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21909"
},
{
"name": "CVE-2025-21910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21910"
},
{
"name": "CVE-2025-21912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21912"
},
{
"name": "CVE-2025-21913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21913"
},
{
"name": "CVE-2025-21914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21914"
},
{
"name": "CVE-2025-21916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21916"
},
{
"name": "CVE-2025-21917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21917"
},
{
"name": "CVE-2025-21918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21918"
},
{
"name": "CVE-2025-21919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21919"
},
{
"name": "CVE-2025-21920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21920"
},
{
"name": "CVE-2025-21922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21922"
},
{
"name": "CVE-2025-21924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21924"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2025-21928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21928"
},
{
"name": "CVE-2025-21934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21934"
},
{
"name": "CVE-2025-21935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21935"
},
{
"name": "CVE-2025-21936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21936"
},
{
"name": "CVE-2025-21937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21937"
},
{
"name": "CVE-2025-21941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21941"
},
{
"name": "CVE-2025-21943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21943"
},
{
"name": "CVE-2025-21944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21944"
},
{
"name": "CVE-2025-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21945"
},
{
"name": "CVE-2025-21947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21947"
},
{
"name": "CVE-2025-21948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21948"
},
{
"name": "CVE-2025-21950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21950"
},
{
"name": "CVE-2025-21951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21951"
},
{
"name": "CVE-2025-21956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21956"
},
{
"name": "CVE-2025-21957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21957"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2025-21960",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21960"
},
{
"name": "CVE-2025-21962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21962"
},
{
"name": "CVE-2025-21963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21963"
},
{
"name": "CVE-2025-21964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21964"
},
{
"name": "CVE-2025-21968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21968"
},
{
"name": "CVE-2025-21970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21970"
},
{
"name": "CVE-2025-21971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21971"
},
{
"name": "CVE-2025-21975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21975"
},
{
"name": "CVE-2025-21978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21978"
},
{
"name": "CVE-2025-21979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21979"
},
{
"name": "CVE-2025-21980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21980"
},
{
"name": "CVE-2025-21981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21981"
},
{
"name": "CVE-2025-21986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21986"
},
{
"name": "CVE-2025-21991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21991"
},
{
"name": "CVE-2025-21992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21992"
},
{
"name": "CVE-2025-21993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21993"
},
{
"name": "CVE-2025-21994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21994"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-21997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21997"
},
{
"name": "CVE-2025-21999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21999"
},
{
"name": "CVE-2025-22004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22004"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2025-22008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22008"
},
{
"name": "CVE-2025-22010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22010"
},
{
"name": "CVE-2025-22014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22014"
},
{
"name": "CVE-2025-22015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22015"
},
{
"name": "CVE-2025-21969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21969"
},
{
"name": "CVE-2024-57952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57952"
},
{
"name": "CVE-2025-21672",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21672"
},
{
"name": "CVE-2025-21691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21691"
},
{
"name": "CVE-2025-2312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2312"
},
{
"name": "CVE-2025-21927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21927"
},
{
"name": "CVE-2023-53034",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53034"
},
{
"name": "CVE-2025-22025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22025"
},
{
"name": "CVE-2025-22027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22027"
},
{
"name": "CVE-2025-22033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22033"
},
{
"name": "CVE-2025-22035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22035"
},
{
"name": "CVE-2025-22038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22038"
},
{
"name": "CVE-2025-22040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22040"
},
{
"name": "CVE-2025-22041",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22041"
},
{
"name": "CVE-2025-22042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22042"
},
{
"name": "CVE-2025-22044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22044"
},
{
"name": "CVE-2025-22045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22045"
},
{
"name": "CVE-2025-22050",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22050"
},
{
"name": "CVE-2025-22054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22054"
},
{
"name": "CVE-2025-22055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22055"
},
{
"name": "CVE-2025-22056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22056"
},
{
"name": "CVE-2025-22058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22058"
},
{
"name": "CVE-2025-22060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22060"
},
{
"name": "CVE-2025-22063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22063"
},
{
"name": "CVE-2025-22066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22066"
},
{
"name": "CVE-2025-22071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22071"
},
{
"name": "CVE-2025-22072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22072"
},
{
"name": "CVE-2025-22073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22073"
},
{
"name": "CVE-2025-22075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22075"
},
{
"name": "CVE-2025-22079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22079"
},
{
"name": "CVE-2025-22081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22081"
},
{
"name": "CVE-2025-22086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22086"
},
{
"name": "CVE-2025-22088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22088"
},
{
"name": "CVE-2025-22089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22089"
},
{
"name": "CVE-2025-22093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22093"
},
{
"name": "CVE-2025-22095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22095"
},
{
"name": "CVE-2025-22097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22097"
},
{
"name": "CVE-2025-22126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22126"
},
{
"name": "CVE-2025-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23136"
},
{
"name": "CVE-2025-23138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23138"
},
{
"name": "CVE-2025-37785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37785"
},
{
"name": "CVE-2025-37838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37838"
},
{
"name": "CVE-2025-38152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38152"
},
{
"name": "CVE-2025-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38575"
},
{
"name": "CVE-2025-38637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38637"
},
{
"name": "CVE-2025-39728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39728"
},
{
"name": "CVE-2025-39735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39735"
},
{
"name": "CVE-2025-21902",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21902"
},
{
"name": "CVE-2022-49728",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49728"
},
{
"name": "CVE-2024-58093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58093"
},
{
"name": "CVE-2024-58094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58094"
},
{
"name": "CVE-2024-58095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58095"
},
{
"name": "CVE-2024-58096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58096"
},
{
"name": "CVE-2024-58097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58097"
},
{
"name": "CVE-2025-21894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21894"
},
{
"name": "CVE-2025-21906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21906"
},
{
"name": "CVE-2025-21908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21908"
},
{
"name": "CVE-2025-21915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21915"
},
{
"name": "CVE-2025-21923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21923"
},
{
"name": "CVE-2025-21930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21930"
},
{
"name": "CVE-2025-21961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21961"
},
{
"name": "CVE-2025-21966",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21966"
},
{
"name": "CVE-2025-21972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21972"
},
{
"name": "CVE-2025-21995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21995"
},
{
"name": "CVE-2025-22001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22001"
},
{
"name": "CVE-2025-22003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22003"
},
{
"name": "CVE-2025-22009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22009"
},
{
"name": "CVE-2025-22013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22013"
},
{
"name": "CVE-2025-22016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22016"
},
{
"name": "CVE-2025-22017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22017"
},
{
"name": "CVE-2025-22018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22018"
},
{
"name": "CVE-2025-22020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22020"
},
{
"name": "CVE-2025-22036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22036"
},
{
"name": "CVE-2025-22053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22053"
},
{
"name": "CVE-2025-22062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22062"
},
{
"name": "CVE-2025-22064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22064"
},
{
"name": "CVE-2025-22065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22065"
},
{
"name": "CVE-2025-22080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22080"
},
{
"name": "CVE-2025-22090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22090"
},
{
"name": "CVE-2025-22102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22102"
},
{
"name": "CVE-2025-22104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22104"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2025-22106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22106"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2025-22108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22108"
},
{
"name": "CVE-2025-22109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22109"
},
{
"name": "CVE-2025-22115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22115"
},
{
"name": "CVE-2025-22116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22116"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-22128",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22128"
},
{
"name": "CVE-2025-23129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23129"
},
{
"name": "CVE-2025-23131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23131"
},
{
"name": "CVE-2025-23133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23133"
},
{
"name": "CVE-2025-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23145"
},
{
"name": "CVE-2025-37798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37798"
},
{
"name": "CVE-2025-37799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37799"
},
{
"name": "CVE-2025-37860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37860"
},
{
"name": "CVE-2025-37749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37749"
},
{
"name": "CVE-2025-22021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22021"
},
{
"name": "CVE-2025-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23140"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2025-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23142"
},
{
"name": "CVE-2025-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23144"
},
{
"name": "CVE-2025-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23146"
},
{
"name": "CVE-2025-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23147"
},
{
"name": "CVE-2025-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23148"
},
{
"name": "CVE-2025-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23150"
},
{
"name": "CVE-2025-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23151"
},
{
"name": "CVE-2025-23156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23156"
},
{
"name": "CVE-2025-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23157"
},
{
"name": "CVE-2025-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23158"
},
{
"name": "CVE-2025-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23159"
},
{
"name": "CVE-2025-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23161"
},
{
"name": "CVE-2025-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23163"
},
{
"name": "CVE-2025-37738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37738"
},
{
"name": "CVE-2025-37739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37739"
},
{
"name": "CVE-2025-37740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37740"
},
{
"name": "CVE-2025-37741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37741"
},
{
"name": "CVE-2025-37742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37742"
},
{
"name": "CVE-2025-37748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37748"
},
{
"name": "CVE-2025-37752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37752"
},
{
"name": "CVE-2025-37756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37756"
},
{
"name": "CVE-2025-37757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37757"
},
{
"name": "CVE-2025-37758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37758"
},
{
"name": "CVE-2025-37765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37765"
},
{
"name": "CVE-2025-37766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37766"
},
{
"name": "CVE-2025-37767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37767"
},
{
"name": "CVE-2025-37768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37768"
},
{
"name": "CVE-2025-37769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37769"
},
{
"name": "CVE-2025-37770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37770"
},
{
"name": "CVE-2025-37771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37771"
},
{
"name": "CVE-2025-37772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37772"
},
{
"name": "CVE-2025-37773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37773"
},
{
"name": "CVE-2025-37775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37775"
},
{
"name": "CVE-2025-37778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37778"
},
{
"name": "CVE-2025-37780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37780"
},
{
"name": "CVE-2025-37781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37781"
},
{
"name": "CVE-2025-37787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37787"
},
{
"name": "CVE-2025-37788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37788"
},
{
"name": "CVE-2025-37789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37789"
},
{
"name": "CVE-2025-37790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37790"
},
{
"name": "CVE-2025-37792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37792"
},
{
"name": "CVE-2025-37794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37794"
},
{
"name": "CVE-2025-37796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37796"
},
{
"name": "CVE-2025-37797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37797"
},
{
"name": "CVE-2025-37801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37801"
},
{
"name": "CVE-2025-37803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37803"
},
{
"name": "CVE-2025-37805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37805"
},
{
"name": "CVE-2025-37808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37808"
},
{
"name": "CVE-2025-37810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37810"
},
{
"name": "CVE-2025-37811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37811"
},
{
"name": "CVE-2025-37812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37812"
},
{
"name": "CVE-2025-37815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37815"
},
{
"name": "CVE-2025-37817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37817"
},
{
"name": "CVE-2025-37820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37820"
},
{
"name": "CVE-2025-37823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37823"
},
{
"name": "CVE-2025-37824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37824"
},
{
"name": "CVE-2025-37829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37829"
},
{
"name": "CVE-2025-37830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37830"
},
{
"name": "CVE-2025-37836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37836"
},
{
"name": "CVE-2025-37839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37839"
},
{
"name": "CVE-2025-37840",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37840"
},
{
"name": "CVE-2025-37841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37841"
},
{
"name": "CVE-2025-37844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37844"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-37850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37850"
},
{
"name": "CVE-2025-37851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37851"
},
{
"name": "CVE-2025-37852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37852"
},
{
"name": "CVE-2025-37854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37854"
},
{
"name": "CVE-2025-37857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37857"
},
{
"name": "CVE-2025-37858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37858"
},
{
"name": "CVE-2025-37859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37859"
},
{
"name": "CVE-2025-37862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37862"
},
{
"name": "CVE-2025-37865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37865"
},
{
"name": "CVE-2025-37867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37867"
},
{
"name": "CVE-2025-37875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37875"
},
{
"name": "CVE-2025-37879",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37879"
},
{
"name": "CVE-2025-37881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37881"
},
{
"name": "CVE-2025-37883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37883"
},
{
"name": "CVE-2025-37884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37884"
},
{
"name": "CVE-2025-37885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37885"
},
{
"name": "CVE-2025-37889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37889"
},
{
"name": "CVE-2025-37892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37892"
},
{
"name": "CVE-2025-37937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37937"
},
{
"name": "CVE-2025-37938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37938"
},
{
"name": "CVE-2025-37940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37940"
},
{
"name": "CVE-2025-37979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37979"
},
{
"name": "CVE-2025-37982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37982"
},
{
"name": "CVE-2025-37983",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37983"
},
{
"name": "CVE-2025-37985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37985"
},
{
"name": "CVE-2025-37989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37989"
},
{
"name": "CVE-2025-37819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37819"
},
{
"name": "CVE-2025-37890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37890"
},
{
"name": "CVE-2025-37932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37932"
},
{
"name": "CVE-2022-49909",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49909"
},
{
"name": "CVE-2025-22030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22030"
},
{
"name": "CVE-2025-22057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22057"
},
{
"name": "CVE-2025-22070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22070"
},
{
"name": "CVE-2025-22103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22103"
},
{
"name": "CVE-2025-22125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22125"
},
{
"name": "CVE-2025-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23160"
},
{
"name": "CVE-2025-37750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37750"
},
{
"name": "CVE-2025-37755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37755"
},
{
"name": "CVE-2025-37809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37809"
},
{
"name": "CVE-2025-37831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37831"
},
{
"name": "CVE-2025-37833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37833"
},
{
"name": "CVE-2025-37842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37842"
},
{
"name": "CVE-2025-37870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37870"
},
{
"name": "CVE-2025-37886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37886"
},
{
"name": "CVE-2025-37887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37887"
},
{
"name": "CVE-2025-40325",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40325"
},
{
"name": "CVE-2025-37943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37943"
},
{
"name": "CVE-2025-21893",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21893"
},
{
"name": "CVE-2025-21929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21929"
},
{
"name": "CVE-2025-21973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21973"
},
{
"name": "CVE-2025-21974",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21974"
},
{
"name": "CVE-2025-21989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21989"
},
{
"name": "CVE-2025-21990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21990"
},
{
"name": "CVE-2025-22028",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22028"
},
{
"name": "CVE-2025-22085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22085"
},
{
"name": "CVE-2025-22091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22091"
},
{
"name": "CVE-2025-22094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22094"
},
{
"name": "CVE-2025-22112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22112"
},
{
"name": "CVE-2025-22113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22113"
},
{
"name": "CVE-2025-22117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22117"
},
{
"name": "CVE-2025-22118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22118"
},
{
"name": "CVE-2025-22119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22119"
},
{
"name": "CVE-2025-22124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22124"
},
{
"name": "CVE-2025-23134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23134"
},
{
"name": "CVE-2025-23149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23149"
},
{
"name": "CVE-2025-23154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23154"
},
{
"name": "CVE-2025-23155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23155"
},
{
"name": "CVE-2025-37743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37743"
},
{
"name": "CVE-2025-37747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37747"
},
{
"name": "CVE-2025-37754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37754"
},
{
"name": "CVE-2025-37793",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37793"
},
{
"name": "CVE-2025-37800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37800"
},
{
"name": "CVE-2025-37846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37846"
},
{
"name": "CVE-2025-37853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37853"
},
{
"name": "CVE-2025-37873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37873"
},
{
"name": "CVE-2025-37874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37874"
},
{
"name": "CVE-2025-37925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37925"
},
{
"name": "CVE-2025-37944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37944"
},
{
"name": "CVE-2025-37978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37978"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2025-37986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37986"
},
{
"name": "CVE-2025-37987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37987"
},
{
"name": "CVE-2025-38104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38104"
},
{
"name": "CVE-2025-38240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38240"
},
{
"name": "CVE-2025-40014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40014"
},
{
"name": "CVE-2022-49636",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49636"
},
{
"name": "CVE-2025-37997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37997"
},
{
"name": "CVE-2025-38000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38000"
},
{
"name": "CVE-2025-38001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38001"
},
{
"name": "CVE-2024-58092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58092"
},
{
"name": "CVE-2025-21903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21903"
},
{
"name": "CVE-2025-21911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21911"
},
{
"name": "CVE-2025-21939",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21939"
},
{
"name": "CVE-2025-21946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21946"
},
{
"name": "CVE-2025-21955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21955"
},
{
"name": "CVE-2025-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21967"
},
{
"name": "CVE-2025-21977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21977"
},
{
"name": "CVE-2025-21982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21982"
},
{
"name": "CVE-2025-21984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21984"
},
{
"name": "CVE-2025-21998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21998"
},
{
"name": "CVE-2025-22000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22000"
},
{
"name": "CVE-2025-22002",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22002"
},
{
"name": "CVE-2025-22011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22011"
},
{
"name": "CVE-2025-22019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22019"
},
{
"name": "CVE-2025-22022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22022"
},
{
"name": "CVE-2025-22023",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22023"
},
{
"name": "CVE-2025-22024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22024"
},
{
"name": "CVE-2025-22026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22026"
},
{
"name": "CVE-2025-22031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22031"
},
{
"name": "CVE-2025-22032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22032"
},
{
"name": "CVE-2025-22034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22034"
},
{
"name": "CVE-2025-22037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22037"
},
{
"name": "CVE-2025-22039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22039"
},
{
"name": "CVE-2025-22043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22043"
},
{
"name": "CVE-2025-22046",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22046"
},
{
"name": "CVE-2025-22047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22047"
},
{
"name": "CVE-2025-22051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22051"
},
{
"name": "CVE-2025-22052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22052"
},
{
"name": "CVE-2025-22059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22059"
},
{
"name": "CVE-2025-22061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22061"
},
{
"name": "CVE-2025-22067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22067"
},
{
"name": "CVE-2025-22068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22068"
},
{
"name": "CVE-2025-22069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22069"
},
{
"name": "CVE-2025-22074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22074"
},
{
"name": "CVE-2025-22076",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22076"
},
{
"name": "CVE-2025-22078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22078"
},
{
"name": "CVE-2025-22082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22082"
},
{
"name": "CVE-2025-22083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22083"
},
{
"name": "CVE-2025-22084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22084"
},
{
"name": "CVE-2025-22087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22087"
},
{
"name": "CVE-2025-22092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22092"
},
{
"name": "CVE-2025-22096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22096"
},
{
"name": "CVE-2025-22098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22098"
},
{
"name": "CVE-2025-22099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22099"
},
{
"name": "CVE-2025-22100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22100"
},
{
"name": "CVE-2025-22101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22101"
},
{
"name": "CVE-2025-22110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22110"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2025-22114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22114"
},
{
"name": "CVE-2025-22120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22120"
},
{
"name": "CVE-2025-22122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22122"
},
{
"name": "CVE-2025-22123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22123"
},
{
"name": "CVE-2025-22127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22127"
},
{
"name": "CVE-2025-23130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23130"
},
{
"name": "CVE-2025-23132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23132"
},
{
"name": "CVE-2025-23135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23135"
},
{
"name": "CVE-2025-23137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23137"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-23152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23152"
},
{
"name": "CVE-2025-23153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23153"
},
{
"name": "CVE-2025-23162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23162"
},
{
"name": "CVE-2025-37744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37744"
},
{
"name": "CVE-2025-37745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37745"
},
{
"name": "CVE-2025-37746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37746"
},
{
"name": "CVE-2025-37751",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37751"
},
{
"name": "CVE-2025-37759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37759"
},
{
"name": "CVE-2025-37760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37760"
},
{
"name": "CVE-2025-37761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37761"
},
{
"name": "CVE-2025-37762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37762"
},
{
"name": "CVE-2025-37763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37763"
},
{
"name": "CVE-2025-37764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37764"
},
{
"name": "CVE-2025-37774",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37774"
},
{
"name": "CVE-2025-37776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37776"
},
{
"name": "CVE-2025-37777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37777"
},
{
"name": "CVE-2025-37779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37779"
},
{
"name": "CVE-2025-37783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37783"
},
{
"name": "CVE-2025-37784",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37784"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2025-37791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37791"
},
{
"name": "CVE-2025-37802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37802"
},
{
"name": "CVE-2025-37806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37806"
},
{
"name": "CVE-2025-37807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37807"
},
{
"name": "CVE-2025-37813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37813"
},
{
"name": "CVE-2025-37814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37814"
},
{
"name": "CVE-2025-37816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37816"
},
{
"name": "CVE-2025-37821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37821"
},
{
"name": "CVE-2025-37822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37822"
},
{
"name": "CVE-2025-37825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37825"
},
{
"name": "CVE-2025-37826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37826"
},
{
"name": "CVE-2025-37827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37827"
},
{
"name": "CVE-2025-37828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37828"
},
{
"name": "CVE-2025-37834",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37834"
},
{
"name": "CVE-2025-37837",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37837"
},
{
"name": "CVE-2025-37843",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37843"
},
{
"name": "CVE-2025-37845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37845"
},
{
"name": "CVE-2025-37847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37847"
},
{
"name": "CVE-2025-37848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37848"
},
{
"name": "CVE-2025-37855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37855"
},
{
"name": "CVE-2025-37856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37856"
},
{
"name": "CVE-2025-37861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37861"
},
{
"name": "CVE-2025-37863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37863"
},
{
"name": "CVE-2025-37864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37864"
},
{
"name": "CVE-2025-37866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37866"
},
{
"name": "CVE-2025-37868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37868"
},
{
"name": "CVE-2025-37869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37869"
},
{
"name": "CVE-2025-37872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37872"
},
{
"name": "CVE-2025-37876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37876"
},
{
"name": "CVE-2025-37877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37877"
},
{
"name": "CVE-2025-37878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37878"
},
{
"name": "CVE-2025-37880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37880"
},
{
"name": "CVE-2025-37882",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37882"
},
{
"name": "CVE-2025-37888",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37888"
},
{
"name": "CVE-2025-37939",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37939"
},
{
"name": "CVE-2025-37941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37941"
},
{
"name": "CVE-2025-37942",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37942"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2025-37975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37975"
},
{
"name": "CVE-2025-37977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37977"
},
{
"name": "CVE-2025-37981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37981"
},
{
"name": "CVE-2025-37984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37984"
},
{
"name": "CVE-2025-37988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37988"
},
{
"name": "CVE-2025-38049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38049"
},
{
"name": "CVE-2025-38479",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38479"
},
{
"name": "CVE-2025-39688",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39688"
},
{
"name": "CVE-2025-39755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39755"
},
{
"name": "CVE-2025-39778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39778"
},
{
"name": "CVE-2025-39930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39930"
},
{
"name": "CVE-2025-39989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39989"
},
{
"name": "CVE-2025-40114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40114"
}
],
"initial_release_date": "2025-07-04T00:00:00",
"last_revision_date": "2025-07-04T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0559",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-07-04T00:00:00.000000"
}
],
"risks": [
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2025-07-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7607-2",
"url": "https://ubuntu.com/security/notices/USN-7607-2"
},
{
"published_at": "2025-06-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7595-3",
"url": "https://ubuntu.com/security/notices/USN-7595-3"
},
{
"published_at": "2025-07-03",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7585-6",
"url": "https://ubuntu.com/security/notices/USN-7585-6"
},
{
"published_at": "2025-06-30",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7605-1",
"url": "https://ubuntu.com/security/notices/USN-7605-1"
},
{
"published_at": "2025-07-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7608-3",
"url": "https://ubuntu.com/security/notices/USN-7608-3"
},
{
"published_at": "2025-06-26",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7602-1",
"url": "https://ubuntu.com/security/notices/USN-7602-1"
},
{
"published_at": "2025-06-26",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7594-2",
"url": "https://ubuntu.com/security/notices/USN-7594-2"
},
{
"published_at": "2025-06-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7596-2",
"url": "https://ubuntu.com/security/notices/USN-7596-2"
},
{
"published_at": "2025-07-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7609-1",
"url": "https://ubuntu.com/security/notices/USN-7609-1"
},
{
"published_at": "2025-06-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7585-4",
"url": "https://ubuntu.com/security/notices/USN-7585-4"
},
{
"published_at": "2025-07-03",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7608-4",
"url": "https://ubuntu.com/security/notices/USN-7608-4"
},
{
"published_at": "2025-06-30",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7606-1",
"url": "https://ubuntu.com/security/notices/USN-7606-1"
},
{
"published_at": "2025-06-26",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7595-4",
"url": "https://ubuntu.com/security/notices/USN-7595-4"
},
{
"published_at": "2025-07-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7608-2",
"url": "https://ubuntu.com/security/notices/USN-7608-2"
},
{
"published_at": "2025-07-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7607-1",
"url": "https://ubuntu.com/security/notices/USN-7607-1"
},
{
"published_at": "2025-07-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7608-1",
"url": "https://ubuntu.com/security/notices/USN-7608-1"
},
{
"published_at": "2025-07-01",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7609-2",
"url": "https://ubuntu.com/security/notices/USN-7609-2"
},
{
"published_at": "2025-06-30",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7595-5",
"url": "https://ubuntu.com/security/notices/USN-7595-5"
},
{
"published_at": "2025-06-30",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7585-5",
"url": "https://ubuntu.com/security/notices/USN-7585-5"
}
]
}
CERTFR-2025-AVI-0605
Vulnerability from certfr_avis - Published: 2025-07-18 - Updated: 2025-07-18
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une atteinte à la confidentialité des données, un contournement de la politique de sécurité et un déni de service.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.04",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2024-57981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57981"
},
{
"name": "CVE-2023-52664",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52664"
},
{
"name": "CVE-2024-58010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58010"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2024-50055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50055"
},
{
"name": "CVE-2024-58069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58069"
},
{
"name": "CVE-2025-21871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21871"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2024-58009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58009"
},
{
"name": "CVE-2023-53034",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53034"
},
{
"name": "CVE-2025-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21823"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2025-21922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21922"
},
{
"name": "CVE-2025-22021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22021"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-46787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46787"
},
{
"name": "CVE-2023-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52927"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2025-39735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39735"
},
{
"name": "CVE-2025-21904",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21904"
},
{
"name": "CVE-2025-37798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37798"
},
{
"name": "CVE-2025-22004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22004"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-21647",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21647"
},
{
"name": "CVE-2024-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58063"
},
{
"name": "CVE-2025-21948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21948"
},
{
"name": "CVE-2025-21753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21753"
},
{
"name": "CVE-2025-21993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21993"
},
{
"name": "CVE-2025-37937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37937"
},
{
"name": "CVE-2025-21715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21715"
},
{
"name": "CVE-2025-21781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21781"
},
{
"name": "CVE-2025-38637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38637"
},
{
"name": "CVE-2025-21772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21772"
},
{
"name": "CVE-2025-21914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21914"
},
{
"name": "CVE-2024-58007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58007"
},
{
"name": "CVE-2025-21728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21728"
},
{
"name": "CVE-2024-58090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58090"
},
{
"name": "CVE-2022-49636",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49636"
},
{
"name": "CVE-2025-22035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22035"
},
{
"name": "CVE-2025-21764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21764"
},
{
"name": "CVE-2024-58093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58093"
},
{
"name": "CVE-2024-58085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58085"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2025-21909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21909"
},
{
"name": "CVE-2021-47211",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47211"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2024-58017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58017"
},
{
"name": "CVE-2024-56599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56599"
},
{
"name": "CVE-2025-21910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21910"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2023-52741",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52741"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-21787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21787"
},
{
"name": "CVE-2025-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23136"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21917"
},
{
"name": "CVE-2025-21957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21957"
},
{
"name": "CVE-2025-21736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21736"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-21992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21992"
},
{
"name": "CVE-2024-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53051"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2025-22018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22018"
},
{
"name": "CVE-2025-21916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21916"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2025-21898",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21898"
},
{
"name": "CVE-2024-58051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58051"
},
{
"name": "CVE-2025-21848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21848"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2025-21935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21935"
},
{
"name": "CVE-2025-22045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22045"
},
{
"name": "CVE-2025-21866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21866"
},
{
"name": "CVE-2025-21862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21862"
},
{
"name": "CVE-2025-21719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21719"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2025-21971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21971"
},
{
"name": "CVE-2025-21806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21806"
},
{
"name": "CVE-2024-57977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57977"
},
{
"name": "CVE-2025-21928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21928"
},
{
"name": "CVE-2024-56551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56551"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2025-21934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21934"
},
{
"name": "CVE-2025-38000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38000"
},
{
"name": "CVE-2025-22071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22071"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2025-21859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21859"
},
{
"name": "CVE-2025-21956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21956"
},
{
"name": "CVE-2025-21761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21761"
},
{
"name": "CVE-2025-37932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37932"
},
{
"name": "CVE-2025-37890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37890"
},
{
"name": "CVE-2025-22020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22020"
},
{
"name": "CVE-2024-58020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58020"
},
{
"name": "CVE-2025-21721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21721"
},
{
"name": "CVE-2025-21877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21877"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2021-47191",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47191"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2025-21782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21782"
},
{
"name": "CVE-2025-22063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22063"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2025-21865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21865"
},
{
"name": "CVE-2024-58002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58002"
},
{
"name": "CVE-2025-38001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38001"
},
{
"name": "CVE-2024-26996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26996"
},
{
"name": "CVE-2024-58052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58052"
},
{
"name": "CVE-2025-21905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21905"
},
{
"name": "CVE-2025-21920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21920"
},
{
"name": "CVE-2024-58001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58001"
},
{
"name": "CVE-2024-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53168"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2024-26689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26689"
},
{
"name": "CVE-2025-37997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37997"
},
{
"name": "CVE-2025-2312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2312"
},
{
"name": "CVE-2025-21749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21749"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2025-21722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21722"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2025-22054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22054"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2024-58055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58055"
},
{
"name": "CVE-2025-21991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21991"
},
{
"name": "CVE-2025-22086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22086"
},
{
"name": "CVE-2025-22073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22073"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2025-22079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22079"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2024-57986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57986"
},
{
"name": "CVE-2025-21835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21835"
},
{
"name": "CVE-2025-21811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21811"
}
],
"initial_release_date": "2025-07-18T00:00:00",
"last_revision_date": "2025-07-18T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0605",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-07-18T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es, un contournement de la politique de s\u00e9curit\u00e9 et un d\u00e9ni de service.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2025-07-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7610-3",
"url": "https://ubuntu.com/security/notices/USN-7610-3"
},
{
"published_at": "2025-07-11",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7608-6",
"url": "https://ubuntu.com/security/notices/USN-7608-6"
},
{
"published_at": "2025-07-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7640-1",
"url": "https://ubuntu.com/security/notices/USN-7640-1"
},
{
"published_at": "2025-07-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7611-3",
"url": "https://ubuntu.com/security/notices/USN-7611-3"
},
{
"published_at": "2025-07-16",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7585-7",
"url": "https://ubuntu.com/security/notices/USN-7585-7"
}
]
}
FKIE_CVE-2024-56599
Vulnerability from fkie_nvd - Published: 2024-12-27 15:15 - Updated: 2026-06-17 08:12| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/27d5d217ae7ffb99dd623375a17a7d3418d9c755 | ||
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/27fda36eedad9e4ec795dc481f307901d1885112 | ||
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/543c0924d446b21f35701ca084d7feca09511220 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921 | ||
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/95c38953cb1ecf40399a676a1f85dfe2b5780a9a | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/b35de9e01fc79c7baac666fb2dcb4ba7698a1d97 | ||
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html | ||
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/ath/ath10k/sdio.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "27d5d217ae7ffb99dd623375a17a7d3418d9c755",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "27fda36eedad9e4ec795dc481f307901d1885112",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "b35de9e01fc79c7baac666fb2dcb4ba7698a1d97",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "543c0924d446b21f35701ca084d7feca09511220",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
},
{
"lessThan": "95c38953cb1ecf40399a676a1f85dfe2b5780a9a",
"status": "affected",
"version": "5e3dd157d7e70f0e3cea3f2573ed69fb156a19d5",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/ath/ath10k/sdio.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.11"
},
{
"lessThan": "3.11",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.237",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.181",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.127",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.70",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.5",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.13",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "75E05E0A-C898-433A-8E50-6D9EC8646A64",
"versionEndExcluding": "6.12.5",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0027rmmod ath10k\u0027, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0027rmmod ath10k\u0027, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n -\u003eath10k_core_unregister\n \u2026\u2026\n -\u003eath10k_core_stop\n -\u003eath10k_hif_stop\n -\u003eath10k_sdio_irq_disable\n -\u003eath10k_hif_power_down\n -\u003edel_timer_sync(\u0026ar_sdio-\u003esleep_timer)\n -\u003eath10k_core_destroy\n -\u003eath10k_mac_destroy\n -\u003eieee80211_free_hw\n -\u003ewiphy_free\n \u2026\u2026\n -\u003ewiphy_dev_release\n -\u003edestroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0027t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: ath10k: evitar error de puntero NULL durante la eliminaci\u00f3n de sdio Al ejecutar \u0027rmmod ath10k\u0027, ath10k_sdio_remove() liberar\u00e1 la cola de trabajo de sdio mediante destroy_workqueue(). Pero si CONFIG_INIT_ON_FREE_DEFAULT_ON est\u00e1 configurado en s\u00ed, se producir\u00e1 un p\u00e1nico del kernel: Rastreo de llamada: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c Esto se debe a que durante \u0027rmmod ath10k\u0027, ath10k_sdio_remove() llamar\u00e1 a ath10k_core_destroy() antes de destroy_workqueue(). wiphy_dev_release() finalmente se llamar\u00e1 en ath10k_core_destroy(). Esta funci\u00f3n liberar\u00e1 la estructura cfg80211_registered_device *rdev y todos sus miembros, incluidos wiphy, dev y el puntero de sdio workqueue. Luego, el puntero de sdio workqueue se establecer\u00e1 en NULL debido a CONFIG_INIT_ON_FREE_DEFAULT_ON. Despu\u00e9s de liberar el dispositivo, destroy_workqueue() usar\u00e1 el puntero NULL y luego se producir\u00e1 el p\u00e1nico del kernel. Rastreo de llamadas: ath10k_sdio_remove -\u0026gt;ath10k_core_unregister \u2026\u2026 -\u0026gt;ath10k_core_stop -\u0026gt;ath10k_hif_stop -\u0026gt;ath10k_sdio_irq_disable -\u0026gt;ath10k_hif_power_down -\u0026gt;del_timer_sync(\u0026amp;ar_sdio-\u0026gt;sleep_timer) -\u0026gt;ath10k_core_destroy -\u0026gt;ath10k_mac_destroy -\u0026gt;ieee80211_free_hw -\u0026gt;wiphy_free \u2026\u2026 -\u0026gt;wiphy_dev_release -\u0026gt;destroy_workqueue Es necesario llamar a destroy_workqueue() antes de ath10k_core_destroy(), primero liberar el b\u00fafer de la cola de trabajo y luego liberar el puntero de la cola de trabajo mediante ath10k_core_destroy(). Este orden coincide con el orden de la ruta de error en ath10k_sdio_probe(). No se pondr\u00e1 en cola ning\u00fan trabajo en la cola de trabajo de sdio entre su destrucci\u00f3n y la llamada a ath10k_core_destroy(). Seg\u00fan la pila de llamadas anterior, el motivo es el siguiente: solo ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() y ath10k_sdio_irq_disable() pondr\u00e1n en cola el trabajo en la cola de trabajo de sdio. El temporizador de suspensi\u00f3n se eliminar\u00e1 antes de ath10k_core_destroy() en ath10k_hif_power_down(). ath10k_sdio_irq_disable() solo se llamar\u00e1 en ath10k_hif_stop(). ath10k_core_unregister() llamar\u00e1 a ath10k_hif_power_down() para detener el bus hif, por lo que ya no se llamar\u00e1 ath10k_sdio_hif_tx_sg(). Probado en: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189"
}
],
"id": "CVE-2024-56599",
"lastModified": "2026-06-17T08:12:30.777",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2024-12-27T15:15:19.307",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/27d5d217ae7ffb99dd623375a17a7d3418d9c755"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/27fda36eedad9e4ec795dc481f307901d1885112"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/543c0924d446b21f35701ca084d7feca09511220"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/95c38953cb1ecf40399a676a1f85dfe2b5780a9a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/b35de9e01fc79c7baac666fb2dcb4ba7698a1d97"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-476"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-H88R-39VX-9655
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: avoid NULL pointer error during sdio remove
When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c
This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.
After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen.
Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue
Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe().
No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189
{
"affected": [],
"aliases": [
"CVE-2024-56599"
],
"database_specific": {
"cwe_ids": [
"CWE-476"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T15:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0027rmmod ath10k\u0027, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0027rmmod ath10k\u0027, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n -\u003eath10k_core_unregister\n \u2026\u2026\n -\u003eath10k_core_stop\n -\u003eath10k_hif_stop\n -\u003eath10k_sdio_irq_disable\n -\u003eath10k_hif_power_down\n -\u003edel_timer_sync(\u0026ar_sdio-\u003esleep_timer)\n -\u003eath10k_core_destroy\n -\u003eath10k_mac_destroy\n -\u003eieee80211_free_hw\n -\u003ewiphy_free\n \u2026\u2026\n -\u003ewiphy_dev_release\n -\u003edestroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0027t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189",
"id": "GHSA-h88r-39vx-9655",
"modified": "2025-11-03T21:31:54Z",
"published": "2024-12-27T15:31:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56599"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27d5d217ae7ffb99dd623375a17a7d3418d9c755"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27fda36eedad9e4ec795dc481f307901d1885112"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/543c0924d446b21f35701ca084d7feca09511220"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95c38953cb1ecf40399a676a1f85dfe2b5780a9a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b35de9e01fc79c7baac666fb2dcb4ba7698a1d97"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.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"
}
]
}
MSRC_CVE-2024-56599
Vulnerability from csaf_microsoft - Published: 2024-12-02 00:00 - Updated: 2026-02-18 01:33oesa-2025-2882
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)
In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes System RAM (kmem) a descendant of CXLWindow X . This confuses region_intersects(), which expects all SystemRAM resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be Operation not permitted instead of Bad address . Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn t allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, System RAM is a descendant of CXL Window 0 instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn t allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with System RAM not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- CXL Window 0 ------------||-- System RAM --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- System RAM --||-- CXL Window 0a --|Where CXL Window 0a is part of the original CXL Window 0 thatisn t covered by System RAM .(CVE-2024-49878)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: avoid NULL pointer error during sdio remove
When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c
This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.
After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen.
Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue
Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe().
No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
ppp: Fix KMSAN uninit-value warning with bpf
Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.
The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.
As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.
The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.
For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.
[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000(CVE-2025-21922)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization
On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.(CVE-2025-23160)
In the Linux kernel, the following vulnerability has been resolved:
net: tls: explicitly disallow disconnect
syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be acked. Disconnect is not commonly used, disallow it.
The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger:
WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix the warning from __kernel_write_iter
[ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280
This patch doesn't allow writing to directory.(CVE-2025-37775)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb_break_all_levII_oplock()
There is a room in smb_break_all_levII_oplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.(CVE-2025-37776)
In the Linux kernel, the following vulnerability has been resolved:
pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()
With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line:
do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));
due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero.
This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero.
Fixes the following warning:
drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section
ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
x86/sev: Evict cache lines during SNP memory validation
An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.
CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.
Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable.(CVE-2025-38560)
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.
On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.
Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size
This is inspired by the check for data_offset + data_length.(CVE-2025-39942)
In the Linux kernel, the following vulnerability has been resolved:
mm/ksm: fix flag-dropping behavior in ksm_madvise
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.
Fix it by changing VM_MERGEABLE constant to unsigned long, using the
BIT() macro.
Note: other VM_ flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_ flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.
Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
[(CVE-2025-40040)
In the Linux kernel, the following vulnerability has been resolved:
net: use dst_dev_rcu() in sk_setup_caps()
Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size().
Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward().
ip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-source-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"perf-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"python3-perf-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-129.0.0.114.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-source-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"perf-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"python3-perf-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-129.0.0.114.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)\n\nIn the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes System RAM (kmem) a descendant of CXLWindow X . This confuses region_intersects(), which expects all SystemRAM resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1 dd: error writing /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be Operation not permitted instead of Bad address . Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn t allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, System RAM is a descendant of CXL Window 0 instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn t allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with System RAM not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- CXL Window 0 ------------||-- System RAM --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- System RAM --||-- CXL Window 0a --|Where CXL Window 0a is part of the original CXL Window 0 thatisn t covered by System RAM .(CVE-2024-49878)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n -\u0026gt;ath10k_core_unregister\n \u2026\u2026\n -\u0026gt;ath10k_core_stop\n -\u0026gt;ath10k_hif_stop\n -\u0026gt;ath10k_sdio_irq_disable\n -\u0026gt;ath10k_hif_power_down\n -\u0026gt;del_timer_sync(\u0026amp;ar_sdio-\u0026gt;sleep_timer)\n -\u0026gt;ath10k_core_destroy\n -\u0026gt;ath10k_mac_destroy\n -\u0026gt;ieee80211_free_hw\n -\u0026gt;wiphy_free\n \u2026\u2026\n -\u0026gt;wiphy_dev_release\n -\u0026gt;destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0026apos;t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: Fix KMSAN uninit-value warning with bpf\n\nSyzbot caught an \u0026quot;KMSAN: uninit-value\u0026quot; warning [1], which is caused by the\nppp driver not initializing a 2-byte header when using socket filter.\n\nThe following code can generate a PPP filter BPF program:\n\u0026apos;\u0026apos;\u0026apos;\nstruct bpf_program fp;\npcap_t *handle;\nhandle = pcap_open_dead(DLT_PPP_PPPD, 65535);\npcap_compile(handle, \u0026amp;fp, \u0026quot;ip and outbound\u0026quot;, 0, 0);\nbpf_dump(\u0026amp;fp, 1);\n\u0026apos;\u0026apos;\u0026apos;\nIts output is:\n\u0026apos;\u0026apos;\u0026apos;\n(000) ldh [2]\n(001) jeq #0x21 jt 2 jf 5\n(002) ldb [0]\n(003) jeq #0x1 jt 4 jf 5\n(004) ret #65535\n(005) ret #0\n\u0026apos;\u0026apos;\u0026apos;\nWen can find similar code at the following link:\nhttps://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680\nThe maintainer of this code repository is also the original maintainer\nof the ppp driver.\n\nAs you can see the BPF program skips 2 bytes of data and then reads the\n\u0026apos;Protocol\u0026apos; field to determine if it\u0026apos;s an IP packet. Then it read the first\nbyte of the first 2 bytes to determine the direction.\n\nThe issue is that only the first byte indicating direction is initialized\nin current ppp driver code while the second byte is not initialized.\n\nFor normal BPF programs generated by libpcap, uninitialized data won\u0026apos;t be\nused, so it\u0026apos;s not a problem. However, for carefully crafted BPF programs,\nsuch as those generated by syzkaller [2], which start reading from offset\n0, the uninitialized data will be used and caught by KMSAN.\n\n[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791\n[2] https://syzkaller.appspot.com/text?tag=ReproC\u0026amp;x=11994913980000(CVE-2025-21922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.(CVE-2025-23160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we\u0026apos;d need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that\u0026apos;s just the easiest bug to trigger:\n\n WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n sock_recvmsg_nosec net/socket.c:1023 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1045\n __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn\u0026apos;t allow writing to directory.(CVE-2025-37775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.(CVE-2025-37776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST \u0026amp;\u0026amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n\tdo_div(resolution, clk_get_rate(pc-\u0026gt;clk_pwms[pwm-\u0026gt;hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK. Regardless it\u0026apos;s\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/](CVE-2025-37850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.(CVE-2025-38560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.(CVE-2025-39942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[ 44.607039] ------------[ cut here ]------------\n[ 44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n\u0026lt;snip other registers, drop unreliable trace\u0026gt;\n\n[ 44.617726] Call Trace:\n[ 44.617926] \u0026lt;TASK\u0026gt;\n[ 44.619284] userfaultfd_release+0xef/0x1b0\n[ 44.620976] __fput+0x3f9/0xb60\n[ 44.621240] fput_close_sync+0x110/0x210\n[ 44.622222] __x64_sys_close+0x8f/0x120\n[ 44.622530] do_syscall_64+0x5b/0x2f0\n[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all(). Specifically, a VMA which has a valid pointer\nto vma-\u0026gt;vm_userfaultfd_ctx, but no UFFD flags in vma-\u0026gt;vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma-\u0026gt;vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide. This setup causes the following mishap during the \u0026amp;=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000\u0026apos;0000. \nAfter ~ is applied, it becomes 0x7fff\u0026apos;ffff unsigned int, which is then\npromoted to unsigned long before the \u0026amp; operation. This promotion fills\nupper 32 bits with leading 0s, as we\u0026apos;re doing unsigned conversion (and\neven for a signed conversion, this wouldn\u0026apos;t help as the leading bit is 0).\n\u0026amp; operation thus ends up AND-ing vm_flags with 0x0000\u0026apos;0000\u0026apos;7fff\u0026apos;ffff\ninstead of intended 0xffff\u0026apos;ffff\u0026apos;7fff\u0026apos;ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 (\u0026quot;userfaultfd: remove (VM_)BUG_ON()s\u0026quot;), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[(CVE-2025-40040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u0026gt;dev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)",
"id": "OESA-2025-2882",
"modified": "2026-08-06T11:10:00Z",
"published": "2025-12-30T11:10:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2882"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56599"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37775"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40040"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-42154",
"CVE-2024-49878",
"CVE-2024-56599",
"CVE-2025-21905",
"CVE-2025-21922",
"CVE-2025-23158",
"CVE-2025-23160",
"CVE-2025-37756",
"CVE-2025-37775",
"CVE-2025-37776",
"CVE-2025-37850",
"CVE-2025-37927",
"CVE-2025-38560",
"CVE-2025-39901",
"CVE-2025-39942",
"CVE-2025-40040",
"CVE-2025-40170"
]
}
oesa-2025-2883
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ( usb: musb: sunxi: Explicitly release USB PHY onexit ) will cause that usb phy @glue->xceiv is accessed after released.1) register platform driver @sunxi_musb_driver// get the usb phy @glue->xceivsunxi_musb_probe() -> devm_usb_get_phy().2) register and unregister platform driver @musb_drivermusb_probe() -> sunxi_musb_init()use the phy here//the phy is released heremusb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy()3) register @musb_driver againmusb_probe() -> sunxi_musb_init()use the phy here but the phy has been released at 2)....Fixed by reverting the commit, namely, removing devm_usb_put_phy()from sunxi_musb_exit().(CVE-2024-50269)
In the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 131072 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table 0 524288 cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table 0 65536 linear /dev/sdc 8192 dmsetup resume cdatadmsetup resume cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.(CVE-2024-50279)
In the Linux kernel, the following vulnerability has been resolved:iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loopof iio_gts_build_avail_scale_table(), the err_free_out will fail to callkfree() each time when i is reduced to 0, so all the per_time_scales[0]and per_time_gains[0] will not be freed, which will cause memory leaks.Fix it by checking if i >= 0.(CVE-2024-53076)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: avoid NULL pointer error during sdio remove
When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c
This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.
After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen.
Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue
Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe().
No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
ppp: Fix KMSAN uninit-value warning with bpf
Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.
The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.
As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.
The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.
For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.
[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000(CVE-2025-21922)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization
On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.(CVE-2025-23160)
In the Linux kernel, the following vulnerability has been resolved:
net: tls: explicitly disallow disconnect
syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be acked. Disconnect is not commonly used, disallow it.
The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger:
WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix the warning from __kernel_write_iter
[ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280
This patch doesn't allow writing to directory.(CVE-2025-37775)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb_break_all_levII_oplock()
There is a room in smb_break_all_levII_oplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.(CVE-2025-37776)
In the Linux kernel, the following vulnerability has been resolved:
pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()
With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line:
do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));
due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero.
This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero.
Fixes the following warning:
drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section
ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
x86/sev: Evict cache lines during SNP memory validation
An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.
CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.
Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable.(CVE-2025-38560)
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.
On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.
Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size
This is inspired by the check for data_offset + data_length.(CVE-2025-39942)
In the Linux kernel, the following vulnerability has been resolved:
mm/ksm: fix flag-dropping behavior in ksm_madvise
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.
Fix it by changing VM_MERGEABLE constant to unsigned long, using the
BIT() macro.
Note: other VM_ flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_ flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.
Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
[(CVE-2025-40040)
In the Linux kernel, the following vulnerability has been resolved:
net: use dst_dev_rcu() in sk_setup_caps()
Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size().
Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward().
ip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"perf-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-129.0.0.127.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"perf-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.127.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-129.0.0.127.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ( usb: musb: sunxi: Explicitly release USB PHY onexit ) will cause that usb phy @glue-\u0026gt;xceiv is accessed after released.1) register platform driver @sunxi_musb_driver// get the usb phy @glue-\u0026gt;xceivsunxi_musb_probe() -\u0026gt; devm_usb_get_phy().2) register and unregister platform driver @musb_drivermusb_probe() -\u0026gt; sunxi_musb_init()use the phy here//the phy is released heremusb_remove() -\u0026gt; sunxi_musb_exit() -\u0026gt; devm_usb_put_phy()3) register @musb_driver againmusb_probe() -\u0026gt; sunxi_musb_init()use the phy here but the phy has been released at 2)....Fixed by reverting the commit, namely, removing devm_usb_put_phy()from sunxi_musb_exit().(CVE-2024-50269)\n\nIn the Linux kernel, the following vulnerability has been resolved:dm cache: fix out-of-bounds access to the dirty bitset when resizingdm-cache checks the dirty bits of the cache blocks to be dropped whenshrinking the fast device, but an index bug in bitset iteration causesout-of-bounds access.Reproduce steps:1. create a cache device of 1024 cache blocks (128 bytes dirty bitset)dmsetup create cmeta --table 0 8192 linear /dev/sdc 0 dmsetup create cdata --table 0 131072 linear /dev/sdc 8192 dmsetup create corig --table 0 524288 linear /dev/sdc 262144 dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=directdmsetup create cache --table 0 524288 cache /dev/mapper/cmeta /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80)dmsetup suspend cachedmsetup reload cdata --table 0 65536 linear /dev/sdc 8192 dmsetup resume cdatadmsetup resume cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 \u0026gt;ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by making the index post-incremented.(CVE-2024-50279)\n\nIn the Linux kernel, the following vulnerability has been resolved:iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table()If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loopof iio_gts_build_avail_scale_table(), the err_free_out will fail to callkfree() each time when i is reduced to 0, so all the per_time_scales[0]and per_time_gains[0] will not be freed, which will cause memory leaks.Fix it by checking if i \u0026gt;= 0.(CVE-2024-53076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n -\u0026gt;ath10k_core_unregister\n \u2026\u2026\n -\u0026gt;ath10k_core_stop\n -\u0026gt;ath10k_hif_stop\n -\u0026gt;ath10k_sdio_irq_disable\n -\u0026gt;ath10k_hif_power_down\n -\u0026gt;del_timer_sync(\u0026amp;ar_sdio-\u0026gt;sleep_timer)\n -\u0026gt;ath10k_core_destroy\n -\u0026gt;ath10k_mac_destroy\n -\u0026gt;ieee80211_free_hw\n -\u0026gt;wiphy_free\n \u2026\u2026\n -\u0026gt;wiphy_dev_release\n -\u0026gt;destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0026apos;t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: Fix KMSAN uninit-value warning with bpf\n\nSyzbot caught an \u0026quot;KMSAN: uninit-value\u0026quot; warning [1], which is caused by the\nppp driver not initializing a 2-byte header when using socket filter.\n\nThe following code can generate a PPP filter BPF program:\n\u0026apos;\u0026apos;\u0026apos;\nstruct bpf_program fp;\npcap_t *handle;\nhandle = pcap_open_dead(DLT_PPP_PPPD, 65535);\npcap_compile(handle, \u0026amp;fp, \u0026quot;ip and outbound\u0026quot;, 0, 0);\nbpf_dump(\u0026amp;fp, 1);\n\u0026apos;\u0026apos;\u0026apos;\nIts output is:\n\u0026apos;\u0026apos;\u0026apos;\n(000) ldh [2]\n(001) jeq #0x21 jt 2 jf 5\n(002) ldb [0]\n(003) jeq #0x1 jt 4 jf 5\n(004) ret #65535\n(005) ret #0\n\u0026apos;\u0026apos;\u0026apos;\nWen can find similar code at the following link:\nhttps://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680\nThe maintainer of this code repository is also the original maintainer\nof the ppp driver.\n\nAs you can see the BPF program skips 2 bytes of data and then reads the\n\u0026apos;Protocol\u0026apos; field to determine if it\u0026apos;s an IP packet. Then it read the first\nbyte of the first 2 bytes to determine the direction.\n\nThe issue is that only the first byte indicating direction is initialized\nin current ppp driver code while the second byte is not initialized.\n\nFor normal BPF programs generated by libpcap, uninitialized data won\u0026apos;t be\nused, so it\u0026apos;s not a problem. However, for carefully crafted BPF programs,\nsuch as those generated by syzkaller [2], which start reading from offset\n0, the uninitialized data will be used and caught by KMSAN.\n\n[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791\n[2] https://syzkaller.appspot.com/text?tag=ReproC\u0026amp;x=11994913980000(CVE-2025-21922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.(CVE-2025-23160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we\u0026apos;d need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that\u0026apos;s just the easiest bug to trigger:\n\n WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n sock_recvmsg_nosec net/socket.c:1023 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1045\n __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn\u0026apos;t allow writing to directory.(CVE-2025-37775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.(CVE-2025-37776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST \u0026amp;\u0026amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n\tdo_div(resolution, clk_get_rate(pc-\u0026gt;clk_pwms[pwm-\u0026gt;hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK. Regardless it\u0026apos;s\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/](CVE-2025-37850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.(CVE-2025-38560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.(CVE-2025-39942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[ 44.607039] ------------[ cut here ]------------\n[ 44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n\u0026lt;snip other registers, drop unreliable trace\u0026gt;\n\n[ 44.617726] Call Trace:\n[ 44.617926] \u0026lt;TASK\u0026gt;\n[ 44.619284] userfaultfd_release+0xef/0x1b0\n[ 44.620976] __fput+0x3f9/0xb60\n[ 44.621240] fput_close_sync+0x110/0x210\n[ 44.622222] __x64_sys_close+0x8f/0x120\n[ 44.622530] do_syscall_64+0x5b/0x2f0\n[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all(). Specifically, a VMA which has a valid pointer\nto vma-\u0026gt;vm_userfaultfd_ctx, but no UFFD flags in vma-\u0026gt;vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma-\u0026gt;vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide. This setup causes the following mishap during the \u0026amp;=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000\u0026apos;0000. \nAfter ~ is applied, it becomes 0x7fff\u0026apos;ffff unsigned int, which is then\npromoted to unsigned long before the \u0026amp; operation. This promotion fills\nupper 32 bits with leading 0s, as we\u0026apos;re doing unsigned conversion (and\neven for a signed conversion, this wouldn\u0026apos;t help as the leading bit is 0).\n\u0026amp; operation thus ends up AND-ing vm_flags with 0x0000\u0026apos;0000\u0026apos;7fff\u0026apos;ffff\ninstead of intended 0xffff\u0026apos;ffff\u0026apos;7fff\u0026apos;ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 (\u0026quot;userfaultfd: remove (VM_)BUG_ON()s\u0026quot;), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[(CVE-2025-40040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u0026gt;dev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)",
"id": "OESA-2025-2883",
"modified": "2026-08-06T11:10:01Z",
"published": "2025-12-30T11:10:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50279"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53076"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56599"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37775"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40040"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-50269",
"CVE-2024-50279",
"CVE-2024-53076",
"CVE-2024-56599",
"CVE-2025-21905",
"CVE-2025-21922",
"CVE-2025-23158",
"CVE-2025-23160",
"CVE-2025-37756",
"CVE-2025-37775",
"CVE-2025-37776",
"CVE-2025-37850",
"CVE-2025-37927",
"CVE-2025-38560",
"CVE-2025-39901",
"CVE-2025-39942",
"CVE-2025-40040",
"CVE-2025-40170"
]
}
SUSE-SU-2025:0117-1
Vulnerability from csaf_suse - Published: 2025-01-15 09:07 - Updated: 2025-01-15 09:07SUSE-SU-2025:0153-1
Vulnerability from csaf_suse - Published: 2025-01-17 09:14 - Updated: 2025-01-17 09:14SUSE-SU-2025:0154-1
Vulnerability from csaf_suse - Published: 2025-01-17 09:15 - Updated: 2025-01-17 09:15Sightings
| 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.