Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-53198 (GCVE-0-2024-53198)
Vulnerability from cvelistv5 – Published: 2024-12-27 13:49 – Updated: 2026-08-05 11:44- CWE-401 - Missing Release of Memory after Effective Lifetime
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
4bac07c993d03434ea902d3d4290d9e45944b66c , < 87106169b4ce26f85561f953d13d1fd86d99b612
(git)
Affected: 4bac07c993d03434ea902d3d4290d9e45944b66c , < 0aa9e30b5b4af5dd504801689d6d84c584290a45 (git) Affected: 4bac07c993d03434ea902d3d4290d9e45944b66c , < e8823e6ff313465910edea07581627d85e68d9fd (git) Affected: 4bac07c993d03434ea902d3d4290d9e45944b66c , < 3fc0996d2fefe61219375fd650601724b8cf2d30 (git) Affected: 4bac07c993d03434ea902d3d4290d9e45944b66c , < 804b96f8d0a02fa10b92f28b2e042f9128ed3ffc (git) Affected: 4bac07c993d03434ea902d3d4290d9e45944b66c , < 217bdce88b104269b73603b84d0ab4dd04f481bc (git) Affected: 4bac07c993d03434ea902d3d4290d9e45944b66c , < 2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e (git) Affected: 4bac07c993d03434ea902d3d4290d9e45944b66c , < afc545da381ba0c651b2658966ac737032676f01 (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.23
Unaffected: 0 , < 2.6.23 (semver) Unaffected: 5.4.287 , ≤ 5.4.* (semver) Unaffected: 5.10.231 , ≤ 5.10.* (semver) Unaffected: 5.15.174 , ≤ 5.15.* (semver) Unaffected: 6.1.120 , ≤ 6.1.* (semver) Unaffected: 6.6.64 , ≤ 6.6.* (semver) Unaffected: 6.11.11 , ≤ 6.11.* (semver) Unaffected: 6.12.2 , ≤ 6.12.* (semver) Unaffected: 6.13 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-53198",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:04:00.609421Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-401",
"description": "CWE-401 Missing Release of Memory after Effective Lifetime",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T20:07:20.627Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T20:47:32.708Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00001.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00002.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/xen/xenbus/xenbus_probe.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "87106169b4ce26f85561f953d13d1fd86d99b612",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "0aa9e30b5b4af5dd504801689d6d84c584290a45",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "e8823e6ff313465910edea07581627d85e68d9fd",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "3fc0996d2fefe61219375fd650601724b8cf2d30",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "804b96f8d0a02fa10b92f28b2e042f9128ed3ffc",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "217bdce88b104269b73603b84d0ab4dd04f481bc",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "afc545da381ba0c651b2658966ac737032676f01",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/xen/xenbus/xenbus_probe.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.23"
},
{
"lessThan": "2.6.23",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"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.4.287",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13",
"versionStartIncluding": "2.6.23",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u003eprobe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable code is the Xen paravirtual bus probe path, reached through local xenstore access (/dev/xen/xenbus, xenfs) and sysfs driver bind/unbind or device hotplug within the domain. There is no network-facing path to xenbus_dev_probe().\nAC:L - An attacker who can influence xenstore or induce memory pressure can deterministically make watch_otherend() fail (kvasprintf ENOMEM, or xs_watch returning EINVAL/E2BIG on an over-long path or exhausted per-domain watch quota), and probe can be re-triggered repeatedly via bind/unbind. No condition outside the attacker\u0027s influence is required.\nPR:L - A local unprivileged user can create the allocation-failure condition that makes the watch registration fail while ordinary device probe/hotplug/resume activity drives xenbus_dev_probe(); no capability check guards the vulnerable error path itself.\nUI:N - The probe path runs automatically on device discovery, hotplug and resume, and can be re-driven by the attacker; no action by another user is required.\nS:U - The leaked resources and the resulting dangling-pointer accesses are all within the same kernel\u0027s security authority; no hypervisor or IOMMU boundary is crossed by the defect itself.\nC:H - The orphaned xenstore watch (blkback\u0027s backend_watch, pciback\u0027s be_watch) keeps a dangling pointer to a struct xenbus_device that is later kfree()d, so the watch callback performs use-after-free reads of dev-\u003enodename/dev-\u003eotherend_id and echoes them into xenstore, exposing reclaimed kernel heap contents that an attacker can groom.\nI:H - The same dangling pointer is written through \u2014 xenbus_dev_fatal() reaches __xenbus_switch_state() which stores into dev-\u003estate, and dev_err() walks the freed struct device \u2014 giving a use-after-free write into a reallocated object, the classic primitive for heap corruption and control-flow hijack.\nA:H - The missing drv-\u003eremove() leaks event channels, grant references and kernel objects on every repeated probe failure, and the surviving watch dereferencing freed memory causes an oops or panic when it later fires."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:44:34.804Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612"
},
{
"url": "https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45"
},
{
"url": "https://git.kernel.org/stable/c/e8823e6ff313465910edea07581627d85e68d9fd"
},
{
"url": "https://git.kernel.org/stable/c/3fc0996d2fefe61219375fd650601724b8cf2d30"
},
{
"url": "https://git.kernel.org/stable/c/804b96f8d0a02fa10b92f28b2e042f9128ed3ffc"
},
{
"url": "https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc"
},
{
"url": "https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e"
},
{
"url": "https://git.kernel.org/stable/c/afc545da381ba0c651b2658966ac737032676f01"
}
],
"title": "xen: Fix the issue of resource not being properly released in xenbus_dev_probe()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-53198",
"datePublished": "2024-12-27T13:49:40.339Z",
"dateReserved": "2024-11-19T17:17:25.015Z",
"dateUpdated": "2026-08-05T11:44:34.804Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-53198",
"date": "2026-09-22",
"epss": "0.00241",
"percentile": "0.15554"
},
"fkie_nvd": {
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u003eprobe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen: soluciona el problema de que los recursos no se liberan correctamente en xenbus_dev_probe() Este parche soluciona un problema en la funci\u00f3n xenbus_dev_probe(). En la funci\u00f3n xenbus_dev_probe(), dentro de la rama if (err) en la l\u00ednea 313, el programa devuelve incorrectamente err directamente sin liberar los recursos asignados por err = drv-\u0026gt;probe(dev, id). Como el valor de retorno no es cero, las capas superiores suponen que la l\u00f3gica de procesamiento ha fallado. Sin embargo, la operaci\u00f3n de sondeo se realiz\u00f3 antes sin una operaci\u00f3n de eliminaci\u00f3n correspondiente. Dado que el sondeo realmente asigna recursos, no realizar la operaci\u00f3n de eliminaci\u00f3n podr\u00eda provocar problemas. Para solucionar este problema, seguimos la l\u00f3gica de liberaci\u00f3n de recursos de la funci\u00f3n xenbus_dev_remove() agregando un nuevo bloque fail_remove antes del bloque fail_put. Despu\u00e9s de ingresar a la rama if (err) en la l\u00ednea 313, la funci\u00f3n usar\u00e1 una declaraci\u00f3n goto para saltar al bloque fail_remove, lo que garantiza que los recursos adquiridos previamente se liberen correctamente, evitando as\u00ed la fuga del recuento de referencias. Este error fue identificado por una herramienta de an\u00e1lisis est\u00e1tico experimental desarrollada por nuestro equipo. La herramienta se especializa en analizar operaciones de recuento de referencias y detectar posibles problemas en los que los recursos no se administran correctamente. En este caso, la herramienta marc\u00f3 la operaci\u00f3n de liberaci\u00f3n faltante como un problema potencial, lo que llev\u00f3 al desarrollo de este parche."
}
],
"id": "CVE-2024-53198",
"lastModified": "2024-12-27T14:15:27.497",
"published": "2024-12-27T14:15:27.497",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/3fc0996d2fefe61219375fd650601724b8cf2d30"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/804b96f8d0a02fa10b92f28b2e042f9128ed3ffc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/afc545da381ba0c651b2658966ac737032676f01"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/e8823e6ff313465910edea07581627d85e68d9fd"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Awaiting Analysis"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/xen/xenbus/xenbus_probe.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "87106169b4ce26f85561f953d13d1fd86d99b612",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "0aa9e30b5b4af5dd504801689d6d84c584290a45",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "e8823e6ff313465910edea07581627d85e68d9fd",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "3fc0996d2fefe61219375fd650601724b8cf2d30",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "804b96f8d0a02fa10b92f28b2e042f9128ed3ffc",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "217bdce88b104269b73603b84d0ab4dd04f481bc",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "afc545da381ba0c651b2658966ac737032676f01",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/xen/xenbus/xenbus_probe.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.23"
},
{
"lessThan": "2.6.23",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"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": "8C6A7B3A-AE77-4337-BC43-53984FDD12C4",
"versionEndExcluding": "5.4.287",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B5C644CC-2BD7-4E32-BC54-8DCC7ABE9935",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "419FD073-1517-4FD5-8158-F94BC68A1E89",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "09AC6122-E2A4-40FE-9D33-268A1B2EC265",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CA16DEE3-ABEC-4449-9F4A-7A3DC4FC36C7",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "21434379-192D-472F-9B54-D45E3650E893",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D8882B1B-2ABC-4838-AC1D-DBDBB5764776",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "6.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u003eprobe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen: soluciona el problema de que los recursos no se liberan correctamente en xenbus_dev_probe() Este parche soluciona un problema en la funci\u00f3n xenbus_dev_probe(). En la funci\u00f3n xenbus_dev_probe(), dentro de la rama if (err) en la l\u00ednea 313, el programa devuelve incorrectamente err directamente sin liberar los recursos asignados por err = drv-\u0026gt;probe(dev, id). Como el valor de retorno no es cero, las capas superiores suponen que la l\u00f3gica de procesamiento ha fallado. Sin embargo, la operaci\u00f3n de sondeo se realiz\u00f3 antes sin una operaci\u00f3n de eliminaci\u00f3n correspondiente. Dado que el sondeo realmente asigna recursos, no realizar la operaci\u00f3n de eliminaci\u00f3n podr\u00eda provocar problemas. Para solucionar este problema, seguimos la l\u00f3gica de liberaci\u00f3n de recursos de la funci\u00f3n xenbus_dev_remove() agregando un nuevo bloque fail_remove antes del bloque fail_put. Despu\u00e9s de ingresar a la rama if (err) en la l\u00ednea 313, la funci\u00f3n usar\u00e1 una declaraci\u00f3n goto para saltar al bloque fail_remove, lo que garantiza que los recursos adquiridos previamente se liberen correctamente, evitando as\u00ed la fuga del recuento de referencias. Este error fue identificado por una herramienta de an\u00e1lisis est\u00e1tico experimental desarrollada por nuestro equipo. La herramienta se especializa en analizar operaciones de recuento de referencias y detectar posibles problemas en los que los recursos no se administran correctamente. En este caso, la herramienta marc\u00f3 la operaci\u00f3n de liberaci\u00f3n faltante como un problema potencial, lo que llev\u00f3 al desarrollo de este parche."
}
],
"id": "CVE-2024-53198",
"lastModified": "2026-08-04T11:22:04.490",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"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"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-53198",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:04:00.609421Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-12-27T14:15:27.497",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3fc0996d2fefe61219375fd650601724b8cf2d30"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/804b96f8d0a02fa10b92f28b2e042f9128ed3ffc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/afc545da381ba0c651b2658966ac737032676f01"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e8823e6ff313465910edea07581627d85e68d9fd"
},
{
"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/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-401"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-401"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2025-11-21T11:00:06+00:00",
"cve": "CVE-2024-53198",
"id": "CVE-2024-53198",
"initial_release_date": "2024-12-27T00:00:00+00:00",
"product_status:known_affected": "198",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: xen: Fix the issue of resource not being properly released in xenbus_dev_probe()",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-53198.json",
"version": "3"
},
"suse_vex": {
"aggregate_severity": "moderate",
"current_release_date": "2026-09-12T16:56:30Z",
"cve": "CVE-2024-53198",
"id": "CVE-2024-53198",
"initial_release_date": "2024-12-28T03:50:26Z",
"product_status:known_affected": "827",
"product_status:known_not_affected": "32",
"product_status:recommended": "398",
"source": "SUSE CSAF VEX",
"status": "interim",
"title": "SUSE CVE CVE-2024-53198",
"url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2024-53198.json",
"version": "76"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-53198",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:04:00.609421Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-401",
"description": "CWE-401 Missing Release of Memory after Effective Lifetime",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T15:37:56.205Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/xen/xenbus/xenbus_probe.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "87106169b4ce26f85561f953d13d1fd86d99b612",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "0aa9e30b5b4af5dd504801689d6d84c584290a45",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "e8823e6ff313465910edea07581627d85e68d9fd",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "3fc0996d2fefe61219375fd650601724b8cf2d30",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "804b96f8d0a02fa10b92f28b2e042f9128ed3ffc",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "217bdce88b104269b73603b84d0ab4dd04f481bc",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "afc545da381ba0c651b2658966ac737032676f01",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/xen/xenbus/xenbus_probe.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.23"
},
{
"lessThan": "2.6.23",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"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.4.287",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13",
"versionStartIncluding": "2.6.23",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u003eprobe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch."
}
],
"providerMetadata": {
"dateUpdated": "2025-05-04T09:55:34.159Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612"
},
{
"url": "https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45"
},
{
"url": "https://git.kernel.org/stable/c/e8823e6ff313465910edea07581627d85e68d9fd"
},
{
"url": "https://git.kernel.org/stable/c/3fc0996d2fefe61219375fd650601724b8cf2d30"
},
{
"url": "https://git.kernel.org/stable/c/804b96f8d0a02fa10b92f28b2e042f9128ed3ffc"
},
{
"url": "https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc"
},
{
"url": "https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e"
},
{
"url": "https://git.kernel.org/stable/c/afc545da381ba0c651b2658966ac737032676f01"
}
],
"title": "xen: Fix the issue of resource not being properly released in xenbus_dev_probe()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-53198",
"datePublished": "2024-12-27T13:49:40.339Z",
"dateReserved": "2024-11-19T17:17:25.015Z",
"dateUpdated": "2025-10-01T20:07:20.627Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.1"
}
}
}
CERTFR-2025-AVI-0308
Vulnerability from certfr_avis - Published: - Updated:
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 élévation de privilèges, 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 16.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 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 LTS",
"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-23041",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23041"
},
{
"name": "CVE-2021-47101",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47101"
},
{
"name": "CVE-2021-47119",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47119"
},
{
"name": "CVE-2024-26863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26863"
},
{
"name": "CVE-2021-47235",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47235"
},
{
"name": "CVE-2021-47320",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47320"
},
{
"name": "CVE-2021-47483",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47483"
},
{
"name": "CVE-2024-26921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26921"
},
{
"name": "CVE-2024-26928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26928"
},
{
"name": "CVE-2024-35864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35864"
},
{
"name": "CVE-2024-35973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35973"
},
{
"name": "CVE-2024-35960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35960"
},
{
"name": "CVE-2021-47602",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47602"
},
{
"name": "CVE-2024-36899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36899"
},
{
"name": "CVE-2024-42069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42069"
},
{
"name": "CVE-2024-42315",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42315"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-44938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44938"
},
{
"name": "CVE-2024-46784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46784"
},
{
"name": "CVE-2024-46826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
},
{
"name": "CVE-2024-46809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46809"
},
{
"name": "CVE-2024-46841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46841"
},
{
"name": "CVE-2024-46871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46871"
},
{
"name": "CVE-2024-47707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47707"
},
{
"name": "CVE-2024-47730",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47730"
},
{
"name": "CVE-2024-49950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49950"
},
{
"name": "CVE-2024-49974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49974"
},
{
"name": "CVE-2024-49996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49996"
},
{
"name": "CVE-2024-50055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50055"
},
{
"name": "CVE-2024-50242",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50242"
},
{
"name": "CVE-2024-50265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50265"
},
{
"name": "CVE-2024-50283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50283"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-49925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49925"
},
{
"name": "CVE-2024-49948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49948"
},
{
"name": "CVE-2024-49952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49952"
},
{
"name": "CVE-2024-50121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50121"
},
{
"name": "CVE-2024-50167",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50167"
},
{
"name": "CVE-2024-50275",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50275"
},
{
"name": "CVE-2024-53096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53096"
},
{
"name": "CVE-2024-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53112"
},
{
"name": "CVE-2024-53121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53121"
},
{
"name": "CVE-2024-53138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53138"
},
{
"name": "CVE-2024-53142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53142"
},
{
"name": "CVE-2024-53113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53113"
},
{
"name": "CVE-2024-53119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53119"
},
{
"name": "CVE-2024-53120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53120"
},
{
"name": "CVE-2024-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53122"
},
{
"name": "CVE-2024-53127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53127"
},
{
"name": "CVE-2024-53129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53129"
},
{
"name": "CVE-2024-53130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53130"
},
{
"name": "CVE-2024-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53131"
},
{
"name": "CVE-2024-53135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53135"
},
{
"name": "CVE-2024-53136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53136"
},
{
"name": "CVE-2024-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53140"
},
{
"name": "CVE-2024-53099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53099"
},
{
"name": "CVE-2024-53125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53125"
},
{
"name": "CVE-2024-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53146"
},
{
"name": "CVE-2024-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53148"
},
{
"name": "CVE-2024-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53150"
},
{
"name": "CVE-2024-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53151"
},
{
"name": "CVE-2024-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53155"
},
{
"name": "CVE-2024-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53156"
},
{
"name": "CVE-2024-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53157"
},
{
"name": "CVE-2024-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53158"
},
{
"name": "CVE-2024-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
},
{
"name": "CVE-2024-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53171"
},
{
"name": "CVE-2024-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53173"
},
{
"name": "CVE-2024-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53174"
},
{
"name": "CVE-2024-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53180"
},
{
"name": "CVE-2024-53206",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53206"
},
{
"name": "CVE-2024-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53214"
},
{
"name": "CVE-2024-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53215"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2024-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53237"
},
{
"name": "CVE-2024-56539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56539"
},
{
"name": "CVE-2024-56562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56562"
},
{
"name": "CVE-2024-56567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56567"
},
{
"name": "CVE-2024-56576",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56576"
},
{
"name": "CVE-2024-56605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56605"
},
{
"name": "CVE-2024-56645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56645"
},
{
"name": "CVE-2024-56754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56754"
},
{
"name": "CVE-2024-56756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56756"
},
{
"name": "CVE-2024-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53239"
},
{
"name": "CVE-2024-56548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56548"
},
{
"name": "CVE-2024-56570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56570"
},
{
"name": "CVE-2024-56575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56575"
},
{
"name": "CVE-2024-56598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56598"
},
{
"name": "CVE-2024-56619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56619"
},
{
"name": "CVE-2024-56631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56631"
},
{
"name": "CVE-2024-56704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56704"
},
{
"name": "CVE-2024-36476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36476"
},
{
"name": "CVE-2024-45828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45828"
},
{
"name": "CVE-2024-47143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47143"
},
{
"name": "CVE-2024-48881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48881"
},
{
"name": "CVE-2024-49998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49998"
},
{
"name": "CVE-2024-50051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50051"
},
{
"name": "CVE-2024-52332",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52332"
},
{
"name": "CVE-2024-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53172"
},
{
"name": "CVE-2024-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53194"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53198"
},
{
"name": "CVE-2024-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53227"
},
{
"name": "CVE-2024-53685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53685"
},
{
"name": "CVE-2024-53690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53690"
},
{
"name": "CVE-2024-55881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55881"
},
{
"name": "CVE-2024-55916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55916"
},
{
"name": "CVE-2024-56369",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56369"
},
{
"name": "CVE-2024-56531",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56531"
},
{
"name": "CVE-2024-56532",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56532"
},
{
"name": "CVE-2024-56533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56533"
},
{
"name": "CVE-2024-56558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56558"
},
{
"name": "CVE-2024-56568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56568"
},
{
"name": "CVE-2024-56569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56569"
},
{
"name": "CVE-2024-56572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56572"
},
{
"name": "CVE-2024-56574",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56574"
},
{
"name": "CVE-2024-56578",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56578"
},
{
"name": "CVE-2024-56587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56587"
},
{
"name": "CVE-2024-56589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56589"
},
{
"name": "CVE-2024-56590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56590"
},
{
"name": "CVE-2024-56593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56593"
},
{
"name": "CVE-2024-56594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56594"
},
{
"name": "CVE-2024-56595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56595"
},
{
"name": "CVE-2024-56596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56596"
},
{
"name": "CVE-2024-56597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56597"
},
{
"name": "CVE-2024-56602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56602"
},
{
"name": "CVE-2024-56603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56603"
},
{
"name": "CVE-2024-56606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56606"
},
{
"name": "CVE-2024-56614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56614"
},
{
"name": "CVE-2024-56615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56615"
},
{
"name": "CVE-2024-56616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56616"
},
{
"name": "CVE-2024-56622",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56622"
},
{
"name": "CVE-2024-56623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56623"
},
{
"name": "CVE-2024-56625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56625"
},
{
"name": "CVE-2024-56629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56629"
},
{
"name": "CVE-2024-56630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56630"
},
{
"name": "CVE-2024-56634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56634"
},
{
"name": "CVE-2024-56636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56636"
},
{
"name": "CVE-2024-56637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56637"
},
{
"name": "CVE-2024-56642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56642"
},
{
"name": "CVE-2024-56643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56643"
},
{
"name": "CVE-2024-56644",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56644"
},
{
"name": "CVE-2024-56648",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56648"
},
{
"name": "CVE-2024-56659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56659"
},
{
"name": "CVE-2024-56662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56662"
},
{
"name": "CVE-2024-56670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56670"
},
{
"name": "CVE-2024-56672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56672"
},
{
"name": "CVE-2024-56678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56678"
},
{
"name": "CVE-2024-56681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56681"
},
{
"name": "CVE-2024-56688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56688"
},
{
"name": "CVE-2024-56690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56690"
},
{
"name": "CVE-2024-56691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56691"
},
{
"name": "CVE-2024-56694",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56694"
},
{
"name": "CVE-2024-56698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56698"
},
{
"name": "CVE-2024-56700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56700"
},
{
"name": "CVE-2024-56701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56701"
},
{
"name": "CVE-2024-56705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56705"
},
{
"name": "CVE-2024-56708",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56708"
},
{
"name": "CVE-2024-56716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56716"
},
{
"name": "CVE-2024-56723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56723"
},
{
"name": "CVE-2024-56724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56724"
},
{
"name": "CVE-2024-56739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56739"
},
{
"name": "CVE-2024-56745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56745"
},
{
"name": "CVE-2024-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56746"
},
{
"name": "CVE-2024-56747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56747"
},
{
"name": "CVE-2024-56748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56748"
},
{
"name": "CVE-2024-56759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56759"
},
{
"name": "CVE-2024-56767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56767"
},
{
"name": "CVE-2024-56769",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56769"
},
{
"name": "CVE-2024-56774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56774"
},
{
"name": "CVE-2024-56776",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56776"
},
{
"name": "CVE-2024-56777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56777"
},
{
"name": "CVE-2024-56778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56778"
},
{
"name": "CVE-2024-56779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56779"
},
{
"name": "CVE-2024-56780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56780"
},
{
"name": "CVE-2024-56787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56787"
},
{
"name": "CVE-2024-57791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57791"
},
{
"name": "CVE-2024-57792",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57792"
},
{
"name": "CVE-2024-57798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57798"
},
{
"name": "CVE-2024-57838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57838"
},
{
"name": "CVE-2024-57849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57849"
},
{
"name": "CVE-2024-57850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57850"
},
{
"name": "CVE-2024-57874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57874"
},
{
"name": "CVE-2024-57890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57890"
},
{
"name": "CVE-2024-57892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57892"
},
{
"name": "CVE-2024-57896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57896"
},
{
"name": "CVE-2024-57897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57897"
},
{
"name": "CVE-2024-57903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57903"
},
{
"name": "CVE-2024-57904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57904"
},
{
"name": "CVE-2024-57906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57906"
},
{
"name": "CVE-2024-57907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57907"
},
{
"name": "CVE-2024-57908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57908"
},
{
"name": "CVE-2024-57910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57910"
},
{
"name": "CVE-2024-57911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57911"
},
{
"name": "CVE-2024-57912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57912"
},
{
"name": "CVE-2024-57913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57913"
},
{
"name": "CVE-2024-57922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57922"
},
{
"name": "CVE-2024-57929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57929"
},
{
"name": "CVE-2024-57940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57940"
},
{
"name": "CVE-2025-21646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21646"
},
{
"name": "CVE-2024-50304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50304"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-56601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56601"
},
{
"name": "CVE-2024-56610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56610"
},
{
"name": "CVE-2024-56650",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56650"
},
{
"name": "CVE-2024-56658",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56658"
},
{
"name": "CVE-2024-56679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56679"
},
{
"name": "CVE-2024-56693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56693"
},
{
"name": "CVE-2024-56715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56715"
},
{
"name": "CVE-2024-56726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56726"
},
{
"name": "CVE-2024-56728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56728"
},
{
"name": "CVE-2024-56763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56763"
},
{
"name": "CVE-2024-57802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57802"
},
{
"name": "CVE-2024-57882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57882"
},
{
"name": "CVE-2024-57884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57884"
},
{
"name": "CVE-2024-57917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57917"
},
{
"name": "CVE-2024-57931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57931"
},
{
"name": "CVE-2024-57938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57938"
},
{
"name": "CVE-2024-57946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57946"
},
{
"name": "CVE-2025-21653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21653"
},
{
"name": "CVE-2025-21664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21664"
},
{
"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-21678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21678"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2024-57925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57925"
},
{
"name": "CVE-2024-57939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57939"
},
{
"name": "CVE-2024-57948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57948"
},
{
"name": "CVE-2025-21631",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21631"
},
{
"name": "CVE-2025-21636",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21636"
},
{
"name": "CVE-2025-21637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21637"
},
{
"name": "CVE-2025-21638",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21638"
},
{
"name": "CVE-2025-21639",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21639"
},
{
"name": "CVE-2025-21640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21640"
},
{
"name": "CVE-2025-21648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21648"
},
{
"name": "CVE-2025-21665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21665"
},
{
"name": "CVE-2025-21680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21680"
},
{
"name": "CVE-2025-21683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21683"
},
{
"name": "CVE-2024-56633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56633"
},
{
"name": "CVE-2022-49034",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49034"
},
{
"name": "CVE-2024-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53145"
},
{
"name": "CVE-2024-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53165"
},
{
"name": "CVE-2024-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53181"
},
{
"name": "CVE-2024-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53183"
},
{
"name": "CVE-2024-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53184"
},
{
"name": "CVE-2024-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53226"
},
{
"name": "CVE-2024-56720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56720"
},
{
"name": "CVE-2024-57889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57889"
},
{
"name": "CVE-2025-21687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21687"
},
{
"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-2025-21700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21700"
},
{
"name": "CVE-2024-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43098"
},
{
"name": "CVE-2024-47408",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47408"
},
{
"name": "CVE-2024-49571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49571"
},
{
"name": "CVE-2024-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53680"
},
{
"name": "CVE-2024-56581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56581"
},
{
"name": "CVE-2024-56586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56586"
},
{
"name": "CVE-2024-56626",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56626"
},
{
"name": "CVE-2024-56627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56627"
},
{
"name": "CVE-2024-56640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56640"
},
{
"name": "CVE-2024-56770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56770"
},
{
"name": "CVE-2024-56781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56781"
},
{
"name": "CVE-2024-56785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56785"
},
{
"name": "CVE-2024-57807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57807"
},
{
"name": "CVE-2024-57841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57841"
},
{
"name": "CVE-2024-57900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57900"
},
{
"name": "CVE-2024-57901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57901"
},
{
"name": "CVE-2024-57902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57902"
},
{
"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-58087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58087"
},
{
"name": "CVE-2021-47122",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47122"
},
{
"name": "CVE-2025-21702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21702"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0308",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-04-11T00: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": "\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 \u00e9l\u00e9vation de privil\u00e8ges, 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-04-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7406-5",
"url": "https://ubuntu.com/security/notices/USN-7406-5"
},
{
"published_at": "2025-04-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7421-1",
"url": "https://ubuntu.com/security/notices/USN-7421-1"
},
{
"published_at": "2025-04-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7420-1",
"url": "https://ubuntu.com/security/notices/USN-7420-1"
},
{
"published_at": "2025-04-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7406-6",
"url": "https://ubuntu.com/security/notices/USN-7406-6"
},
{
"published_at": "2025-04-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7402-4",
"url": "https://ubuntu.com/security/notices/USN-7402-4"
},
{
"published_at": "2025-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7428-2",
"url": "https://ubuntu.com/security/notices/USN-7428-2"
},
{
"published_at": "2025-04-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7402-3",
"url": "https://ubuntu.com/security/notices/USN-7402-3"
},
{
"published_at": "2025-04-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7408-4",
"url": "https://ubuntu.com/security/notices/USN-7408-4"
},
{
"published_at": "2025-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7429-1",
"url": "https://ubuntu.com/security/notices/USN-7429-1"
},
{
"published_at": "2025-04-07",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7408-3",
"url": "https://ubuntu.com/security/notices/USN-7408-3"
},
{
"published_at": "2025-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7428-1",
"url": "https://ubuntu.com/security/notices/USN-7428-1"
},
{
"published_at": "2025-04-09",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7429-2",
"url": "https://ubuntu.com/security/notices/USN-7429-2"
}
]
}
CERTFR-2025-AVI-0349
Vulnerability from certfr_avis - Published: - Updated:
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, 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 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.10",
"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-26718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26718"
},
{
"name": "CVE-2021-47119",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47119"
},
{
"name": "CVE-2021-47219",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47219"
},
{
"name": "CVE-2024-23848",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23848"
},
{
"name": "CVE-2024-26915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26915"
},
{
"name": "CVE-2024-26928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26928"
},
{
"name": "CVE-2024-35864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35864"
},
{
"name": "CVE-2024-35887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35887"
},
{
"name": "CVE-2024-35958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35958"
},
{
"name": "CVE-2024-36899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36899"
},
{
"name": "CVE-2024-40953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40953"
},
{
"name": "CVE-2024-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38588"
},
{
"name": "CVE-2024-26837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26837"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2024-39497",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39497"
},
{
"name": "CVE-2024-41066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41066"
},
{
"name": "CVE-2024-42122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42122"
},
{
"name": "CVE-2024-40965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40965"
},
{
"name": "CVE-2023-52913",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52913"
},
{
"name": "CVE-2024-41080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41080"
},
{
"name": "CVE-2024-42069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42069"
},
{
"name": "CVE-2024-42291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42291"
},
{
"name": "CVE-2024-42315",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42315"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-44938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44938"
},
{
"name": "CVE-2024-46784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46784"
},
{
"name": "CVE-2024-46826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
},
{
"name": "CVE-2024-42252",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42252"
},
{
"name": "CVE-2024-46809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46809"
},
{
"name": "CVE-2024-46841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46841"
},
{
"name": "CVE-2024-46871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46871"
},
{
"name": "CVE-2024-47707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47707"
},
{
"name": "CVE-2024-47730",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47730"
},
{
"name": "CVE-2024-49899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49899"
},
{
"name": "CVE-2024-49906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49906"
},
{
"name": "CVE-2024-49914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49914"
},
{
"name": "CVE-2024-49920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49920"
},
{
"name": "CVE-2024-49936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49936"
},
{
"name": "CVE-2024-49950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49950"
},
{
"name": "CVE-2024-49972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49972"
},
{
"name": "CVE-2024-49974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49974"
},
{
"name": "CVE-2024-49996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49996"
},
{
"name": "CVE-2024-50019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50019"
},
{
"name": "CVE-2024-50020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50020"
},
{
"name": "CVE-2024-50021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50021"
},
{
"name": "CVE-2024-50022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50022"
},
{
"name": "CVE-2024-50023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50023"
},
{
"name": "CVE-2024-50024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50024"
},
{
"name": "CVE-2024-50025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50025"
},
{
"name": "CVE-2024-50027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50027"
},
{
"name": "CVE-2024-50028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50028"
},
{
"name": "CVE-2024-50031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50031"
},
{
"name": "CVE-2024-50033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50033"
},
{
"name": "CVE-2024-50035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50035"
},
{
"name": "CVE-2024-50040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50040"
},
{
"name": "CVE-2024-50041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50041"
},
{
"name": "CVE-2024-50042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50042"
},
{
"name": "CVE-2024-50044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50044"
},
{
"name": "CVE-2024-50045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50045"
},
{
"name": "CVE-2024-50046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50046"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2024-50048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50048"
},
{
"name": "CVE-2024-50049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50049"
},
{
"name": "CVE-2024-50055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50055"
},
{
"name": "CVE-2024-50058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50058"
},
{
"name": "CVE-2024-50059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50059"
},
{
"name": "CVE-2024-50060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50060"
},
{
"name": "CVE-2024-50061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50061"
},
{
"name": "CVE-2024-50062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50062"
},
{
"name": "CVE-2024-50063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50063"
},
{
"name": "CVE-2024-50064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50064"
},
{
"name": "CVE-2024-50069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50069"
},
{
"name": "CVE-2024-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50073"
},
{
"name": "CVE-2024-50074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50074"
},
{
"name": "CVE-2024-50075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50075"
},
{
"name": "CVE-2024-50076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50076"
},
{
"name": "CVE-2024-50077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50077"
},
{
"name": "CVE-2024-50078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50078"
},
{
"name": "CVE-2024-50080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50080"
},
{
"name": "CVE-2024-50036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50036"
},
{
"name": "CVE-2024-50067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50067"
},
{
"name": "CVE-2024-50072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50072"
},
{
"name": "CVE-2024-50126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50126"
},
{
"name": "CVE-2024-50215",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50215"
},
{
"name": "CVE-2024-50218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50218"
},
{
"name": "CVE-2024-50229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50229"
},
{
"name": "CVE-2024-50230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50230"
},
{
"name": "CVE-2024-50232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50232"
},
{
"name": "CVE-2024-50233",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50233"
},
{
"name": "CVE-2024-50234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50234"
},
{
"name": "CVE-2024-50235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50235"
},
{
"name": "CVE-2024-50236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50236"
},
{
"name": "CVE-2024-50237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50237"
},
{
"name": "CVE-2024-50242",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50242"
},
{
"name": "CVE-2024-50243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50243"
},
{
"name": "CVE-2024-50244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50244"
},
{
"name": "CVE-2024-50245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50245"
},
{
"name": "CVE-2024-50247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50247"
},
{
"name": "CVE-2024-50249",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50249"
},
{
"name": "CVE-2024-50250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50250"
},
{
"name": "CVE-2024-50251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50251"
},
{
"name": "CVE-2024-50252",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50252"
},
{
"name": "CVE-2024-50255",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50255"
},
{
"name": "CVE-2024-50256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50256"
},
{
"name": "CVE-2024-50257",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50257"
},
{
"name": "CVE-2024-50259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50259"
},
{
"name": "CVE-2024-50261",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50261"
},
{
"name": "CVE-2024-50262",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50262"
},
{
"name": "CVE-2024-50265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50265"
},
{
"name": "CVE-2024-50267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50267"
},
{
"name": "CVE-2024-50268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50268"
},
{
"name": "CVE-2024-50269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50269"
},
{
"name": "CVE-2024-50271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50271"
},
{
"name": "CVE-2024-50272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50272"
},
{
"name": "CVE-2024-50273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50273"
},
{
"name": "CVE-2024-50276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50276"
},
{
"name": "CVE-2024-50278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50278"
},
{
"name": "CVE-2024-50279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50279"
},
{
"name": "CVE-2024-50280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50280"
},
{
"name": "CVE-2024-50282",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50282"
},
{
"name": "CVE-2024-50283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50283"
},
{
"name": "CVE-2024-50284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50284"
},
{
"name": "CVE-2024-50286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50286"
},
{
"name": "CVE-2024-50287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50287"
},
{
"name": "CVE-2024-50290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50290"
},
{
"name": "CVE-2024-50292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50292"
},
{
"name": "CVE-2024-50295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50295"
},
{
"name": "CVE-2024-50296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50296"
},
{
"name": "CVE-2024-50299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50299"
},
{
"name": "CVE-2024-50301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50301"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2024-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53042"
},
{
"name": "CVE-2024-53043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53043"
},
{
"name": "CVE-2024-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53052"
},
{
"name": "CVE-2024-53055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53055"
},
{
"name": "CVE-2024-53058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53058"
},
{
"name": "CVE-2024-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53059"
},
{
"name": "CVE-2024-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53060"
},
{
"name": "CVE-2024-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53061"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53066"
},
{
"name": "CVE-2024-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53072"
},
{
"name": "CVE-2024-53081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53081"
},
{
"name": "CVE-2024-53082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53082"
},
{
"name": "CVE-2024-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53088"
},
{
"name": "CVE-2024-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53093"
},
{
"name": "CVE-2024-50226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50226"
},
{
"name": "CVE-2024-49925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49925"
},
{
"name": "CVE-2024-50208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50208"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-50110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50110"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2024-50192",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50192"
},
{
"name": "CVE-2024-49884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49884"
},
{
"name": "CVE-2024-49893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49893"
},
{
"name": "CVE-2024-49921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49921"
},
{
"name": "CVE-2024-50038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50038"
},
{
"name": "CVE-2024-50039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50039"
},
{
"name": "CVE-2024-50093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50093"
},
{
"name": "CVE-2024-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50095"
},
{
"name": "CVE-2024-50096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50096"
},
{
"name": "CVE-2024-50180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50180"
},
{
"name": "CVE-2024-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50184"
},
{
"name": "CVE-2024-50186",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50186"
},
{
"name": "CVE-2024-50188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50188"
},
{
"name": "CVE-2024-50189",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50189"
},
{
"name": "CVE-2024-50191",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50191"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2024-50009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50009"
},
{
"name": "CVE-2024-50026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50026"
},
{
"name": "CVE-2024-50084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50084"
},
{
"name": "CVE-2024-50087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50087"
},
{
"name": "CVE-2024-50088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50088"
},
{
"name": "CVE-2024-50098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50098"
},
{
"name": "CVE-2024-50101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50101"
},
{
"name": "CVE-2024-50103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50103"
},
{
"name": "CVE-2024-50108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50108"
},
{
"name": "CVE-2024-50115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50115"
},
{
"name": "CVE-2024-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50116"
},
{
"name": "CVE-2024-50117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50117"
},
{
"name": "CVE-2024-50121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50121"
},
{
"name": "CVE-2024-50124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50124"
},
{
"name": "CVE-2024-50125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50125"
},
{
"name": "CVE-2024-50127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50127"
},
{
"name": "CVE-2024-50128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50128"
},
{
"name": "CVE-2024-50130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50130"
},
{
"name": "CVE-2024-50131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50131"
},
{
"name": "CVE-2024-50134",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50134"
},
{
"name": "CVE-2024-50135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50135"
},
{
"name": "CVE-2024-50136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50136"
},
{
"name": "CVE-2024-50138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50138"
},
{
"name": "CVE-2024-50139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50139"
},
{
"name": "CVE-2024-50141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50141"
},
{
"name": "CVE-2024-50145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50145"
},
{
"name": "CVE-2024-50146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50146"
},
{
"name": "CVE-2024-50147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50147"
},
{
"name": "CVE-2024-50148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50148"
},
{
"name": "CVE-2024-50150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50150"
},
{
"name": "CVE-2024-50153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50153"
},
{
"name": "CVE-2024-50154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50154"
},
{
"name": "CVE-2024-50155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50155"
},
{
"name": "CVE-2024-50156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50156"
},
{
"name": "CVE-2024-50158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50158"
},
{
"name": "CVE-2024-50159",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50159"
},
{
"name": "CVE-2024-50160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50160"
},
{
"name": "CVE-2024-50166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50166"
},
{
"name": "CVE-2024-50167",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50167"
},
{
"name": "CVE-2024-50169",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50169"
},
{
"name": "CVE-2024-50171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50171"
},
{
"name": "CVE-2024-50172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50172"
},
{
"name": "CVE-2024-50182",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50182"
},
{
"name": "CVE-2024-50183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50183"
},
{
"name": "CVE-2024-50187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50187"
},
{
"name": "CVE-2024-50194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50194"
},
{
"name": "CVE-2024-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50195"
},
{
"name": "CVE-2024-50196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50196"
},
{
"name": "CVE-2024-50198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50198"
},
{
"name": "CVE-2024-50200",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50200"
},
{
"name": "CVE-2024-50201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50201"
},
{
"name": "CVE-2024-50205",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50205"
},
{
"name": "CVE-2024-50209",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50209"
},
{
"name": "CVE-2024-50210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50210"
},
{
"name": "CVE-2024-50216",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50216"
},
{
"name": "CVE-2024-50221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50221"
},
{
"name": "CVE-2024-50224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50224"
},
{
"name": "CVE-2024-50225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50225"
},
{
"name": "CVE-2024-50231",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50231"
},
{
"name": "CVE-2024-50240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50240"
},
{
"name": "CVE-2024-50246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50246"
},
{
"name": "CVE-2024-50248",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50248"
},
{
"name": "CVE-2024-50274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50274"
},
{
"name": "CVE-2024-50275",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50275"
},
{
"name": "CVE-2024-50289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50289"
},
{
"name": "CVE-2024-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50298"
},
{
"name": "CVE-2024-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53045"
},
{
"name": "CVE-2024-53048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53048"
},
{
"name": "CVE-2024-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53051"
},
{
"name": "CVE-2024-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53068"
},
{
"name": "CVE-2024-53076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53076"
},
{
"name": "CVE-2024-53079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53079"
},
{
"name": "CVE-2024-53085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53085"
},
{
"name": "CVE-2024-53094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53094"
},
{
"name": "CVE-2024-53095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53095"
},
{
"name": "CVE-2024-53096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53096"
},
{
"name": "CVE-2024-53100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53100"
},
{
"name": "CVE-2024-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53101"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2024-53106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53106"
},
{
"name": "CVE-2024-53108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53108"
},
{
"name": "CVE-2024-53110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53110"
},
{
"name": "CVE-2024-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53112"
},
{
"name": "CVE-2024-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53114"
},
{
"name": "CVE-2024-53121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53121"
},
{
"name": "CVE-2024-53138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53138"
},
{
"name": "CVE-2024-53142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53142"
},
{
"name": "CVE-2024-50010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50010"
},
{
"name": "CVE-2024-50083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50083"
},
{
"name": "CVE-2024-50085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50085"
},
{
"name": "CVE-2024-50086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50086"
},
{
"name": "CVE-2024-50133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50133"
},
{
"name": "CVE-2024-50143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50143"
},
{
"name": "CVE-2024-50151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50151"
},
{
"name": "CVE-2024-50162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50162"
},
{
"name": "CVE-2024-50163",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50163"
},
{
"name": "CVE-2024-50168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50168"
},
{
"name": "CVE-2024-50185",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50185"
},
{
"name": "CVE-2024-50193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50193"
},
{
"name": "CVE-2024-50199",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50199"
},
{
"name": "CVE-2024-50202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50202"
},
{
"name": "CVE-2024-53097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53097"
},
{
"name": "CVE-2024-53113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53113"
},
{
"name": "CVE-2024-53119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53119"
},
{
"name": "CVE-2024-53120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53120"
},
{
"name": "CVE-2024-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53122"
},
{
"name": "CVE-2024-53123",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53123"
},
{
"name": "CVE-2024-53127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53127"
},
{
"name": "CVE-2024-53129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53129"
},
{
"name": "CVE-2024-53130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53130"
},
{
"name": "CVE-2024-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53131"
},
{
"name": "CVE-2024-53135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53135"
},
{
"name": "CVE-2024-53136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53136"
},
{
"name": "CVE-2024-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53140"
},
{
"name": "CVE-2024-50203",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50203"
},
{
"name": "CVE-2024-50211",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50211"
},
{
"name": "CVE-2024-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53050"
},
{
"name": "CVE-2024-53090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53090"
},
{
"name": "CVE-2024-53099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53099"
},
{
"name": "CVE-2024-53105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53105"
},
{
"name": "CVE-2024-53111",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53111"
},
{
"name": "CVE-2024-53117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53117"
},
{
"name": "CVE-2024-53118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53118"
},
{
"name": "CVE-2024-53125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53125"
},
{
"name": "CVE-2024-53126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53126"
},
{
"name": "CVE-2024-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53133"
},
{
"name": "CVE-2024-53134",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53134"
},
{
"name": "CVE-2024-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53146"
},
{
"name": "CVE-2024-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53148"
},
{
"name": "CVE-2024-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53150"
},
{
"name": "CVE-2024-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53151"
},
{
"name": "CVE-2024-53154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53154"
},
{
"name": "CVE-2024-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53155"
},
{
"name": "CVE-2024-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53156"
},
{
"name": "CVE-2024-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53157"
},
{
"name": "CVE-2024-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53158"
},
{
"name": "CVE-2024-53160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53160"
},
{
"name": "CVE-2024-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
},
{
"name": "CVE-2024-53162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53162"
},
{
"name": "CVE-2024-53166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53166"
},
{
"name": "CVE-2024-53169",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53169"
},
{
"name": "CVE-2024-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53171"
},
{
"name": "CVE-2024-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53173"
},
{
"name": "CVE-2024-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53174"
},
{
"name": "CVE-2024-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53180"
},
{
"name": "CVE-2024-53188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53188"
},
{
"name": "CVE-2024-53190",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53190"
},
{
"name": "CVE-2024-53191",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53191"
},
{
"name": "CVE-2024-53200",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53200"
},
{
"name": "CVE-2024-53201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53201"
},
{
"name": "CVE-2024-53202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53202"
},
{
"name": "CVE-2024-53206",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53206"
},
{
"name": "CVE-2024-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53208"
},
{
"name": "CVE-2024-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53209"
},
{
"name": "CVE-2024-53210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53210"
},
{
"name": "CVE-2024-53213",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53213"
},
{
"name": "CVE-2024-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53214"
},
{
"name": "CVE-2024-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53215"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2024-53222",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53222"
},
{
"name": "CVE-2024-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53224"
},
{
"name": "CVE-2024-53229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53229"
},
{
"name": "CVE-2024-53234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53234"
},
{
"name": "CVE-2024-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53237"
},
{
"name": "CVE-2024-56539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56539"
},
{
"name": "CVE-2024-56549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56549"
},
{
"name": "CVE-2024-56551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56551"
},
{
"name": "CVE-2024-56562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56562"
},
{
"name": "CVE-2024-56566",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56566"
},
{
"name": "CVE-2024-56567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56567"
},
{
"name": "CVE-2024-56576",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56576"
},
{
"name": "CVE-2024-56582",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56582"
},
{
"name": "CVE-2024-56599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56599"
},
{
"name": "CVE-2024-56604",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56604"
},
{
"name": "CVE-2024-56605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56605"
},
{
"name": "CVE-2024-56645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56645"
},
{
"name": "CVE-2024-56752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56752"
},
{
"name": "CVE-2024-56754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56754"
},
{
"name": "CVE-2024-56755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56755"
},
{
"name": "CVE-2024-56756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56756"
},
{
"name": "CVE-2024-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53239"
},
{
"name": "CVE-2024-56548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56548"
},
{
"name": "CVE-2024-56570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56570"
},
{
"name": "CVE-2024-56575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56575"
},
{
"name": "CVE-2024-56598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56598"
},
{
"name": "CVE-2024-56619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56619"
},
{
"name": "CVE-2024-56631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56631"
},
{
"name": "CVE-2024-56704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56704"
},
{
"name": "CVE-2024-36476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36476"
},
{
"name": "CVE-2024-45828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45828"
},
{
"name": "CVE-2024-47141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47141"
},
{
"name": "CVE-2024-47143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47143"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2024-48873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48873"
},
{
"name": "CVE-2024-48881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48881"
},
{
"name": "CVE-2024-49569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49569"
},
{
"name": "CVE-2024-49998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49998"
},
{
"name": "CVE-2024-50051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50051"
},
{
"name": "CVE-2024-52332",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52332"
},
{
"name": "CVE-2024-53091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53091"
},
{
"name": "CVE-2024-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53168"
},
{
"name": "CVE-2024-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53170"
},
{
"name": "CVE-2024-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53172"
},
{
"name": "CVE-2024-53175",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53175"
},
{
"name": "CVE-2024-53185",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53185"
},
{
"name": "CVE-2024-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53194"
},
{
"name": "CVE-2024-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53195"
},
{
"name": "CVE-2024-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53196"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53198"
},
{
"name": "CVE-2024-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53227"
},
{
"name": "CVE-2024-53230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53230"
},
{
"name": "CVE-2024-53231",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53231"
},
{
"name": "CVE-2024-53232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53232"
},
{
"name": "CVE-2024-53233",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53233"
},
{
"name": "CVE-2024-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53236"
},
{
"name": "CVE-2024-53685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53685"
},
{
"name": "CVE-2024-53690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53690"
},
{
"name": "CVE-2024-55881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55881"
},
{
"name": "CVE-2024-55916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55916"
},
{
"name": "CVE-2024-56369",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56369"
},
{
"name": "CVE-2024-56531",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56531"
},
{
"name": "CVE-2024-56532",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56532"
},
{
"name": "CVE-2024-56533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56533"
},
{
"name": "CVE-2024-56538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56538"
},
{
"name": "CVE-2024-56543",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56543"
},
{
"name": "CVE-2024-56546",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56546"
},
{
"name": "CVE-2024-56557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56557"
},
{
"name": "CVE-2024-56558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56558"
},
{
"name": "CVE-2024-56568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56568"
},
{
"name": "CVE-2024-56569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56569"
},
{
"name": "CVE-2024-56572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56572"
},
{
"name": "CVE-2024-56573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56573"
},
{
"name": "CVE-2024-56574",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56574"
},
{
"name": "CVE-2024-56577",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56577"
},
{
"name": "CVE-2024-56578",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56578"
},
{
"name": "CVE-2024-56584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56584"
},
{
"name": "CVE-2024-56587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56587"
},
{
"name": "CVE-2024-56588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56588"
},
{
"name": "CVE-2024-56589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56589"
},
{
"name": "CVE-2024-56590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56590"
},
{
"name": "CVE-2024-56593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56593"
},
{
"name": "CVE-2024-56594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56594"
},
{
"name": "CVE-2024-56595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56595"
},
{
"name": "CVE-2024-56596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56596"
},
{
"name": "CVE-2024-56597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56597"
},
{
"name": "CVE-2024-56602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56602"
},
{
"name": "CVE-2024-56603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56603"
},
{
"name": "CVE-2024-56606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56606"
},
{
"name": "CVE-2024-56607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56607"
},
{
"name": "CVE-2024-56609",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56609"
},
{
"name": "CVE-2024-56611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56611"
},
{
"name": "CVE-2024-56614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56614"
},
{
"name": "CVE-2024-56615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56615"
},
{
"name": "CVE-2024-56616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56616"
},
{
"name": "CVE-2024-56620",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56620"
},
{
"name": "CVE-2024-56622",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56622"
},
{
"name": "CVE-2024-56623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56623"
},
{
"name": "CVE-2024-56625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56625"
},
{
"name": "CVE-2024-56629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56629"
},
{
"name": "CVE-2024-56630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56630"
},
{
"name": "CVE-2024-56632",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56632"
},
{
"name": "CVE-2024-56634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56634"
},
{
"name": "CVE-2024-56635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56635"
},
{
"name": "CVE-2024-56636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56636"
},
{
"name": "CVE-2024-56637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56637"
},
{
"name": "CVE-2024-56641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56641"
},
{
"name": "CVE-2024-56642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56642"
},
{
"name": "CVE-2024-56643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56643"
},
{
"name": "CVE-2024-56644",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56644"
},
{
"name": "CVE-2024-56648",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56648"
},
{
"name": "CVE-2024-56649",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56649"
},
{
"name": "CVE-2024-56651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56651"
},
{
"name": "CVE-2024-56659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56659"
},
{
"name": "CVE-2024-56662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56662"
},
{
"name": "CVE-2024-56663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56663"
},
{
"name": "CVE-2024-56670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56670"
},
{
"name": "CVE-2024-56672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56672"
},
{
"name": "CVE-2024-56677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56677"
},
{
"name": "CVE-2024-56678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56678"
},
{
"name": "CVE-2024-56681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56681"
},
{
"name": "CVE-2024-56683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56683"
},
{
"name": "CVE-2024-56687",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56687"
},
{
"name": "CVE-2024-56688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56688"
},
{
"name": "CVE-2024-56690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56690"
},
{
"name": "CVE-2024-56691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56691"
},
{
"name": "CVE-2024-56694",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56694"
},
{
"name": "CVE-2024-56698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56698"
},
{
"name": "CVE-2024-56700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56700"
},
{
"name": "CVE-2024-56701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56701"
},
{
"name": "CVE-2024-56705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56705"
},
{
"name": "CVE-2024-56708",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56708"
},
{
"name": "CVE-2024-56716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56716"
},
{
"name": "CVE-2024-56722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56722"
},
{
"name": "CVE-2024-56723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56723"
},
{
"name": "CVE-2024-56724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56724"
},
{
"name": "CVE-2024-56729",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56729"
},
{
"name": "CVE-2024-56739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56739"
},
{
"name": "CVE-2024-56745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56745"
},
{
"name": "CVE-2024-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56746"
},
{
"name": "CVE-2024-56747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56747"
},
{
"name": "CVE-2024-56748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56748"
},
{
"name": "CVE-2024-56759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56759"
},
{
"name": "CVE-2024-56765",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56765"
},
{
"name": "CVE-2024-56767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56767"
},
{
"name": "CVE-2024-56769",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56769"
},
{
"name": "CVE-2024-56774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56774"
},
{
"name": "CVE-2024-56775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56775"
},
{
"name": "CVE-2024-56776",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56776"
},
{
"name": "CVE-2024-56777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56777"
},
{
"name": "CVE-2024-56778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56778"
},
{
"name": "CVE-2024-56779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56779"
},
{
"name": "CVE-2024-56780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56780"
},
{
"name": "CVE-2024-56787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56787"
},
{
"name": "CVE-2024-57791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57791"
},
{
"name": "CVE-2024-57792",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57792"
},
{
"name": "CVE-2024-57798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57798"
},
{
"name": "CVE-2024-57838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57838"
},
{
"name": "CVE-2024-57849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57849"
},
{
"name": "CVE-2024-57850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57850"
},
{
"name": "CVE-2024-57874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57874"
},
{
"name": "CVE-2024-57876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57876"
},
{
"name": "CVE-2024-57890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57890"
},
{
"name": "CVE-2024-57892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57892"
},
{
"name": "CVE-2024-57896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57896"
},
{
"name": "CVE-2024-57897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57897"
},
{
"name": "CVE-2024-57903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57903"
},
{
"name": "CVE-2024-57904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57904"
},
{
"name": "CVE-2024-57906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57906"
},
{
"name": "CVE-2024-57907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57907"
},
{
"name": "CVE-2024-57908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57908"
},
{
"name": "CVE-2024-57910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57910"
},
{
"name": "CVE-2024-57911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57911"
},
{
"name": "CVE-2024-57912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57912"
},
{
"name": "CVE-2024-57913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57913"
},
{
"name": "CVE-2024-57922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57922"
},
{
"name": "CVE-2024-57929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57929"
},
{
"name": "CVE-2024-57940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57940"
},
{
"name": "CVE-2025-21646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21646"
},
{
"name": "CVE-2024-53047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53047"
},
{
"name": "CVE-2024-50258",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50258"
},
{
"name": "CVE-2024-50304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50304"
},
{
"name": "CVE-2024-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53187"
},
{
"name": "CVE-2024-53203",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53203"
},
{
"name": "CVE-2024-56592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56592"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-56601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56601"
},
{
"name": "CVE-2024-56608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56608"
},
{
"name": "CVE-2024-56610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56610"
},
{
"name": "CVE-2024-56650",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56650"
},
{
"name": "CVE-2024-56658",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56658"
},
{
"name": "CVE-2024-56679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56679"
},
{
"name": "CVE-2024-56693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56693"
},
{
"name": "CVE-2024-56707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56707"
},
{
"name": "CVE-2024-56715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56715"
},
{
"name": "CVE-2024-56725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56725"
},
{
"name": "CVE-2024-56726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56726"
},
{
"name": "CVE-2024-56727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56727"
},
{
"name": "CVE-2024-56728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56728"
},
{
"name": "CVE-2024-56763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56763"
},
{
"name": "CVE-2024-57802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57802"
},
{
"name": "CVE-2024-57882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57882"
},
{
"name": "CVE-2024-57884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57884"
},
{
"name": "CVE-2024-57917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57917"
},
{
"name": "CVE-2024-57931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57931"
},
{
"name": "CVE-2024-57938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57938"
},
{
"name": "CVE-2024-57946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57946"
},
{
"name": "CVE-2025-21653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21653"
},
{
"name": "CVE-2025-21664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21664"
},
{
"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-50164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50164"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2024-53128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53128"
},
{
"name": "CVE-2024-56703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56703"
},
{
"name": "CVE-2024-57925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57925"
},
{
"name": "CVE-2024-57939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57939"
},
{
"name": "CVE-2024-57948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57948"
},
{
"name": "CVE-2025-21631",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21631"
},
{
"name": "CVE-2025-21636",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21636"
},
{
"name": "CVE-2025-21637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21637"
},
{
"name": "CVE-2025-21638",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21638"
},
{
"name": "CVE-2025-21639",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21639"
},
{
"name": "CVE-2025-21640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21640"
},
{
"name": "CVE-2025-21648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21648"
},
{
"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-2024-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53177"
},
{
"name": "CVE-2024-56633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56633"
},
{
"name": "CVE-2025-21673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21673"
},
{
"name": "CVE-2022-49034",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49034"
},
{
"name": "CVE-2024-47711",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47711"
},
{
"name": "CVE-2024-47726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47726"
},
{
"name": "CVE-2024-49865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49865"
},
{
"name": "CVE-2024-50029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50029"
},
{
"name": "CVE-2024-50030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50030"
},
{
"name": "CVE-2024-50056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50056"
},
{
"name": "CVE-2024-50057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50057"
},
{
"name": "CVE-2024-50065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50065"
},
{
"name": "CVE-2024-50066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50066"
},
{
"name": "CVE-2024-50068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50068"
},
{
"name": "CVE-2024-50070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50070"
},
{
"name": "CVE-2024-50090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50090"
},
{
"name": "CVE-2024-50104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50104"
},
{
"name": "CVE-2024-50105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50105"
},
{
"name": "CVE-2024-50107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50107"
},
{
"name": "CVE-2024-50111",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50111"
},
{
"name": "CVE-2024-50112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50112"
},
{
"name": "CVE-2024-50118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50118"
},
{
"name": "CVE-2024-50120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50120"
},
{
"name": "CVE-2024-50137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50137"
},
{
"name": "CVE-2024-50140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50140"
},
{
"name": "CVE-2024-50152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50152"
},
{
"name": "CVE-2024-50170",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50170"
},
{
"name": "CVE-2024-50197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50197"
},
{
"name": "CVE-2024-50206",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50206"
},
{
"name": "CVE-2024-50207",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50207"
},
{
"name": "CVE-2024-50220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50220"
},
{
"name": "CVE-2024-50222",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50222"
},
{
"name": "CVE-2024-50223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50223"
},
{
"name": "CVE-2024-50238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50238"
},
{
"name": "CVE-2024-50239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50239"
},
{
"name": "CVE-2024-50263",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50263"
},
{
"name": "CVE-2024-50270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50270"
},
{
"name": "CVE-2024-50285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50285"
},
{
"name": "CVE-2024-50288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50288"
},
{
"name": "CVE-2024-50291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50291"
},
{
"name": "CVE-2024-50294",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50294"
},
{
"name": "CVE-2024-50297",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50297"
},
{
"name": "CVE-2024-50300",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50300"
},
{
"name": "CVE-2024-50303",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50303"
},
{
"name": "CVE-2024-53044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53044"
},
{
"name": "CVE-2024-53046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53046"
},
{
"name": "CVE-2024-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53053"
},
{
"name": "CVE-2024-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53062"
},
{
"name": "CVE-2024-53067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53067"
},
{
"name": "CVE-2024-53083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53083"
},
{
"name": "CVE-2024-53084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53084"
},
{
"name": "CVE-2024-53086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53086"
},
{
"name": "CVE-2024-53087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53087"
},
{
"name": "CVE-2024-53089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53089"
},
{
"name": "CVE-2024-53107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53107"
},
{
"name": "CVE-2024-53109",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53109"
},
{
"name": "CVE-2024-53115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53115"
},
{
"name": "CVE-2024-53139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53139"
},
{
"name": "CVE-2024-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53145"
},
{
"name": "CVE-2024-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53147"
},
{
"name": "CVE-2024-53163",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53163"
},
{
"name": "CVE-2024-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53165"
},
{
"name": "CVE-2024-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53176"
},
{
"name": "CVE-2024-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53178"
},
{
"name": "CVE-2024-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53181"
},
{
"name": "CVE-2024-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53183"
},
{
"name": "CVE-2024-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53184"
},
{
"name": "CVE-2024-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53218"
},
{
"name": "CVE-2024-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53219"
},
{
"name": "CVE-2024-53220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53220"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"name": "CVE-2024-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53223"
},
{
"name": "CVE-2024-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53226"
},
{
"name": "CVE-2024-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53228"
},
{
"name": "CVE-2024-56540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56540"
},
{
"name": "CVE-2024-56545",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56545"
},
{
"name": "CVE-2024-56685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56685"
},
{
"name": "CVE-2024-56689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56689"
},
{
"name": "CVE-2024-56692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56692"
},
{
"name": "CVE-2024-56720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56720"
},
{
"name": "CVE-2024-56721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56721"
},
{
"name": "CVE-2024-56742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56742"
},
{
"name": "CVE-2024-56744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56744"
},
{
"name": "CVE-2024-56751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56751"
},
{
"name": "CVE-2025-0927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0927"
},
{
"name": "CVE-2024-56579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56579"
},
{
"name": "CVE-2024-56647",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56647"
},
{
"name": "CVE-2024-57889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57889"
},
{
"name": "CVE-2025-21684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21684"
},
{
"name": "CVE-2025-21687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21687"
},
{
"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-2025-21700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21700"
},
{
"name": "CVE-2024-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43098"
},
{
"name": "CVE-2024-47408",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47408"
},
{
"name": "CVE-2024-49571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49571"
},
{
"name": "CVE-2024-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53680"
},
{
"name": "CVE-2024-56581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56581"
},
{
"name": "CVE-2024-56586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56586"
},
{
"name": "CVE-2024-56626",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56626"
},
{
"name": "CVE-2024-56627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56627"
},
{
"name": "CVE-2024-56640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56640"
},
{
"name": "CVE-2024-56770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56770"
},
{
"name": "CVE-2024-56781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56781"
},
{
"name": "CVE-2024-56783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56783"
},
{
"name": "CVE-2024-56785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56785"
},
{
"name": "CVE-2024-57807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57807"
},
{
"name": "CVE-2024-57841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57841"
},
{
"name": "CVE-2024-57900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57900"
},
{
"name": "CVE-2024-57901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57901"
},
{
"name": "CVE-2024-57902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57902"
},
{
"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-2022-0995",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0995"
},
{
"name": "CVE-2024-41932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41932"
},
{
"name": "CVE-2024-41935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41935"
},
{
"name": "CVE-2024-47794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47794"
},
{
"name": "CVE-2024-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48875"
},
{
"name": "CVE-2024-48876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48876"
},
{
"name": "CVE-2024-56550",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56550"
},
{
"name": "CVE-2024-56561",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56561"
},
{
"name": "CVE-2024-56565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56565"
},
{
"name": "CVE-2024-56580",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56580"
},
{
"name": "CVE-2024-56583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56583"
},
{
"name": "CVE-2024-56613",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56613"
},
{
"name": "CVE-2024-56621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56621"
},
{
"name": "CVE-2024-56638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56638"
},
{
"name": "CVE-2024-56771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56771"
},
{
"name": "CVE-2024-56772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56772"
},
{
"name": "CVE-2024-56773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56773"
},
{
"name": "CVE-2024-56782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56782"
},
{
"name": "CVE-2024-56786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56786"
},
{
"name": "CVE-2024-57843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57843"
},
{
"name": "CVE-2024-57872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57872"
},
{
"name": "CVE-2024-58087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58087"
},
{
"name": "CVE-2025-21701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21701"
},
{
"name": "CVE-2025-21703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21703"
},
{
"name": "CVE-2025-21693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21693"
},
{
"name": "CVE-2025-21756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21756"
},
{
"name": "CVE-2025-21831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21831"
},
{
"name": "CVE-2025-21702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21702"
},
{
"name": "CVE-2025-21993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21993"
},
{
"name": "CVE-2024-44955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44955"
},
{
"name": "CVE-2024-50032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50032"
},
{
"name": "CVE-2024-57950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57950"
},
{
"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-21677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21677"
},
{
"name": "CVE-2025-21685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21685"
},
{
"name": "CVE-2025-21691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21691"
},
{
"name": "CVE-2025-21695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21695"
},
{
"name": "CVE-2025-21696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21696"
},
{
"name": "CVE-2025-2312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2312"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0349",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-04-25T00:00:00.000000"
}
],
"risks": [
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"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, 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-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7459-1",
"url": "https://ubuntu.com/security/notices/USN-7459-1"
},
{
"published_at": "2025-04-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7451-1",
"url": "https://ubuntu.com/security/notices/USN-7451-1"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7449-2",
"url": "https://ubuntu.com/security/notices/USN-7449-2"
},
{
"published_at": "2025-04-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7450-1",
"url": "https://ubuntu.com/security/notices/USN-7450-1"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7461-1",
"url": "https://ubuntu.com/security/notices/USN-7461-1"
},
{
"published_at": "2025-04-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7453-1",
"url": "https://ubuntu.com/security/notices/USN-7453-1"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7462-1",
"url": "https://ubuntu.com/security/notices/USN-7462-1"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7463-1",
"url": "https://ubuntu.com/security/notices/USN-7463-1"
},
{
"published_at": "2025-04-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7445-1",
"url": "https://ubuntu.com/security/notices/USN-7445-1"
},
{
"published_at": "2025-04-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7448-1",
"url": "https://ubuntu.com/security/notices/USN-7448-1"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7461-2",
"url": "https://ubuntu.com/security/notices/USN-7461-2"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7455-1",
"url": "https://ubuntu.com/security/notices/USN-7455-1"
},
{
"published_at": "2025-04-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7402-5",
"url": "https://ubuntu.com/security/notices/USN-7402-5"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7455-2",
"url": "https://ubuntu.com/security/notices/USN-7455-2"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7460-1",
"url": "https://ubuntu.com/security/notices/USN-7460-1"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7462-2",
"url": "https://ubuntu.com/security/notices/USN-7462-2"
},
{
"published_at": "2025-04-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7452-1",
"url": "https://ubuntu.com/security/notices/USN-7452-1"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7458-1",
"url": "https://ubuntu.com/security/notices/USN-7458-1"
},
{
"published_at": "2025-04-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7455-3",
"url": "https://ubuntu.com/security/notices/USN-7455-3"
},
{
"published_at": "2025-04-23",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7449-1",
"url": "https://ubuntu.com/security/notices/USN-7449-1"
}
]
}
CERTFR-2025-AVI-0366
Vulnerability from certfr_avis - Published: - Updated:
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).
| Title | Publication Time | Tags | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.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-26928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26928"
},
{
"name": "CVE-2024-35864",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35864"
},
{
"name": "CVE-2024-36899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36899"
},
{
"name": "CVE-2024-26837",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26837"
},
{
"name": "CVE-2024-41014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41014"
},
{
"name": "CVE-2024-41016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41016"
},
{
"name": "CVE-2024-42122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42122"
},
{
"name": "CVE-2024-42315",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42315"
},
{
"name": "CVE-2024-43900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43900"
},
{
"name": "CVE-2024-44938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44938"
},
{
"name": "CVE-2024-46784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46784"
},
{
"name": "CVE-2024-46826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46826"
},
{
"name": "CVE-2024-46809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46809"
},
{
"name": "CVE-2024-46841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46841"
},
{
"name": "CVE-2024-46871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46871"
},
{
"name": "CVE-2024-47670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47670"
},
{
"name": "CVE-2024-47671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47671"
},
{
"name": "CVE-2024-47672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47672"
},
{
"name": "CVE-2024-47673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47673"
},
{
"name": "CVE-2024-47684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47684"
},
{
"name": "CVE-2024-47685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47685"
},
{
"name": "CVE-2024-47692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47692"
},
{
"name": "CVE-2024-47693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47693"
},
{
"name": "CVE-2024-47695",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47695"
},
{
"name": "CVE-2024-47696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47696"
},
{
"name": "CVE-2024-47697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47697"
},
{
"name": "CVE-2024-47698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47698"
},
{
"name": "CVE-2024-47699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47699"
},
{
"name": "CVE-2024-47704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47704"
},
{
"name": "CVE-2024-47705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47705"
},
{
"name": "CVE-2024-47706",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47706"
},
{
"name": "CVE-2024-47707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47707"
},
{
"name": "CVE-2024-47709",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47709"
},
{
"name": "CVE-2024-47710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47710"
},
{
"name": "CVE-2024-47712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47712"
},
{
"name": "CVE-2024-47713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47713"
},
{
"name": "CVE-2024-47718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47718"
},
{
"name": "CVE-2024-47720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47720"
},
{
"name": "CVE-2024-47723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47723"
},
{
"name": "CVE-2024-47728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47728"
},
{
"name": "CVE-2024-47730",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47730"
},
{
"name": "CVE-2024-47735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47735"
},
{
"name": "CVE-2024-47737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47737"
},
{
"name": "CVE-2024-47738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47738"
},
{
"name": "CVE-2024-47739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47739"
},
{
"name": "CVE-2024-47742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47742"
},
{
"name": "CVE-2024-47745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47745"
},
{
"name": "CVE-2024-47747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47747"
},
{
"name": "CVE-2024-47748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47748"
},
{
"name": "CVE-2024-47749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47749"
},
{
"name": "CVE-2024-47756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47756"
},
{
"name": "CVE-2024-47757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47757"
},
{
"name": "CVE-2024-49851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49851"
},
{
"name": "CVE-2024-49852",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49852"
},
{
"name": "CVE-2024-49855",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49855"
},
{
"name": "CVE-2024-49858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49858"
},
{
"name": "CVE-2024-49860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49860"
},
{
"name": "CVE-2024-49861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49861"
},
{
"name": "CVE-2024-49863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49863"
},
{
"name": "CVE-2024-49866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49866"
},
{
"name": "CVE-2024-49867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49867"
},
{
"name": "CVE-2024-49870",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49870"
},
{
"name": "CVE-2024-49871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49871"
},
{
"name": "CVE-2024-49875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49875"
},
{
"name": "CVE-2024-49877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49877"
},
{
"name": "CVE-2024-49878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49878"
},
{
"name": "CVE-2024-49879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49879"
},
{
"name": "CVE-2024-49881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49881"
},
{
"name": "CVE-2024-49882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49882"
},
{
"name": "CVE-2024-49883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49883"
},
{
"name": "CVE-2024-49886",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49886"
},
{
"name": "CVE-2024-49888",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49888"
},
{
"name": "CVE-2024-49890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49890"
},
{
"name": "CVE-2024-49891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49891"
},
{
"name": "CVE-2024-49892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49892"
},
{
"name": "CVE-2024-49894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49894"
},
{
"name": "CVE-2024-49895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49895"
},
{
"name": "CVE-2024-49896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49896"
},
{
"name": "CVE-2024-49898",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49898"
},
{
"name": "CVE-2024-49899",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49899"
},
{
"name": "CVE-2024-49900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49900"
},
{
"name": "CVE-2024-49901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49901"
},
{
"name": "CVE-2024-49902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49902"
},
{
"name": "CVE-2024-49903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49903"
},
{
"name": "CVE-2024-49906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49906"
},
{
"name": "CVE-2024-49907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49907"
},
{
"name": "CVE-2024-49909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49909"
},
{
"name": "CVE-2024-49911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49911"
},
{
"name": "CVE-2024-49912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49912"
},
{
"name": "CVE-2024-49913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49913"
},
{
"name": "CVE-2024-49914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49914"
},
{
"name": "CVE-2024-49917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49917"
},
{
"name": "CVE-2024-49918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49918"
},
{
"name": "CVE-2024-49919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49919"
},
{
"name": "CVE-2024-49920",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49920"
},
{
"name": "CVE-2024-49922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49922"
},
{
"name": "CVE-2024-49923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49923"
},
{
"name": "CVE-2024-49928",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49928"
},
{
"name": "CVE-2024-49929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49929"
},
{
"name": "CVE-2024-49930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49930"
},
{
"name": "CVE-2024-49931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49931"
},
{
"name": "CVE-2024-49933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49933"
},
{
"name": "CVE-2024-49935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49935"
},
{
"name": "CVE-2024-49936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49936"
},
{
"name": "CVE-2024-49937",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49937"
},
{
"name": "CVE-2024-49938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49938"
},
{
"name": "CVE-2024-49939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49939"
},
{
"name": "CVE-2024-49946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49946"
},
{
"name": "CVE-2024-49949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49949"
},
{
"name": "CVE-2024-49950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49950"
},
{
"name": "CVE-2024-49954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49954"
},
{
"name": "CVE-2024-49955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49955"
},
{
"name": "CVE-2024-49957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49957"
},
{
"name": "CVE-2024-49958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49958"
},
{
"name": "CVE-2024-49959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49959"
},
{
"name": "CVE-2024-49960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49960"
},
{
"name": "CVE-2024-49961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49961"
},
{
"name": "CVE-2024-49962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49962"
},
{
"name": "CVE-2024-49963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49963"
},
{
"name": "CVE-2024-49965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49965"
},
{
"name": "CVE-2024-49966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49966"
},
{
"name": "CVE-2024-49969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49969"
},
{
"name": "CVE-2024-49972",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49972"
},
{
"name": "CVE-2024-49973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49973"
},
{
"name": "CVE-2024-49974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49974"
},
{
"name": "CVE-2024-49975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49975"
},
{
"name": "CVE-2024-49981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49981"
},
{
"name": "CVE-2024-49982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49982"
},
{
"name": "CVE-2024-49985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49985"
},
{
"name": "CVE-2024-49991",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49991"
},
{
"name": "CVE-2024-49996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49996"
},
{
"name": "CVE-2024-50000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50000"
},
{
"name": "CVE-2024-50001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50001"
},
{
"name": "CVE-2024-50002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50002"
},
{
"name": "CVE-2024-50006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50006"
},
{
"name": "CVE-2024-50007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50007"
},
{
"name": "CVE-2024-50008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50008"
},
{
"name": "CVE-2024-50013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50013"
},
{
"name": "CVE-2024-50014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50014"
},
{
"name": "CVE-2024-50015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50015"
},
{
"name": "CVE-2024-50017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50017"
},
{
"name": "CVE-2024-50019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50019"
},
{
"name": "CVE-2024-50020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50020"
},
{
"name": "CVE-2024-50021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50021"
},
{
"name": "CVE-2024-50022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50022"
},
{
"name": "CVE-2024-50023",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50023"
},
{
"name": "CVE-2024-50024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50024"
},
{
"name": "CVE-2024-50025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50025"
},
{
"name": "CVE-2024-50027",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50027"
},
{
"name": "CVE-2024-50028",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50028"
},
{
"name": "CVE-2024-50031",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50031"
},
{
"name": "CVE-2024-50033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50033"
},
{
"name": "CVE-2024-50035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50035"
},
{
"name": "CVE-2024-50040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50040"
},
{
"name": "CVE-2024-50041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50041"
},
{
"name": "CVE-2024-50042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50042"
},
{
"name": "CVE-2024-50044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50044"
},
{
"name": "CVE-2024-50045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50045"
},
{
"name": "CVE-2024-50046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50046"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2024-50048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50048"
},
{
"name": "CVE-2024-50049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50049"
},
{
"name": "CVE-2024-50055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50055"
},
{
"name": "CVE-2024-50058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50058"
},
{
"name": "CVE-2024-50059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50059"
},
{
"name": "CVE-2024-50060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50060"
},
{
"name": "CVE-2024-50061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50061"
},
{
"name": "CVE-2024-50062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50062"
},
{
"name": "CVE-2024-50063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50063"
},
{
"name": "CVE-2024-50064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50064"
},
{
"name": "CVE-2024-50069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50069"
},
{
"name": "CVE-2024-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50073"
},
{
"name": "CVE-2024-50074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50074"
},
{
"name": "CVE-2024-50075",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50075"
},
{
"name": "CVE-2024-50076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50076"
},
{
"name": "CVE-2024-50077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50077"
},
{
"name": "CVE-2024-50078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50078"
},
{
"name": "CVE-2024-50080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50080"
},
{
"name": "CVE-2024-50012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50012"
},
{
"name": "CVE-2024-50036",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50036"
},
{
"name": "CVE-2024-50067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50067"
},
{
"name": "CVE-2024-50072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50072"
},
{
"name": "CVE-2024-50126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50126"
},
{
"name": "CVE-2024-50215",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50215"
},
{
"name": "CVE-2024-50218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50218"
},
{
"name": "CVE-2024-50229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50229"
},
{
"name": "CVE-2024-50230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50230"
},
{
"name": "CVE-2024-50232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50232"
},
{
"name": "CVE-2024-50233",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50233"
},
{
"name": "CVE-2024-50234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50234"
},
{
"name": "CVE-2024-50235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50235"
},
{
"name": "CVE-2024-50236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50236"
},
{
"name": "CVE-2024-50237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50237"
},
{
"name": "CVE-2024-50242",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50242"
},
{
"name": "CVE-2024-50243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50243"
},
{
"name": "CVE-2024-50244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50244"
},
{
"name": "CVE-2024-50245",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50245"
},
{
"name": "CVE-2024-50247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50247"
},
{
"name": "CVE-2024-50250",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50250"
},
{
"name": "CVE-2024-50251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50251"
},
{
"name": "CVE-2024-50252",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50252"
},
{
"name": "CVE-2024-50255",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50255"
},
{
"name": "CVE-2024-50256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50256"
},
{
"name": "CVE-2024-50257",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50257"
},
{
"name": "CVE-2024-50259",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50259"
},
{
"name": "CVE-2024-50261",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50261"
},
{
"name": "CVE-2024-50262",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50262"
},
{
"name": "CVE-2024-50265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50265"
},
{
"name": "CVE-2024-50267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50267"
},
{
"name": "CVE-2024-50268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50268"
},
{
"name": "CVE-2024-50269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50269"
},
{
"name": "CVE-2024-50271",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50271"
},
{
"name": "CVE-2024-50272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50272"
},
{
"name": "CVE-2024-50273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50273"
},
{
"name": "CVE-2024-50276",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50276"
},
{
"name": "CVE-2024-50278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50278"
},
{
"name": "CVE-2024-50279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50279"
},
{
"name": "CVE-2024-50280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50280"
},
{
"name": "CVE-2024-50282",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50282"
},
{
"name": "CVE-2024-50283",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50283"
},
{
"name": "CVE-2024-50284",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50284"
},
{
"name": "CVE-2024-50286",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50286"
},
{
"name": "CVE-2024-50287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50287"
},
{
"name": "CVE-2024-50290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50290"
},
{
"name": "CVE-2024-50292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50292"
},
{
"name": "CVE-2024-50295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50295"
},
{
"name": "CVE-2024-50296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50296"
},
{
"name": "CVE-2024-50299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50299"
},
{
"name": "CVE-2024-50301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50301"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2024-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53042"
},
{
"name": "CVE-2024-53043",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53043"
},
{
"name": "CVE-2024-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53052"
},
{
"name": "CVE-2024-53055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53055"
},
{
"name": "CVE-2024-53058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53058"
},
{
"name": "CVE-2024-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53059"
},
{
"name": "CVE-2024-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53061"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53066"
},
{
"name": "CVE-2024-53072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53072"
},
{
"name": "CVE-2024-53081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53081"
},
{
"name": "CVE-2024-53082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53082"
},
{
"name": "CVE-2024-53088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53088"
},
{
"name": "CVE-2024-53093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53093"
},
{
"name": "CVE-2024-50226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50226"
},
{
"name": "CVE-2024-49925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49925"
},
{
"name": "CVE-2024-49945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49945"
},
{
"name": "CVE-2024-50208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50208"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-50110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50110"
},
{
"name": "CVE-2024-50142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50142"
},
{
"name": "CVE-2024-50192",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50192"
},
{
"name": "CVE-2024-47679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47679"
},
{
"name": "CVE-2024-47690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47690"
},
{
"name": "CVE-2024-47701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47701"
},
{
"name": "CVE-2024-47734",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47734"
},
{
"name": "CVE-2024-47740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47740"
},
{
"name": "CVE-2024-49856",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49856"
},
{
"name": "CVE-2024-49868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49868"
},
{
"name": "CVE-2024-49884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49884"
},
{
"name": "CVE-2024-49889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49889"
},
{
"name": "CVE-2024-49893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49893"
},
{
"name": "CVE-2024-49905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49905"
},
{
"name": "CVE-2024-49915",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49915"
},
{
"name": "CVE-2024-49921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49921"
},
{
"name": "CVE-2024-49924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49924"
},
{
"name": "CVE-2024-49927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49927"
},
{
"name": "CVE-2024-49944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49944"
},
{
"name": "CVE-2024-49948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49948"
},
{
"name": "CVE-2024-49952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49952"
},
{
"name": "CVE-2024-49977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49977"
},
{
"name": "CVE-2024-49983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49983"
},
{
"name": "CVE-2024-49997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49997"
},
{
"name": "CVE-2024-50038",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50038"
},
{
"name": "CVE-2024-50039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50039"
},
{
"name": "CVE-2024-50093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50093"
},
{
"name": "CVE-2024-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50095"
},
{
"name": "CVE-2024-50096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50096"
},
{
"name": "CVE-2024-50179",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50179"
},
{
"name": "CVE-2024-50180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50180"
},
{
"name": "CVE-2024-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50184"
},
{
"name": "CVE-2024-50186",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50186"
},
{
"name": "CVE-2024-50188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50188"
},
{
"name": "CVE-2024-50189",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50189"
},
{
"name": "CVE-2024-50191",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50191"
},
{
"name": "CVE-2024-47703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47703"
},
{
"name": "CVE-2024-49934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49934"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2024-49987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49987"
},
{
"name": "CVE-2024-49989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49989"
},
{
"name": "CVE-2024-50009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50009"
},
{
"name": "CVE-2024-50026",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50026"
},
{
"name": "CVE-2024-50084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50084"
},
{
"name": "CVE-2024-50087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50087"
},
{
"name": "CVE-2024-50088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50088"
},
{
"name": "CVE-2024-50098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50098"
},
{
"name": "CVE-2024-50101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50101"
},
{
"name": "CVE-2024-50103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50103"
},
{
"name": "CVE-2024-50108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50108"
},
{
"name": "CVE-2024-50115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50115"
},
{
"name": "CVE-2024-50116",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50116"
},
{
"name": "CVE-2024-50117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50117"
},
{
"name": "CVE-2024-50121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50121"
},
{
"name": "CVE-2024-50124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50124"
},
{
"name": "CVE-2024-50125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50125"
},
{
"name": "CVE-2024-50127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50127"
},
{
"name": "CVE-2024-50128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50128"
},
{
"name": "CVE-2024-50130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50130"
},
{
"name": "CVE-2024-50131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50131"
},
{
"name": "CVE-2024-50134",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50134"
},
{
"name": "CVE-2024-50135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50135"
},
{
"name": "CVE-2024-50136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50136"
},
{
"name": "CVE-2024-50138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50138"
},
{
"name": "CVE-2024-50139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50139"
},
{
"name": "CVE-2024-50141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50141"
},
{
"name": "CVE-2024-50145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50145"
},
{
"name": "CVE-2024-50146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50146"
},
{
"name": "CVE-2024-50147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50147"
},
{
"name": "CVE-2024-50148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50148"
},
{
"name": "CVE-2024-50150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50150"
},
{
"name": "CVE-2024-50153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50153"
},
{
"name": "CVE-2024-50154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50154"
},
{
"name": "CVE-2024-50155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50155"
},
{
"name": "CVE-2024-50156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50156"
},
{
"name": "CVE-2024-50158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50158"
},
{
"name": "CVE-2024-50159",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50159"
},
{
"name": "CVE-2024-50160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50160"
},
{
"name": "CVE-2024-50166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50166"
},
{
"name": "CVE-2024-50167",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50167"
},
{
"name": "CVE-2024-50169",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50169"
},
{
"name": "CVE-2024-50171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50171"
},
{
"name": "CVE-2024-50172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50172"
},
{
"name": "CVE-2024-50182",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50182"
},
{
"name": "CVE-2024-50183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50183"
},
{
"name": "CVE-2024-50187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50187"
},
{
"name": "CVE-2024-50194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50194"
},
{
"name": "CVE-2024-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50195"
},
{
"name": "CVE-2024-50196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50196"
},
{
"name": "CVE-2024-50198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50198"
},
{
"name": "CVE-2024-50200",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50200"
},
{
"name": "CVE-2024-50201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50201"
},
{
"name": "CVE-2024-50205",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50205"
},
{
"name": "CVE-2024-50209",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50209"
},
{
"name": "CVE-2024-50216",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50216"
},
{
"name": "CVE-2024-50221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50221"
},
{
"name": "CVE-2024-50224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50224"
},
{
"name": "CVE-2024-50225",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50225"
},
{
"name": "CVE-2024-50231",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50231"
},
{
"name": "CVE-2024-50240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50240"
},
{
"name": "CVE-2024-50246",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50246"
},
{
"name": "CVE-2024-50248",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50248"
},
{
"name": "CVE-2024-50274",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50274"
},
{
"name": "CVE-2024-50275",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50275"
},
{
"name": "CVE-2024-50289",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50289"
},
{
"name": "CVE-2024-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50298"
},
{
"name": "CVE-2024-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53045"
},
{
"name": "CVE-2024-53048",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53048"
},
{
"name": "CVE-2024-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53051"
},
{
"name": "CVE-2024-53068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53068"
},
{
"name": "CVE-2024-53076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53076"
},
{
"name": "CVE-2024-53079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53079"
},
{
"name": "CVE-2024-53085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53085"
},
{
"name": "CVE-2024-53094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53094"
},
{
"name": "CVE-2024-53095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53095"
},
{
"name": "CVE-2024-53096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53096"
},
{
"name": "CVE-2024-53100",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53100"
},
{
"name": "CVE-2024-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53101"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2024-53106",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53106"
},
{
"name": "CVE-2024-53108",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53108"
},
{
"name": "CVE-2024-53110",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53110"
},
{
"name": "CVE-2024-53112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53112"
},
{
"name": "CVE-2024-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53114"
},
{
"name": "CVE-2024-53121",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53121"
},
{
"name": "CVE-2024-53138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53138"
},
{
"name": "CVE-2024-53142",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53142"
},
{
"name": "CVE-2024-47678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47678"
},
{
"name": "CVE-2024-49859",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49859"
},
{
"name": "CVE-2024-49978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49978"
},
{
"name": "CVE-2024-49992",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49992"
},
{
"name": "CVE-2024-50010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50010"
},
{
"name": "CVE-2024-50083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50083"
},
{
"name": "CVE-2024-50085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50085"
},
{
"name": "CVE-2024-50086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50086"
},
{
"name": "CVE-2024-50133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50133"
},
{
"name": "CVE-2024-50143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50143"
},
{
"name": "CVE-2024-50151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50151"
},
{
"name": "CVE-2024-50162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50162"
},
{
"name": "CVE-2024-50163",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50163"
},
{
"name": "CVE-2024-50168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50168"
},
{
"name": "CVE-2024-50185",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50185"
},
{
"name": "CVE-2024-50193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50193"
},
{
"name": "CVE-2024-50199",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50199"
},
{
"name": "CVE-2024-50202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50202"
},
{
"name": "CVE-2024-53103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53103"
},
{
"name": "CVE-2024-53113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53113"
},
{
"name": "CVE-2024-53119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53119"
},
{
"name": "CVE-2024-53120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53120"
},
{
"name": "CVE-2024-53122",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53122"
},
{
"name": "CVE-2024-53123",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53123"
},
{
"name": "CVE-2024-53127",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53127"
},
{
"name": "CVE-2024-53129",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53129"
},
{
"name": "CVE-2024-53130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53130"
},
{
"name": "CVE-2024-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53131"
},
{
"name": "CVE-2024-53135",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53135"
},
{
"name": "CVE-2024-53136",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53136"
},
{
"name": "CVE-2024-53140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53140"
},
{
"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-50016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50016"
},
{
"name": "CVE-2024-50203",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50203"
},
{
"name": "CVE-2024-50211",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50211"
},
{
"name": "CVE-2024-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53050"
},
{
"name": "CVE-2024-53090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53090"
},
{
"name": "CVE-2024-53099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53099"
},
{
"name": "CVE-2024-53105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53105"
},
{
"name": "CVE-2024-53111",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53111"
},
{
"name": "CVE-2024-53117",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53117"
},
{
"name": "CVE-2024-53118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53118"
},
{
"name": "CVE-2024-53125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53125"
},
{
"name": "CVE-2024-53126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53126"
},
{
"name": "CVE-2024-53133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53133"
},
{
"name": "CVE-2024-53134",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53134"
},
{
"name": "CVE-2024-53141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53141"
},
{
"name": "CVE-2024-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53146"
},
{
"name": "CVE-2024-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53148"
},
{
"name": "CVE-2024-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53150"
},
{
"name": "CVE-2024-53151",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53151"
},
{
"name": "CVE-2024-53154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53154"
},
{
"name": "CVE-2024-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53155"
},
{
"name": "CVE-2024-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53156"
},
{
"name": "CVE-2024-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53157"
},
{
"name": "CVE-2024-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53158"
},
{
"name": "CVE-2024-53160",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53160"
},
{
"name": "CVE-2024-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
},
{
"name": "CVE-2024-53162",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53162"
},
{
"name": "CVE-2024-53166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53166"
},
{
"name": "CVE-2024-53169",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53169"
},
{
"name": "CVE-2024-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53171"
},
{
"name": "CVE-2024-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53173"
},
{
"name": "CVE-2024-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53174"
},
{
"name": "CVE-2024-53180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53180"
},
{
"name": "CVE-2024-53188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53188"
},
{
"name": "CVE-2024-53190",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53190"
},
{
"name": "CVE-2024-53191",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53191"
},
{
"name": "CVE-2024-53200",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53200"
},
{
"name": "CVE-2024-53202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53202"
},
{
"name": "CVE-2024-53206",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53206"
},
{
"name": "CVE-2024-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53208"
},
{
"name": "CVE-2024-53209",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53209"
},
{
"name": "CVE-2024-53210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53210"
},
{
"name": "CVE-2024-53213",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53213"
},
{
"name": "CVE-2024-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53214"
},
{
"name": "CVE-2024-53215",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53215"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2024-53222",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53222"
},
{
"name": "CVE-2024-53224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53224"
},
{
"name": "CVE-2024-53229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53229"
},
{
"name": "CVE-2024-53234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53234"
},
{
"name": "CVE-2024-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53237"
},
{
"name": "CVE-2024-56539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56539"
},
{
"name": "CVE-2024-56549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56549"
},
{
"name": "CVE-2024-56551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56551"
},
{
"name": "CVE-2024-56562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56562"
},
{
"name": "CVE-2024-56566",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56566"
},
{
"name": "CVE-2024-56567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56567"
},
{
"name": "CVE-2024-56576",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56576"
},
{
"name": "CVE-2024-56582",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56582"
},
{
"name": "CVE-2024-56599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56599"
},
{
"name": "CVE-2024-56604",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56604"
},
{
"name": "CVE-2024-56605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56605"
},
{
"name": "CVE-2024-56645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56645"
},
{
"name": "CVE-2024-56752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56752"
},
{
"name": "CVE-2024-56754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56754"
},
{
"name": "CVE-2024-56755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56755"
},
{
"name": "CVE-2024-56756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56756"
},
{
"name": "CVE-2024-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53239"
},
{
"name": "CVE-2024-56548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56548"
},
{
"name": "CVE-2024-56570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56570"
},
{
"name": "CVE-2024-56575",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56575"
},
{
"name": "CVE-2024-56598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56598"
},
{
"name": "CVE-2024-56619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56619"
},
{
"name": "CVE-2024-56631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56631"
},
{
"name": "CVE-2024-56704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56704"
},
{
"name": "CVE-2024-36476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36476"
},
{
"name": "CVE-2024-45828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45828"
},
{
"name": "CVE-2024-47141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47141"
},
{
"name": "CVE-2024-47143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47143"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2024-48873",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48873"
},
{
"name": "CVE-2024-48881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48881"
},
{
"name": "CVE-2024-49569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49569"
},
{
"name": "CVE-2024-49998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49998"
},
{
"name": "CVE-2024-50051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50051"
},
{
"name": "CVE-2024-52332",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52332"
},
{
"name": "CVE-2024-53091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53091"
},
{
"name": "CVE-2024-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53168"
},
{
"name": "CVE-2024-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53170"
},
{
"name": "CVE-2024-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53172"
},
{
"name": "CVE-2024-53175",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53175"
},
{
"name": "CVE-2024-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53194"
},
{
"name": "CVE-2024-53195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53195"
},
{
"name": "CVE-2024-53196",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53196"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53198"
},
{
"name": "CVE-2024-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53227"
},
{
"name": "CVE-2024-53230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53230"
},
{
"name": "CVE-2024-53231",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53231"
},
{
"name": "CVE-2024-53232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53232"
},
{
"name": "CVE-2024-53233",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53233"
},
{
"name": "CVE-2024-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53236"
},
{
"name": "CVE-2024-53685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53685"
},
{
"name": "CVE-2024-53690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53690"
},
{
"name": "CVE-2024-55881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55881"
},
{
"name": "CVE-2024-55916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55916"
},
{
"name": "CVE-2024-56369",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56369"
},
{
"name": "CVE-2024-56531",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56531"
},
{
"name": "CVE-2024-56532",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56532"
},
{
"name": "CVE-2024-56533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56533"
},
{
"name": "CVE-2024-56538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56538"
},
{
"name": "CVE-2024-56543",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56543"
},
{
"name": "CVE-2024-56546",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56546"
},
{
"name": "CVE-2024-56557",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56557"
},
{
"name": "CVE-2024-56558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56558"
},
{
"name": "CVE-2024-56568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56568"
},
{
"name": "CVE-2024-56569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56569"
},
{
"name": "CVE-2024-56572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56572"
},
{
"name": "CVE-2024-56573",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56573"
},
{
"name": "CVE-2024-56574",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56574"
},
{
"name": "CVE-2024-53164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53164"
},
{
"name": "CVE-2024-56577",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56577"
},
{
"name": "CVE-2024-56578",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56578"
},
{
"name": "CVE-2024-56584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56584"
},
{
"name": "CVE-2024-56587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56587"
},
{
"name": "CVE-2024-56588",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56588"
},
{
"name": "CVE-2024-56589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56589"
},
{
"name": "CVE-2024-56590",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56590"
},
{
"name": "CVE-2024-56593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56593"
},
{
"name": "CVE-2024-56594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56594"
},
{
"name": "CVE-2024-56595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56595"
},
{
"name": "CVE-2024-56596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56596"
},
{
"name": "CVE-2024-56597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56597"
},
{
"name": "CVE-2024-56602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56602"
},
{
"name": "CVE-2024-56603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56603"
},
{
"name": "CVE-2024-56606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56606"
},
{
"name": "CVE-2024-56607",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56607"
},
{
"name": "CVE-2024-56609",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56609"
},
{
"name": "CVE-2024-56611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56611"
},
{
"name": "CVE-2024-56614",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56614"
},
{
"name": "CVE-2024-56615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56615"
},
{
"name": "CVE-2024-56616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56616"
},
{
"name": "CVE-2024-56620",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56620"
},
{
"name": "CVE-2024-56622",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56622"
},
{
"name": "CVE-2024-56623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56623"
},
{
"name": "CVE-2024-56625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56625"
},
{
"name": "CVE-2024-56629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56629"
},
{
"name": "CVE-2024-56630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56630"
},
{
"name": "CVE-2024-56632",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56632"
},
{
"name": "CVE-2024-56634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56634"
},
{
"name": "CVE-2024-56635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56635"
},
{
"name": "CVE-2024-56636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56636"
},
{
"name": "CVE-2024-56637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56637"
},
{
"name": "CVE-2024-56641",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56641"
},
{
"name": "CVE-2024-56642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56642"
},
{
"name": "CVE-2024-56643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56643"
},
{
"name": "CVE-2024-56644",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56644"
},
{
"name": "CVE-2024-56648",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56648"
},
{
"name": "CVE-2024-56649",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56649"
},
{
"name": "CVE-2024-56651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56651"
},
{
"name": "CVE-2024-56659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56659"
},
{
"name": "CVE-2024-56662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56662"
},
{
"name": "CVE-2024-56663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56663"
},
{
"name": "CVE-2024-56670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56670"
},
{
"name": "CVE-2024-56672",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56672"
},
{
"name": "CVE-2024-56677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56677"
},
{
"name": "CVE-2024-56678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56678"
},
{
"name": "CVE-2024-56681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56681"
},
{
"name": "CVE-2024-56683",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56683"
},
{
"name": "CVE-2024-56687",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56687"
},
{
"name": "CVE-2024-56688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56688"
},
{
"name": "CVE-2024-56690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56690"
},
{
"name": "CVE-2024-56691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56691"
},
{
"name": "CVE-2024-56694",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56694"
},
{
"name": "CVE-2024-56698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56698"
},
{
"name": "CVE-2024-56700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56700"
},
{
"name": "CVE-2024-56701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56701"
},
{
"name": "CVE-2024-56705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56705"
},
{
"name": "CVE-2024-56708",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56708"
},
{
"name": "CVE-2024-56716",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56716"
},
{
"name": "CVE-2024-56722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56722"
},
{
"name": "CVE-2024-56723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56723"
},
{
"name": "CVE-2024-56724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56724"
},
{
"name": "CVE-2024-56729",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56729"
},
{
"name": "CVE-2024-56739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56739"
},
{
"name": "CVE-2024-56745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56745"
},
{
"name": "CVE-2024-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56746"
},
{
"name": "CVE-2024-56747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56747"
},
{
"name": "CVE-2024-56748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56748"
},
{
"name": "CVE-2024-56759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56759"
},
{
"name": "CVE-2024-56765",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56765"
},
{
"name": "CVE-2024-56767",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56767"
},
{
"name": "CVE-2024-56769",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56769"
},
{
"name": "CVE-2024-56774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56774"
},
{
"name": "CVE-2024-56775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56775"
},
{
"name": "CVE-2024-56776",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56776"
},
{
"name": "CVE-2024-56777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56777"
},
{
"name": "CVE-2024-56778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56778"
},
{
"name": "CVE-2024-56779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56779"
},
{
"name": "CVE-2024-56780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56780"
},
{
"name": "CVE-2024-56787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56787"
},
{
"name": "CVE-2024-57791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57791"
},
{
"name": "CVE-2024-57792",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57792"
},
{
"name": "CVE-2024-57798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57798"
},
{
"name": "CVE-2024-57838",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57838"
},
{
"name": "CVE-2024-57849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57849"
},
{
"name": "CVE-2024-57850",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57850"
},
{
"name": "CVE-2024-57874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57874"
},
{
"name": "CVE-2024-57876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57876"
},
{
"name": "CVE-2024-57890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57890"
},
{
"name": "CVE-2024-57892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57892"
},
{
"name": "CVE-2024-57896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57896"
},
{
"name": "CVE-2024-57897",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57897"
},
{
"name": "CVE-2024-57903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57903"
},
{
"name": "CVE-2024-57904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57904"
},
{
"name": "CVE-2024-57906",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57906"
},
{
"name": "CVE-2024-57907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57907"
},
{
"name": "CVE-2024-57908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57908"
},
{
"name": "CVE-2024-57910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57910"
},
{
"name": "CVE-2024-57911",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57911"
},
{
"name": "CVE-2024-57912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57912"
},
{
"name": "CVE-2024-57913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57913"
},
{
"name": "CVE-2024-57922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57922"
},
{
"name": "CVE-2024-57929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57929"
},
{
"name": "CVE-2024-57940",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57940"
},
{
"name": "CVE-2025-21646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21646"
},
{
"name": "CVE-2024-53047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53047"
},
{
"name": "CVE-2024-50258",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50258"
},
{
"name": "CVE-2024-50304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50304"
},
{
"name": "CVE-2024-53187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53187"
},
{
"name": "CVE-2024-53203",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53203"
},
{
"name": "CVE-2024-56592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56592"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-56601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56601"
},
{
"name": "CVE-2024-56608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56608"
},
{
"name": "CVE-2024-56610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56610"
},
{
"name": "CVE-2024-56650",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56650"
},
{
"name": "CVE-2024-56658",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56658"
},
{
"name": "CVE-2024-56679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56679"
},
{
"name": "CVE-2024-56693",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56693"
},
{
"name": "CVE-2024-56707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56707"
},
{
"name": "CVE-2024-56715",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56715"
},
{
"name": "CVE-2024-56725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56725"
},
{
"name": "CVE-2024-56726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56726"
},
{
"name": "CVE-2024-56727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56727"
},
{
"name": "CVE-2024-56728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56728"
},
{
"name": "CVE-2024-56763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56763"
},
{
"name": "CVE-2024-57802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57802"
},
{
"name": "CVE-2024-57882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57882"
},
{
"name": "CVE-2024-57884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57884"
},
{
"name": "CVE-2024-57917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57917"
},
{
"name": "CVE-2024-57931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57931"
},
{
"name": "CVE-2024-57938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57938"
},
{
"name": "CVE-2024-57946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57946"
},
{
"name": "CVE-2025-21653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21653"
},
{
"name": "CVE-2025-21664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21664"
},
{
"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-21678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21678"
},
{
"name": "CVE-2024-49994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49994"
},
{
"name": "CVE-2024-50164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50164"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2024-53128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53128"
},
{
"name": "CVE-2024-56703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56703"
},
{
"name": "CVE-2024-57925",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57925"
},
{
"name": "CVE-2024-57939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57939"
},
{
"name": "CVE-2024-57948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57948"
},
{
"name": "CVE-2025-21631",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21631"
},
{
"name": "CVE-2025-21636",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21636"
},
{
"name": "CVE-2025-21637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21637"
},
{
"name": "CVE-2025-21638",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21638"
},
{
"name": "CVE-2025-21639",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21639"
},
{
"name": "CVE-2025-21640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21640"
},
{
"name": "CVE-2025-21648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21648"
},
{
"name": "CVE-2025-21665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21665"
},
{
"name": "CVE-2025-21680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21680"
},
{
"name": "CVE-2025-21683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21683"
},
{
"name": "CVE-2024-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53177"
},
{
"name": "CVE-2024-56633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56633"
},
{
"name": "CVE-2022-49034",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49034"
},
{
"name": "CVE-2024-47689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47689"
},
{
"name": "CVE-2024-47691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47691"
},
{
"name": "CVE-2024-47711",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47711"
},
{
"name": "CVE-2024-47726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47726"
},
{
"name": "CVE-2024-49865",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49865"
},
{
"name": "CVE-2024-49880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49880"
},
{
"name": "CVE-2024-49926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49926"
},
{
"name": "CVE-2024-49988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49988"
},
{
"name": "CVE-2024-50029",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50029"
},
{
"name": "CVE-2024-50030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50030"
},
{
"name": "CVE-2024-50056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50056"
},
{
"name": "CVE-2024-50057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50057"
},
{
"name": "CVE-2024-50065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50065"
},
{
"name": "CVE-2024-50066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50066"
},
{
"name": "CVE-2024-50068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50068"
},
{
"name": "CVE-2024-50070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50070"
},
{
"name": "CVE-2024-50090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50090"
},
{
"name": "CVE-2024-50104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50104"
},
{
"name": "CVE-2024-50105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50105"
},
{
"name": "CVE-2024-50107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50107"
},
{
"name": "CVE-2024-50111",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50111"
},
{
"name": "CVE-2024-50112",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50112"
},
{
"name": "CVE-2024-50118",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50118"
},
{
"name": "CVE-2024-50120",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50120"
},
{
"name": "CVE-2024-50137",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50137"
},
{
"name": "CVE-2024-50140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50140"
},
{
"name": "CVE-2024-50152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50152"
},
{
"name": "CVE-2024-50170",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50170"
},
{
"name": "CVE-2024-50197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50197"
},
{
"name": "CVE-2024-50206",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50206"
},
{
"name": "CVE-2024-50207",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50207"
},
{
"name": "CVE-2024-50220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50220"
},
{
"name": "CVE-2024-50222",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50222"
},
{
"name": "CVE-2024-50223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50223"
},
{
"name": "CVE-2024-50238",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50238"
},
{
"name": "CVE-2024-50239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50239"
},
{
"name": "CVE-2024-50263",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50263"
},
{
"name": "CVE-2024-50270",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50270"
},
{
"name": "CVE-2024-50285",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50285"
},
{
"name": "CVE-2024-50288",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50288"
},
{
"name": "CVE-2024-50291",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50291"
},
{
"name": "CVE-2024-50294",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50294"
},
{
"name": "CVE-2024-50297",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50297"
},
{
"name": "CVE-2024-50300",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50300"
},
{
"name": "CVE-2024-50303",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50303"
},
{
"name": "CVE-2024-53044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53044"
},
{
"name": "CVE-2024-53046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53046"
},
{
"name": "CVE-2024-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53053"
},
{
"name": "CVE-2024-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53062"
},
{
"name": "CVE-2024-53067",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53067"
},
{
"name": "CVE-2024-53083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53083"
},
{
"name": "CVE-2024-53084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53084"
},
{
"name": "CVE-2024-53086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53086"
},
{
"name": "CVE-2024-53087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53087"
},
{
"name": "CVE-2024-53089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53089"
},
{
"name": "CVE-2024-53107",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53107"
},
{
"name": "CVE-2024-53109",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53109"
},
{
"name": "CVE-2024-53115",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53115"
},
{
"name": "CVE-2024-53139",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53139"
},
{
"name": "CVE-2024-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53145"
},
{
"name": "CVE-2024-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53147"
},
{
"name": "CVE-2024-53163",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53163"
},
{
"name": "CVE-2024-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53165"
},
{
"name": "CVE-2024-53176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53176"
},
{
"name": "CVE-2024-53178",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53178"
},
{
"name": "CVE-2024-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53181"
},
{
"name": "CVE-2024-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53183"
},
{
"name": "CVE-2024-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53184"
},
{
"name": "CVE-2024-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53218"
},
{
"name": "CVE-2024-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53219"
},
{
"name": "CVE-2024-53220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53220"
},
{
"name": "CVE-2024-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53221"
},
{
"name": "CVE-2024-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53223"
},
{
"name": "CVE-2024-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53226"
},
{
"name": "CVE-2024-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53228"
},
{
"name": "CVE-2024-56540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56540"
},
{
"name": "CVE-2024-56545",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56545"
},
{
"name": "CVE-2024-56685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56685"
},
{
"name": "CVE-2024-56689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56689"
},
{
"name": "CVE-2024-56692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56692"
},
{
"name": "CVE-2024-56720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56720"
},
{
"name": "CVE-2024-56721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56721"
},
{
"name": "CVE-2024-56742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56742"
},
{
"name": "CVE-2024-56744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56744"
},
{
"name": "CVE-2024-56751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56751"
},
{
"name": "CVE-2025-0927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0927"
},
{
"name": "CVE-2024-56579",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56579"
},
{
"name": "CVE-2024-56647",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56647"
},
{
"name": "CVE-2024-57889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57889"
},
{
"name": "CVE-2025-21687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21687"
},
{
"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-2025-21700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21700"
},
{
"name": "CVE-2024-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43098"
},
{
"name": "CVE-2024-47408",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47408"
},
{
"name": "CVE-2024-49571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49571"
},
{
"name": "CVE-2024-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53680"
},
{
"name": "CVE-2024-56581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56581"
},
{
"name": "CVE-2024-56586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56586"
},
{
"name": "CVE-2024-56626",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56626"
},
{
"name": "CVE-2024-56627",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56627"
},
{
"name": "CVE-2024-56640",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56640"
},
{
"name": "CVE-2024-56770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56770"
},
{
"name": "CVE-2024-56781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56781"
},
{
"name": "CVE-2024-56785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56785"
},
{
"name": "CVE-2024-57807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57807"
},
{
"name": "CVE-2024-57841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57841"
},
{
"name": "CVE-2024-57900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57900"
},
{
"name": "CVE-2024-57901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57901"
},
{
"name": "CVE-2024-57902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57902"
},
{
"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-2022-0995",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0995"
},
{
"name": "CVE-2024-41932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41932"
},
{
"name": "CVE-2024-41935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41935"
},
{
"name": "CVE-2024-47794",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47794"
},
{
"name": "CVE-2024-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48875"
},
{
"name": "CVE-2024-48876",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48876"
},
{
"name": "CVE-2024-56550",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56550"
},
{
"name": "CVE-2024-56565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56565"
},
{
"name": "CVE-2024-56580",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56580"
},
{
"name": "CVE-2024-56583",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56583"
},
{
"name": "CVE-2024-56613",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56613"
},
{
"name": "CVE-2024-56621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56621"
},
{
"name": "CVE-2024-56638",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56638"
},
{
"name": "CVE-2024-56771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56771"
},
{
"name": "CVE-2024-56772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56772"
},
{
"name": "CVE-2024-56773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56773"
},
{
"name": "CVE-2024-56782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56782"
},
{
"name": "CVE-2024-56786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56786"
},
{
"name": "CVE-2024-57843",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57843"
},
{
"name": "CVE-2024-57872",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57872"
},
{
"name": "CVE-2024-58087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58087"
},
{
"name": "CVE-2025-21701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21701"
},
{
"name": "CVE-2025-21703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21703"
},
{
"name": "CVE-2025-21756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21756"
},
{
"name": "CVE-2025-21831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21831"
},
{
"name": "CVE-2025-21702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21702"
},
{
"name": "CVE-2025-21993",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21993"
},
{
"name": "CVE-2024-44955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44955"
},
{
"name": "CVE-2025-2312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2312"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0366",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-05-02T00:00:00.000000"
}
],
"risks": [
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"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-04-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7455-4",
"url": "https://ubuntu.com/security/notices/USN-7455-4"
},
{
"published_at": "2025-04-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7459-2",
"url": "https://ubuntu.com/security/notices/USN-7459-2"
},
{
"published_at": "2025-04-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7468-1",
"url": "https://ubuntu.com/security/notices/USN-7468-1"
},
{
"published_at": "2025-04-29",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7455-5",
"url": "https://ubuntu.com/security/notices/USN-7455-5"
}
]
}
CERTFR-2025-AVI-0677
Vulnerability from certfr_avis - Published: - Updated:
De multiples vulnérabilités ont été découvertes dans les produits Siemens. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Siemens | N/A | SIMATIC PCS neo V6.0 versions antérieures à V6.0 SP1 | ||
| Siemens | N/A | SIMATIC WinCC V17, v18 et V20 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC Control Function Library (CFL) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIPROTEC 5 versions antérieures à 10.0 | ||
| Siemens | N/A | SIMATIC MTP Integrator toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ProSave V17 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Unified Line Coordination toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC TeleControl toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC OA V3.19 versions antérieures à V3.19 P020 | ||
| Siemens | N/A | SIMATIC WinCC flexible ES toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V17 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2024-54678. | ||
| Siemens | N/A | SIMATIC S7-Fail-safe Configuration Tool (S7-FCT) versions antérieures à 4.0.1 | ||
| Siemens | N/A | SIMATIC PCS neo V6.0 toutes versions pour la vulnérabilité CVE-2024-54678 | ||
| Siemens | N/A | SIMATIC eaSie Core Package (6DL5424-0AX00-0AV8) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC MTP CREATOR V2.x et V3.x toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC WinCC OA V3.18 versions antérieures à V3.18 P032 | ||
| Siemens | N/A | TIA Portal Cloud V19 versions antérieures à 5.2.1.1 | ||
| Siemens | N/A | SIMATIC D7-SYS toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC BATCH V10.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ODK 1500S toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2020 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour les vulnérabilités CVE-2025-30033 et CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC S7-1500 Software Controller V2 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | TIA Portal Cloud Connector toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Unified Sequence toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V17 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40759. | ||
| Siemens | N/A | SIMATIC WinCC Runtime Advanced toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Logon V2.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ProSave V19 versions antérieures à V19 Update 4 | ||
| Siemens | N/A | SIMATIC PDM Maintenance Station V5.0 toutes versions pour les vulnérabilités CVE-2025-30033 et CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC Safety Matrix toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Management Console toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SCALANCE XCM-/XRM-/XCH-/XRH-300 family versions antérieures à 3.2 | ||
| Siemens | N/A | SIMATIC BATCH V9.1 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC Process Function Library (PFL) V4.0 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC S7-1500 Software Controller V3 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 CFC V20 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC NET PC Software toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Route Control V9.1 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2022 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC OA V3.20 versions antérieures à V3.20 P008 | ||
| Siemens | N/A | SIMATIC RTLS Locating Manager versions antérieures à 3.3 | ||
| Siemens | N/A | Siprotec 4 7SA6, 7SD5 et 7SD610 versions antérieures à 4.78 | ||
| Siemens | N/A | SIMATIC Automation Tool toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | TIA Portal Cloud V18 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC PDM V9.2 et V9.3 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Runtime Professional toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Visualization Architect (SiVArc) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC eaSie Workflow Skills toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 CFC V19 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC WinCC V19 versions antérieures à V19 Update 4 | ||
| Siemens | N/A | SIMATIC Management Agent toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC V7.5 et V8.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 V5.7 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Automation Tool SDK Windows toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2022 toutes versions pour la vulnérabilité CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V20 versions antérieures à V20 Update 1 | ||
| Siemens | N/A | TIA Portal Cloud V17 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC Energy Suite toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS 7 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Process Historian 2024 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC STEP 7 V19 versions antérieures à V19 Update 4 | ||
| Siemens | N/A | TIA Portal Test Suite V17, v18, v19 et v20 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7-PCT toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Target toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC ProSave V18 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC Logon V1.6 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC STEP 7 V17 et V18 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | SIMATIC RTLS Locating Manager versions antérieures à 3.2 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM Advanced versions antérieures à V7.0 Update 1 | ||
| Siemens | N/A | SIMATIC PCS neo V5.0 toutes versions pour la vulnérabilité CVE-2024-54678 | ||
| Siemens | N/A | SIMATIC STEP 7 V20 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | TIA Portal Cloud V20 toutes versions pour les vulnérabilités CVE-2024-54678 et CVE-2025-40759 | ||
| Siemens | N/A | Siprotec 4 toutes versions et tous modèles exceptés 7SA6, 7SD5, 7SD610 pour la vulnérabilité CVE-2024-52504. | ||
| Siemens | N/A | SIMATIC eaSie PCS 7 Skill Package (6DL5424-0BX00-0AV8) toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 versions antérieures à 3.2 | ||
| Siemens | N/A | SIMATIC S7-PLCSIM V17, V18 et V19 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC Unified PC Runtime V18, V19 et V20 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS 7 Advanced Process Faceplates V9.1 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC S7 F Systems V6.4 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC Information Server toutes versions pour la vulnérabilité CVE-2025-47809 | ||
| Siemens | N/A | SIMATIC S7 F Systems V6.3 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-30033. | ||
| Siemens | N/A | SIMATIC ProSave V20 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS 7 Logic Matrix V9.1 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | WinCC Panel Image Setup toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC PCS neo V4.1 et V5.0 toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2024-54678. | ||
| Siemens | N/A | SIMATIC Route Control V10.0 toutes versions pour la vulnérabilité CVE-2025-30033 | ||
| Siemens | N/A | SIMATIC WinCC V8.1 versions antérieures à V8.1 Update 3 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SIMATIC PCS neo V6.0 versions ant\u00e9rieures \u00e0 V6.0 SP1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V17, v18 et V20 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Control Function Library (CFL) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPROTEC 5 versions ant\u00e9rieures \u00e0 10.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC MTP Integrator toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V17 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Unified Line Coordination toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC TeleControl toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC OA V3.19 versions ant\u00e9rieures \u00e0 V3.19 P020",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC flexible ES toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V17 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-Fail-safe Configuration Tool (S7-FCT) versions ant\u00e9rieures \u00e0 4.0.1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS neo V6.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC eaSie Core Package (6DL5424-0AX00-0AV8) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC MTP CREATOR V2.x et V3.x toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC OA V3.18 versions ant\u00e9rieures \u00e0 V3.18 P032",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V19 versions ant\u00e9rieures \u00e0 5.2.1.1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC D7-SYS toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC BATCH V10.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ODK 1500S toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2020 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour les vuln\u00e9rabilit\u00e9s CVE-2025-30033 et CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 Software Controller V2 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud Connector toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Unified Sequence toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V17 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40759.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Runtime Advanced toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Logon V2.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V19 versions ant\u00e9rieures \u00e0 V19 Update 4",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PDM Maintenance Station V5.0 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2025-30033 et CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Safety Matrix toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Management Console toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XCM-/XRM-/XCH-/XRH-300 family versions ant\u00e9rieures \u00e0 3.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC BATCH V9.1 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Function Library (PFL) V4.0 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 Software Controller V3 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 CFC V20 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC NET PC Software toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Route Control V9.1 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2022 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC OA V3.20 versions ant\u00e9rieures \u00e0 V3.20 P008",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC RTLS Locating Manager versions ant\u00e9rieures \u00e0 3.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Siprotec 4 7SA6, 7SD5 et 7SD610 versions ant\u00e9rieures \u00e0 4.78",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Automation Tool toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V18 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PDM V9.2 et V9.3 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Runtime Professional toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Visualization Architect (SiVArc) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC eaSie Workflow Skills toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 CFC V19 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V19 versions ant\u00e9rieures \u00e0 V19 Update 4",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Management Agent toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V7.5 et V8.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V5.7 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Automation Tool SDK Windows toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2022 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V20 versions ant\u00e9rieures \u00e0 V20 Update 1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V17 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Energy Suite toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS 7 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Process Historian 2024 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V19 versions ant\u00e9rieures \u00e0 V19 Update 4",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Test Suite V17, v18, v19 et v20 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PCT toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Target toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V18 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Logon V1.6 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V17 et V18 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC RTLS Locating Manager versions ant\u00e9rieures \u00e0 3.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM Advanced versions ant\u00e9rieures \u00e0 V7.0 Update 1",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS neo V5.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC STEP 7 V20 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "TIA Portal Cloud V20 toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2024-54678 et CVE-2025-40759",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Siprotec 4 toutes versions et tous mod\u00e8les except\u00e9s 7SA6, 7SD5, 7SD610 pour la vuln\u00e9rabilit\u00e9 CVE-2024-52504. ",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC eaSie PCS 7 Skill Package (6DL5424-0BX00-0AV8) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 versions ant\u00e9rieures \u00e0 3.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-PLCSIM V17, V18 et V19 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC Unified PC Runtime V18, V19 et V20 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS 7 Advanced Process Faceplates V9.1 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 F Systems V6.4 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Information Server toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-47809",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 F Systems V6.3 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ProSave V20 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS 7 Logic Matrix V9.1 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "WinCC Panel Image Setup toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC PCS neo V4.1 et V5.0 toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2024-54678.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Route Control V10.0 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-30033",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V8.1 versions ant\u00e9rieures \u00e0 V8.1 Update 3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
}
],
"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-2023-35827",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35827"
},
{
"name": "CVE-2024-40931",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40931"
},
{
"name": "CVE-2024-56596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56596"
},
{
"name": "CVE-2024-43907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43907"
},
{
"name": "CVE-2024-56645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56645"
},
{
"name": "CVE-2024-56659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56659"
},
{
"name": "CVE-2024-46755",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46755"
},
{
"name": "CVE-2024-47748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47748"
},
{
"name": "CVE-2024-26825",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26825"
},
{
"name": "CVE-2024-49863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49863"
},
{
"name": "CVE-2024-41022",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41022"
},
{
"name": "CVE-2024-49907",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49907"
},
{
"name": "CVE-2024-53061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53061"
},
{
"name": "CVE-2024-53052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53052"
},
{
"name": "CVE-2023-52477",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52477"
},
{
"name": "CVE-2024-53097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53097"
},
{
"name": "CVE-2024-46713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46713"
},
{
"name": "CVE-2023-52622",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52622"
},
{
"name": "CVE-2024-9681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9681"
},
{
"name": "CVE-2024-46844",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46844"
},
{
"name": "CVE-2024-43914",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43914"
},
{
"name": "CVE-2024-26696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26696"
},
{
"name": "CVE-2024-56670",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56670"
},
{
"name": "CVE-2024-41009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41009"
},
{
"name": "CVE-2024-47697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47697"
},
{
"name": "CVE-2024-46815",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46815"
},
{
"name": "CVE-2024-39503",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39503"
},
{
"name": "CVE-2025-40759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40759"
},
{
"name": "CVE-2022-48666",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48666"
},
{
"name": "CVE-2024-49890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49890"
},
{
"name": "CVE-2024-50262",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50262"
},
{
"name": "CVE-2024-40988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40988"
},
{
"name": "CVE-2024-50268",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50268"
},
{
"name": "CVE-2024-49903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49903"
},
{
"name": "CVE-2024-49969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49969"
},
{
"name": "CVE-2023-52804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52804"
},
{
"name": "CVE-2024-41004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41004"
},
{
"name": "CVE-2024-46676",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46676"
},
{
"name": "CVE-2024-41070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41070"
},
{
"name": "CVE-2024-46740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46740"
},
{
"name": "CVE-2023-52845",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52845"
},
{
"name": "CVE-2021-44879",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44879"
},
{
"name": "CVE-2024-46798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46798"
},
{
"name": "CVE-2024-50195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50195"
},
{
"name": "CVE-2024-53172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53172"
},
{
"name": "CVE-2024-46707",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46707"
},
{
"name": "CVE-2024-49967",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49967"
},
{
"name": "CVE-2024-41000",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41000"
},
{
"name": "CVE-2024-36974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36974"
},
{
"name": "CVE-2023-52818",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52818"
},
{
"name": "CVE-2024-56606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56606"
},
{
"name": "CVE-2023-52637",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52637"
},
{
"name": "CVE-2024-46747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46747"
},
{
"name": "CVE-2024-49858",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49858"
},
{
"name": "CVE-2023-52873",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52873"
},
{
"name": "CVE-2024-49948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49948"
},
{
"name": "CVE-2024-56594",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56594"
},
{
"name": "CVE-2024-26754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26754"
},
{
"name": "CVE-2023-52858",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52858"
},
{
"name": "CVE-2024-46738",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46738"
},
{
"name": "CVE-2023-45863",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45863"
},
{
"name": "CVE-2024-56756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56756"
},
{
"name": "CVE-2024-52332",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52332"
},
{
"name": "CVE-2024-46679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46679"
},
{
"name": "CVE-2024-56724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56724"
},
{
"name": "CVE-2024-53194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53194"
},
{
"name": "CVE-2024-49878",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49878"
},
{
"name": "CVE-2023-51782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51782"
},
{
"name": "CVE-2024-46673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46673"
},
{
"name": "CVE-2024-41034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41034"
},
{
"name": "CVE-2024-56723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56723"
},
{
"name": "CVE-2024-53226",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53226"
},
{
"name": "CVE-2024-49884",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49884"
},
{
"name": "CVE-2024-46724",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46724"
},
{
"name": "CVE-2024-56569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56569"
},
{
"name": "CVE-2024-50074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50074"
},
{
"name": "CVE-2024-26790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26790"
},
{
"name": "CVE-2024-46791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46791"
},
{
"name": "CVE-2024-50024",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50024"
},
{
"name": "CVE-2024-47684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47684"
},
{
"name": "CVE-2024-49965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49965"
},
{
"name": "CVE-2024-44969",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44969"
},
{
"name": "CVE-2024-56634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56634"
},
{
"name": "CVE-2024-43098",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43098"
},
{
"name": "CVE-2024-42236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42236"
},
{
"name": "CVE-2024-56548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56548"
},
{
"name": "CVE-2024-39469",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39469"
},
{
"name": "CVE-2024-39509",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39509"
},
{
"name": "CVE-2024-50202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50202"
},
{
"name": "CVE-2023-5178",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5178"
},
{
"name": "CVE-2024-26845",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26845"
},
{
"name": "CVE-2024-26704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26704"
},
{
"name": "CVE-2024-26671",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26671"
},
{
"name": "CVE-2024-46800",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46800"
},
{
"name": "CVE-2023-52810",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52810"
},
{
"name": "CVE-2024-46750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46750"
},
{
"name": "CVE-2024-39484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39484"
},
{
"name": "CVE-2024-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53181"
},
{
"name": "CVE-2024-46722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46722"
},
{
"name": "CVE-2024-26600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26600"
},
{
"name": "CVE-2024-47701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47701"
},
{
"name": "CVE-2024-40971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40971"
},
{
"name": "CVE-2023-52847",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52847"
},
{
"name": "CVE-2024-39505",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39505"
},
{
"name": "CVE-2023-52864",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52864"
},
{
"name": "CVE-2024-0646",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0646"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2024-47713",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47713"
},
{
"name": "CVE-2024-49936",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49936"
},
{
"name": "CVE-2024-50267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50267"
},
{
"name": "CVE-2024-56637",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56637"
},
{
"name": "CVE-2024-47663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47663"
},
{
"name": "CVE-2024-40932",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40932"
},
{
"name": "CVE-2024-49881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49881"
},
{
"name": "CVE-2023-52478",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52478"
},
{
"name": "CVE-2024-41006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41006"
},
{
"name": "CVE-2023-46343",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46343"
},
{
"name": "CVE-2024-46745",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46745"
},
{
"name": "CVE-2024-46819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46819"
},
{
"name": "CVE-2024-49896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49896"
},
{
"name": "CVE-2024-40904",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40904"
},
{
"name": "CVE-2024-42084",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42084"
},
{
"name": "CVE-2024-49959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49959"
},
{
"name": "CVE-2024-49913",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49913"
},
{
"name": "CVE-2024-56691",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56691"
},
{
"name": "CVE-2024-46721",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46721"
},
{
"name": "CVE-2024-50045",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50045"
},
{
"name": "CVE-2024-26805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26805"
},
{
"name": "CVE-2024-42153",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42153"
},
{
"name": "CVE-2024-46822",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46822"
},
{
"name": "CVE-2024-40960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40960"
},
{
"name": "CVE-2024-49995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49995"
},
{
"name": "CVE-2024-56643",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56643"
},
{
"name": "CVE-2025-40570",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40570"
},
{
"name": "CVE-2024-56661",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56661"
},
{
"name": "CVE-2024-49977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49977"
},
{
"name": "CVE-2024-42154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42154"
},
{
"name": "CVE-2024-49900",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49900"
},
{
"name": "CVE-2024-46685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46685"
},
{
"name": "CVE-2024-47679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47679"
},
{
"name": "CVE-2024-36484",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36484"
},
{
"name": "CVE-2024-43889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43889"
},
{
"name": "CVE-2024-44998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44998"
},
{
"name": "CVE-2024-46723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46723"
},
{
"name": "CVE-2024-42229",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42229"
},
{
"name": "CVE-2024-26839",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26839"
},
{
"name": "CVE-2024-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46828"
},
{
"name": "CVE-2024-50269",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50269"
},
{
"name": "CVE-2024-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53150"
},
{
"name": "CVE-2024-47735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47735"
},
{
"name": "CVE-2024-49952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49952"
},
{
"name": "CVE-2024-49981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49981"
},
{
"name": "CVE-2024-56595",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56595"
},
{
"name": "CVE-2024-42086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42086"
},
{
"name": "CVE-2024-26581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26581"
},
{
"name": "CVE-2022-48935",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48935"
},
{
"name": "CVE-2023-52433",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52433"
},
{
"name": "CVE-2024-41007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41007"
},
{
"name": "CVE-2024-41095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41095"
},
{
"name": "CVE-2024-56601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56601"
},
{
"name": "CVE-2023-52600",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52600"
},
{
"name": "CVE-2024-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53057"
},
{
"name": "CVE-2024-26910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26910"
},
{
"name": "CVE-2024-50181",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50181"
},
{
"name": "CVE-2023-52507",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52507"
},
{
"name": "CVE-2024-56571",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56571"
},
{
"name": "CVE-2023-52764",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52764"
},
{
"name": "CVE-2023-52587",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52587"
},
{
"name": "CVE-2023-52887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52887"
},
{
"name": "CVE-2024-46675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46675"
},
{
"name": "CVE-2024-26645",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26645"
},
{
"name": "CVE-2024-26702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26702"
},
{
"name": "CVE-2024-46783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46783"
},
{
"name": "CVE-2023-51779",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51779"
},
{
"name": "CVE-2024-42076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42076"
},
{
"name": "CVE-2024-26673",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26673"
},
{
"name": "CVE-2024-49997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49997"
},
{
"name": "CVE-2024-42092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42092"
},
{
"name": "CVE-2024-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26720"
},
{
"name": "CVE-2024-0584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0584"
},
{
"name": "CVE-2024-42093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42093"
},
{
"name": "CVE-2024-42247",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42247"
},
{
"name": "CVE-2024-43871",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43871"
},
{
"name": "CVE-2024-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53066"
},
{
"name": "CVE-2023-52784",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52784"
},
{
"name": "CVE-2024-43880",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43880"
},
{
"name": "CVE-2024-27413",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27413"
},
{
"name": "CVE-2024-56629",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56629"
},
{
"name": "CVE-2024-50304",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50304"
},
{
"name": "CVE-2024-40959",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40959"
},
{
"name": "CVE-2024-26615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26615"
},
{
"name": "CVE-2023-52853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52853"
},
{
"name": "CVE-2024-46689",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46689"
},
{
"name": "CVE-2024-50295",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50295"
},
{
"name": "CVE-2024-26801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26801"
},
{
"name": "CVE-2024-50051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50051"
},
{
"name": "CVE-2024-41078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41078"
},
{
"name": "CVE-2024-53063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53063"
},
{
"name": "CVE-2024-53171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53171"
},
{
"name": "CVE-2024-56602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56602"
},
{
"name": "CVE-2024-46781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46781"
},
{
"name": "CVE-2024-56770",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56770"
},
{
"name": "CVE-2024-53157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53157"
},
{
"name": "CVE-2025-30034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30034"
},
{
"name": "CVE-2024-46777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46777"
},
{
"name": "CVE-2023-52340",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52340"
},
{
"name": "CVE-2024-50199",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50199"
},
{
"name": "CVE-2024-26779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26779"
},
{
"name": "CVE-2024-40916",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40916"
},
{
"name": "CVE-2024-0193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0193"
},
{
"name": "CVE-2023-52604",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52604"
},
{
"name": "CVE-2024-50040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50040"
},
{
"name": "CVE-2024-38586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38586"
},
{
"name": "CVE-2024-56739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56739"
},
{
"name": "CVE-2024-50292",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50292"
},
{
"name": "CVE-2024-53103",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53103"
},
{
"name": "CVE-2024-46714",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46714"
},
{
"name": "CVE-2024-40976",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40976"
},
{
"name": "CVE-2024-41081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41081"
},
{
"name": "CVE-2025-40746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40746"
},
{
"name": "CVE-2024-49983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49983"
},
{
"name": "CVE-2023-52601",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52601"
},
{
"name": "CVE-2024-41072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41072"
},
{
"name": "CVE-2024-44960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44960"
},
{
"name": "CVE-2024-26773",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26773"
},
{
"name": "CVE-2024-26722",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26722"
},
{
"name": "CVE-2024-54678",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54678"
},
{
"name": "CVE-2024-26598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26598"
},
{
"name": "CVE-2024-53197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53197"
},
{
"name": "CVE-2024-26679",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26679"
},
{
"name": "CVE-2024-39468",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39468"
},
{
"name": "CVE-2024-26763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26763"
},
{
"name": "CVE-2024-49889",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49889"
},
{
"name": "CVE-2023-52435",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52435"
},
{
"name": "CVE-2024-40980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40980"
},
{
"name": "CVE-2023-52654",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52654"
},
{
"name": "CVE-2024-36938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36938"
},
{
"name": "CVE-2024-40974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40974"
},
{
"name": "CVE-2023-52855",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52855"
},
{
"name": "CVE-2024-56779",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56779"
},
{
"name": "CVE-2024-26749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26749"
},
{
"name": "CVE-2024-44971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44971"
},
{
"name": "CVE-2023-52603",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52603"
},
{
"name": "CVE-2024-43894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43894"
},
{
"name": "CVE-2023-52486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52486"
},
{
"name": "CVE-2024-43867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43867"
},
{
"name": "CVE-2023-52868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52868"
},
{
"name": "CVE-2023-52619",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52619"
},
{
"name": "CVE-2023-52796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52796"
},
{
"name": "CVE-2023-52475",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52475"
},
{
"name": "CVE-2024-50013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50013"
},
{
"name": "CVE-2024-50185",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50185"
},
{
"name": "CVE-2024-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53239"
},
{
"name": "CVE-2023-52617",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52617"
},
{
"name": "CVE-2024-49957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49957"
},
{
"name": "CVE-2024-49962",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49962"
},
{
"name": "CVE-2024-46731",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46731"
},
{
"name": "CVE-2024-39502",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39502"
},
{
"name": "CVE-2024-46674",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46674"
},
{
"name": "CVE-2023-52836",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52836"
},
{
"name": "CVE-2024-26804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26804"
},
{
"name": "CVE-2024-26593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26593"
},
{
"name": "CVE-2024-26751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26751"
},
{
"name": "CVE-2024-49958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49958"
},
{
"name": "CVE-2024-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50082"
},
{
"name": "CVE-2024-47723",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47723"
},
{
"name": "CVE-2024-49955",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49955"
},
{
"name": "CVE-2024-42087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42087"
},
{
"name": "CVE-2024-44944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44944"
},
{
"name": "CVE-2024-43893",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43893"
},
{
"name": "CVE-2024-50095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50095"
},
{
"name": "CVE-2024-40983",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40983"
},
{
"name": "CVE-2024-50296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50296"
},
{
"name": "CVE-2024-57874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57874"
},
{
"name": "CVE-2024-53145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53145"
},
{
"name": "CVE-2024-50006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50006"
},
{
"name": "CVE-2022-49034",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49034"
},
{
"name": "CVE-2024-50049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50049"
},
{
"name": "CVE-2024-27412",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27412"
},
{
"name": "CVE-2024-26636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26636"
},
{
"name": "CVE-2024-56642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56642"
},
{
"name": "CVE-2024-50007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50007"
},
{
"name": "CVE-2024-56586",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56586"
},
{
"name": "CVE-2023-39198",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39198"
},
{
"name": "CVE-2024-40963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40963"
},
{
"name": "CVE-2025-40752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40752"
},
{
"name": "CVE-2024-41041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41041"
},
{
"name": "CVE-2024-50096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50096"
},
{
"name": "CVE-2023-52789",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52789"
},
{
"name": "CVE-2024-49868",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49868"
},
{
"name": "CVE-2024-40947",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40947"
},
{
"name": "CVE-2024-53173",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53173"
},
{
"name": "CVE-2024-50237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50237"
},
{
"name": "CVE-2023-52867",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52867"
},
{
"name": "CVE-2024-44995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44995"
},
{
"name": "CVE-2024-46757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46757"
},
{
"name": "CVE-2024-42232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42232"
},
{
"name": "CVE-2024-47699",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47699"
},
{
"name": "CVE-2024-56581",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56581"
},
{
"name": "CVE-2024-46677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46677"
},
{
"name": "CVE-2024-50059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50059"
},
{
"name": "CVE-2024-50264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50264"
},
{
"name": "CVE-2024-26606",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26606"
},
{
"name": "CVE-2024-35833",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35833"
},
{
"name": "CVE-2024-41005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41005"
},
{
"name": "CVE-2024-43883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43883"
},
{
"name": "CVE-2024-56623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56623"
},
{
"name": "CVE-2024-26625",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26625"
},
{
"name": "CVE-2024-44935",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44935"
},
{
"name": "CVE-2024-44999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44999"
},
{
"name": "CVE-2024-47712",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47712"
},
{
"name": "CVE-2024-56610",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56610"
},
{
"name": "CVE-2024-26748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26748"
},
{
"name": "CVE-2023-52809",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52809"
},
{
"name": "CVE-2024-42223",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42223"
},
{
"name": "CVE-2024-49963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49963"
},
{
"name": "CVE-2024-49971",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49971"
},
{
"name": "CVE-2024-56562",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56562"
},
{
"name": "CVE-2024-26635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26635"
},
{
"name": "CVE-2023-52805",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52805"
},
{
"name": "CVE-2024-41097",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41097"
},
{
"name": "CVE-2024-49875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49875"
},
{
"name": "CVE-2024-47739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47739"
},
{
"name": "CVE-2024-47705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47705"
},
{
"name": "CVE-2024-53161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
},
{
"name": "CVE-2023-52919",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52919"
},
{
"name": "CVE-2024-50035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50035"
},
{
"name": "CVE-2024-56600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56600"
},
{
"name": "CVE-2024-36978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36978"
},
{
"name": "CVE-2024-44988",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44988"
},
{
"name": "CVE-2024-47660",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47660"
},
{
"name": "CVE-2024-56690",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56690"
},
{
"name": "CVE-2024-56597",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56597"
},
{
"name": "CVE-2024-40905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40905"
},
{
"name": "CVE-2024-56574",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56574"
},
{
"name": "CVE-2024-47740",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47740"
},
{
"name": "CVE-2024-41063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41063"
},
{
"name": "CVE-2024-41017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41017"
},
{
"name": "CVE-2024-26697",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26697"
},
{
"name": "CVE-2024-42244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42244"
},
{
"name": "CVE-2024-49924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49924"
},
{
"name": "CVE-2024-46758",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46758"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2024-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53183"
},
{
"name": "CVE-2024-49938",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49938"
},
{
"name": "CVE-2024-41012",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41012"
},
{
"name": "CVE-2024-40902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40902"
},
{
"name": "CVE-2024-47756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47756"
},
{
"name": "CVE-2024-40934",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40934"
},
{
"name": "CVE-2024-47667",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47667"
},
{
"name": "CVE-2024-46756",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46756"
},
{
"name": "CVE-2024-56615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56615"
},
{
"name": "CVE-2024-47737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47737"
},
{
"name": "CVE-2024-46739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46739"
},
{
"name": "CVE-2024-47669",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47669"
},
{
"name": "CVE-2024-56705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56705"
},
{
"name": "CVE-2024-50290",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50290"
},
{
"name": "CVE-2024-50008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50008"
},
{
"name": "CVE-2024-42082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42082"
},
{
"name": "CVE-2024-26685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26685"
},
{
"name": "CVE-2024-56704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56704"
},
{
"name": "CVE-2024-45006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45006"
},
{
"name": "CVE-2024-46725",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46725"
},
{
"name": "CVE-2024-46829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46829"
},
{
"name": "CVE-2024-40912",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40912"
},
{
"name": "CVE-2023-52599",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52599"
},
{
"name": "CVE-2024-56589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56589"
},
{
"name": "CVE-2024-50265",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50265"
},
{
"name": "CVE-2024-56636",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56636"
},
{
"name": "CVE-2024-41089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41089"
},
{
"name": "CVE-2024-39487",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39487"
},
{
"name": "CVE-2024-56567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56567"
},
{
"name": "CVE-2024-44954",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44954"
},
{
"name": "CVE-2024-43908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43908"
},
{
"name": "CVE-2023-3567",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3567"
},
{
"name": "CVE-2024-50033",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50033"
},
{
"name": "CVE-2024-43890",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43890"
},
{
"name": "CVE-2024-26688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26688"
},
{
"name": "CVE-2023-52865",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52865"
},
{
"name": "CVE-2024-49901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49901"
},
{
"name": "CVE-2024-36901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36901"
},
{
"name": "CVE-2024-56688",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56688"
},
{
"name": "CVE-2024-41090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41090"
},
{
"name": "CVE-2024-50180",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50180"
},
{
"name": "CVE-2024-26663",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26663"
},
{
"name": "CVE-2024-50282",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50282"
},
{
"name": "CVE-2024-50273",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50273"
},
{
"name": "CVE-2024-26675",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26675"
},
{
"name": "CVE-2024-56532",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56532"
},
{
"name": "CVE-2024-41077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41077"
},
{
"name": "CVE-2024-47143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47143"
},
{
"name": "CVE-2024-49949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49949"
},
{
"name": "CVE-2023-52509",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52509"
},
{
"name": "CVE-2024-44952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44952"
},
{
"name": "CVE-2023-52753",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52753"
},
{
"name": "CVE-2024-26840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26840"
},
{
"name": "CVE-2024-50046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50046"
},
{
"name": "CVE-2023-52583",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52583"
},
{
"name": "CVE-2024-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50099"
},
{
"name": "CVE-2024-50193",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50193"
},
{
"name": "CVE-2024-46743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46743"
},
{
"name": "CVE-2024-49944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49944"
},
{
"name": "CVE-2023-52602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52602"
},
{
"name": "CVE-2024-50198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50198"
},
{
"name": "CVE-2023-52832",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52832"
},
{
"name": "CVE-2024-56746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56746"
},
{
"name": "CVE-2024-47749",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47749"
},
{
"name": "CVE-2024-41092",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41092"
},
{
"name": "CVE-2024-49966",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49966"
},
{
"name": "CVE-2024-40995",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40995"
},
{
"name": "CVE-2024-41087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41087"
},
{
"name": "CVE-2023-52819",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52819"
},
{
"name": "CVE-2023-52876",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52876"
},
{
"name": "CVE-2024-42095",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42095"
},
{
"name": "CVE-2024-49902",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49902"
},
{
"name": "CVE-2024-47757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47757"
},
{
"name": "CVE-2025-30033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30033"
},
{
"name": "CVE-2024-27417",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27417"
},
{
"name": "CVE-2024-48881",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48881"
},
{
"name": "CVE-2024-47692",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47692"
},
{
"name": "CVE-2024-46744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46744"
},
{
"name": "CVE-2024-0841",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0841"
},
{
"name": "CVE-2025-40753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40753"
},
{
"name": "CVE-2024-50184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50184"
},
{
"name": "CVE-2024-40929",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40929"
},
{
"name": "CVE-2024-39501",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39501"
},
{
"name": "CVE-2024-52504",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52504"
},
{
"name": "CVE-2024-50287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50287"
},
{
"name": "CVE-2024-56747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56747"
},
{
"name": "CVE-2024-49851",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49851"
},
{
"name": "CVE-2023-6040",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6040"
},
{
"name": "CVE-2023-52510",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52510"
},
{
"name": "CVE-2023-51781",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51781"
},
{
"name": "CVE-2024-56603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56603"
},
{
"name": "CVE-2024-53158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53158"
},
{
"name": "CVE-2024-43882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43882"
},
{
"name": "CVE-2024-41068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41068"
},
{
"name": "CVE-2024-56644",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56644"
},
{
"name": "CVE-2024-46780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46780"
},
{
"name": "CVE-2024-46817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46817"
},
{
"name": "CVE-2024-42101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42101"
},
{
"name": "CVE-2025-40751",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40751"
},
{
"name": "CVE-2024-50278",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50278"
},
{
"name": "CVE-2024-50201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50201"
},
{
"name": "CVE-2024-35835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35835"
},
{
"name": "CVE-2024-56701",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56701"
},
{
"name": "CVE-2024-42077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42077"
},
{
"name": "CVE-2023-52670",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52670"
},
{
"name": "CVE-2024-40943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40943"
},
{
"name": "CVE-2024-26735",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26735"
},
{
"name": "CVE-2024-49933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49933"
},
{
"name": "CVE-2024-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53184"
},
{
"name": "CVE-2024-47685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47685"
},
{
"name": "CVE-2024-40901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40901"
},
{
"name": "CVE-2022-48829",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48829"
},
{
"name": "CVE-2024-53174",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53174"
},
{
"name": "CVE-2024-49879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49879"
},
{
"name": "CVE-2024-39495",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39495"
},
{
"name": "CVE-2024-50044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50044"
},
{
"name": "CVE-2024-49894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49894"
},
{
"name": "CVE-2024-56700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56700"
},
{
"name": "CVE-2024-47718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47718"
},
{
"name": "CVE-2024-49867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49867"
},
{
"name": "CVE-2023-51780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51780"
},
{
"name": "CVE-2024-49985",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49985"
},
{
"name": "CVE-2024-50001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50001"
},
{
"name": "CVE-2023-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52881"
},
{
"name": "CVE-2024-49993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49993"
},
{
"name": "CVE-2024-56728",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56728"
},
{
"name": "CVE-2024-43861",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43861"
},
{
"name": "CVE-2024-53241",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53241"
},
{
"name": "CVE-2023-52838",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52838"
},
{
"name": "CVE-2024-47710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47710"
},
{
"name": "CVE-2024-46771",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46771"
},
{
"name": "CVE-2024-50083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50083"
},
{
"name": "CVE-2023-52774",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52774"
},
{
"name": "CVE-2024-56531",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56531"
},
{
"name": "CVE-2024-49892",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49892"
},
{
"name": "CVE-2024-49930",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49930"
},
{
"name": "CVE-2024-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53148"
},
{
"name": "CVE-2024-47698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47698"
},
{
"name": "CVE-2023-52879",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52879"
},
{
"name": "CVE-2024-56681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56681"
},
{
"name": "CVE-2024-26602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26602"
},
{
"name": "CVE-2023-52799",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52799"
},
{
"name": "CVE-2024-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38619"
},
{
"name": "CVE-2024-50039",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50039"
},
{
"name": "CVE-2024-50251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50251"
},
{
"name": "CVE-2024-56754",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56754"
},
{
"name": "CVE-2024-49973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49973"
},
{
"name": "CVE-2024-53214",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53214"
},
{
"name": "CVE-2024-39476",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39476"
},
{
"name": "CVE-2024-46804",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46804"
},
{
"name": "CVE-2024-56619",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56619"
},
{
"name": "CVE-2024-47668",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47668"
},
{
"name": "CVE-2024-49883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49883"
},
{
"name": "CVE-2024-53165",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53165"
},
{
"name": "CVE-2024-50236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50236"
},
{
"name": "CVE-2024-46840",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46840"
},
{
"name": "CVE-2022-48828",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48828"
},
{
"name": "CVE-2024-56568",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56568"
},
{
"name": "CVE-2024-46763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46763"
},
{
"name": "CVE-2024-41059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41059"
},
{
"name": "CVE-2024-42094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42094"
},
{
"name": "CVE-2024-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53146"
},
{
"name": "CVE-2024-46759",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46759"
},
{
"name": "CVE-2024-27416",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27416"
},
{
"name": "CVE-2023-52598",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52598"
},
{
"name": "CVE-2024-46737",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46737"
},
{
"name": "CVE-2024-41040",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41040"
},
{
"name": "CVE-2023-6606",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6606"
},
{
"name": "CVE-2024-40987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40987"
},
{
"name": "CVE-2024-56539",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56539"
},
{
"name": "CVE-2023-52806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52806"
},
{
"name": "CVE-2024-56662",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56662"
},
{
"name": "CVE-2024-46814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46814"
},
{
"name": "CVE-2024-56572",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56572"
},
{
"name": "CVE-2024-56570",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56570"
},
{
"name": "CVE-2024-26793",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26793"
},
{
"name": "CVE-2024-40945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40945"
},
{
"name": "CVE-2024-46818",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46818"
},
{
"name": "CVE-2023-6932",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6932"
},
{
"name": "CVE-2024-50602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50602"
},
{
"name": "CVE-2024-40941",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40941"
},
{
"name": "CVE-2022-48827",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48827"
},
{
"name": "CVE-2023-52594",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52594"
},
{
"name": "CVE-2024-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53198"
},
{
"name": "CVE-2024-44965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44965"
},
{
"name": "CVE-2024-49860",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49860"
},
{
"name": "CVE-2024-45003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45003"
},
{
"name": "CVE-2024-41055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41055"
},
{
"name": "CVE-2023-52595",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52595"
},
{
"name": "CVE-2025-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47809"
},
{
"name": "CVE-2024-50234",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50234"
},
{
"name": "CVE-2024-56720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56720"
},
{
"name": "CVE-2024-26752",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26752"
},
{
"name": "CVE-2024-41015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41015"
},
{
"name": "CVE-2024-53155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53155"
},
{
"name": "CVE-2024-40984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40984"
},
{
"name": "CVE-2024-42224",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42224"
},
{
"name": "CVE-2024-50194",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50194"
},
{
"name": "CVE-2024-46832",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46832"
},
{
"name": "CVE-2023-52871",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52871"
},
{
"name": "CVE-2024-49895",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49895"
},
{
"name": "CVE-2024-56785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56785"
},
{
"name": "CVE-2023-52623",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52623"
},
{
"name": "CVE-2024-26736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26736"
},
{
"name": "CVE-2024-56587",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56587"
},
{
"name": "CVE-2024-45021",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45021"
},
{
"name": "CVE-2023-52655",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52655"
},
{
"name": "CVE-2024-49882",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49882"
},
{
"name": "CVE-2024-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47659"
},
{
"name": "CVE-2024-42161",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42161"
},
{
"name": "CVE-2023-52813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52813"
},
{
"name": "CVE-2024-56741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56741"
},
{
"name": "CVE-2023-52504",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52504"
},
{
"name": "CVE-2024-39506",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39506"
},
{
"name": "CVE-2024-40990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40990"
},
{
"name": "CVE-2024-40978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40978"
},
{
"name": "CVE-2024-53104",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53104"
},
{
"name": "CVE-2023-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52615"
},
{
"name": "CVE-2024-40968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40968"
},
{
"name": "CVE-2024-45025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45025"
},
{
"name": "CVE-2024-27414",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27414"
},
{
"name": "CVE-2024-56748",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56748"
},
{
"name": "CVE-2024-41035",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41035"
},
{
"name": "CVE-2024-56648",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56648"
},
{
"name": "CVE-2024-26777",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26777"
},
{
"name": "CVE-2024-41049",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41049"
},
{
"name": "CVE-2024-26764",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26764"
},
{
"name": "CVE-2024-42143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42143"
},
{
"name": "CVE-2021-47316",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47316"
},
{
"name": "CVE-2024-56558",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56558"
},
{
"name": "CVE-2024-41065",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41065"
},
{
"name": "CVE-2024-43879",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43879"
},
{
"name": "CVE-2024-46761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46761"
},
{
"name": "CVE-2023-52606",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52606"
},
{
"name": "CVE-2024-50301",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50301"
},
{
"name": "CVE-2024-26778",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26778"
},
{
"name": "CVE-2024-37078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37078"
},
{
"name": "CVE-2024-49975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49975"
},
{
"name": "CVE-2024-53240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53240"
},
{
"name": "CVE-2024-50179",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50179"
},
{
"name": "CVE-2024-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53101"
},
{
"name": "CVE-2024-47696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47696"
},
{
"name": "CVE-2023-52840",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52840"
},
{
"name": "CVE-2024-53156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53156"
},
{
"name": "CVE-2023-52502",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52502"
},
{
"name": "CVE-2024-41091",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41091"
},
{
"name": "CVE-2024-42105",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42105"
},
{
"name": "CVE-2024-50015",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50015"
},
{
"name": "CVE-2023-52597",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52597"
},
{
"name": "CVE-2024-41044",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41044"
},
{
"name": "CVE-2024-40958",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40958"
},
{
"name": "CVE-2023-52581",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52581"
},
{
"name": "CVE-2024-45008",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45008"
},
{
"name": "CVE-2024-50188",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50188"
},
{
"name": "CVE-2024-56533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56533"
},
{
"name": "CVE-2024-40981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40981"
},
{
"name": "CVE-2023-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52917"
},
{
"name": "CVE-2024-56598",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56598"
},
{
"name": "CVE-2024-1086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1086"
},
{
"name": "CVE-2024-53060",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53060"
},
{
"name": "CVE-2023-52875",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52875"
},
{
"name": "CVE-2024-44990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44990"
},
{
"name": "CVE-2024-44987",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44987"
},
{
"name": "CVE-2024-56781",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56781"
},
{
"name": "CVE-2024-41046",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41046"
},
{
"name": "CVE-2024-50089",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50089"
},
{
"name": "CVE-2024-56630",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56630"
},
{
"name": "CVE-2024-42152",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42152"
},
{
"name": "CVE-2024-49982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49982"
},
{
"name": "CVE-2023-52835",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52835"
},
{
"name": "CVE-2024-53059",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53059"
},
{
"name": "CVE-2024-50299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50299"
},
{
"name": "CVE-2024-50218",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50218"
},
{
"name": "CVE-2024-42148",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42148"
},
{
"name": "CVE-2024-39482",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39482"
},
{
"name": "CVE-2024-39499",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39499"
},
{
"name": "CVE-2024-56633",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56633"
},
{
"name": "CVE-2024-56593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56593"
},
{
"name": "CVE-2024-56605",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56605"
},
{
"name": "CVE-2024-53680",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53680"
},
{
"name": "CVE-2024-26835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26835"
},
{
"name": "CVE-2024-26791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26791"
},
{
"name": "CVE-2023-52843",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52843"
},
{
"name": "CVE-2024-50279",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50279"
},
{
"name": "CVE-2024-41064",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41064"
},
{
"name": "CVE-2024-36894",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36894"
},
{
"name": "CVE-2024-56698",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56698"
},
{
"name": "CVE-2024-47742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47742"
},
{
"name": "CVE-2024-47709",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47709"
},
{
"name": "CVE-2024-41020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41020"
},
{
"name": "CVE-2024-26772",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26772"
},
{
"name": "CVE-2024-46782",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46782"
},
{
"name": "CVE-2024-56780",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56780"
},
{
"name": "CVE-2024-47706",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47706"
},
{
"name": "CVE-2024-27405",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27405"
},
{
"name": "CVE-2024-46702",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46702"
},
{
"name": "CVE-2023-5717",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5717"
},
{
"name": "CVE-2024-47747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47747"
},
{
"name": "CVE-2024-40942",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40942"
},
{
"name": "CVE-2024-26766",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26766"
},
{
"name": "CVE-2023-5678",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5678"
},
{
"name": "CVE-2024-26664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26664"
},
{
"name": "CVE-2024-46719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46719"
},
{
"name": "CVE-2024-49877",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49877"
},
{
"name": "CVE-2023-52791",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52791"
},
{
"name": "CVE-2024-44949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44949"
},
{
"name": "CVE-2023-6121",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6121"
},
{
"name": "CVE-2023-52607",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52607"
},
{
"name": "CVE-2024-56650",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56650"
},
{
"name": "CVE-2024-44989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44989"
},
{
"name": "CVE-2024-26788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26788"
},
{
"name": "CVE-2023-52817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52817"
},
{
"name": "CVE-2024-27410",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27410"
},
{
"name": "CVE-2024-26684",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26684"
},
{
"name": "CVE-2024-53237",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53237"
},
{
"name": "CVE-2023-6931",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6931"
},
{
"name": "CVE-2024-56576",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56576"
},
{
"name": "CVE-2024-42145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42145"
},
{
"name": "CVE-2024-40961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40961"
},
{
"name": "CVE-2024-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53227"
}
],
"links": [],
"reference": "CERTFR-2025-AVI-0677",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-08-12T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"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": "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 les produits Siemens. 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 un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits Siemens",
"vendor_advisories": [
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-707630",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-707630.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-331739",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-331739.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-693808",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-693808.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-613116",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-613116.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-493396",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-493396.html"
},
{
"published_at": "2025-08-11",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens ssa-400089",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-400089.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-493787",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-493787.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-894058",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-894058.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-355557",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-355557.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-529291",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-529291.html"
},
{
"published_at": "2025-08-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-282044",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-282044.html"
}
]
}
FKIE_CVE-2024-53198
Vulnerability from fkie_nvd - Published: 2024-12-27 14:15 - Updated: 2026-08-04 11:225.5 (Medium) - CVSS:3.1/
5.5 (Medium) - CVSS:3.1/
| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/3fc0996d2fefe61219375fd650601724b8cf2d30 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/804b96f8d0a02fa10b92f28b2e042f9128ed3ffc | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/afc545da381ba0c651b2658966ac737032676f01 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/e8823e6ff313465910edea07581627d85e68d9fd | Patch | |
| 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/03/msg00002.html |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/xen/xenbus/xenbus_probe.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "87106169b4ce26f85561f953d13d1fd86d99b612",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "0aa9e30b5b4af5dd504801689d6d84c584290a45",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "e8823e6ff313465910edea07581627d85e68d9fd",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "3fc0996d2fefe61219375fd650601724b8cf2d30",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "804b96f8d0a02fa10b92f28b2e042f9128ed3ffc",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "217bdce88b104269b73603b84d0ab4dd04f481bc",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
},
{
"lessThan": "afc545da381ba0c651b2658966ac737032676f01",
"status": "affected",
"version": "4bac07c993d03434ea902d3d4290d9e45944b66c",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/xen/xenbus/xenbus_probe.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.23"
},
{
"lessThan": "2.6.23",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.287",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.231",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.174",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.120",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.64",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.11.*",
"status": "unaffected",
"version": "6.11.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.2",
"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": "8C6A7B3A-AE77-4337-BC43-53984FDD12C4",
"versionEndExcluding": "5.4.287",
"versionStartIncluding": "2.6.23",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B5C644CC-2BD7-4E32-BC54-8DCC7ABE9935",
"versionEndExcluding": "5.10.231",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "419FD073-1517-4FD5-8158-F94BC68A1E89",
"versionEndExcluding": "5.15.174",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "09AC6122-E2A4-40FE-9D33-268A1B2EC265",
"versionEndExcluding": "6.1.120",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "CA16DEE3-ABEC-4449-9F4A-7A3DC4FC36C7",
"versionEndExcluding": "6.6.64",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "21434379-192D-472F-9B54-D45E3650E893",
"versionEndExcluding": "6.11.11",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D8882B1B-2ABC-4838-AC1D-DBDBB5764776",
"versionEndExcluding": "6.12.2",
"versionStartIncluding": "6.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u003eprobe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen: soluciona el problema de que los recursos no se liberan correctamente en xenbus_dev_probe() Este parche soluciona un problema en la funci\u00f3n xenbus_dev_probe(). En la funci\u00f3n xenbus_dev_probe(), dentro de la rama if (err) en la l\u00ednea 313, el programa devuelve incorrectamente err directamente sin liberar los recursos asignados por err = drv-\u0026gt;probe(dev, id). Como el valor de retorno no es cero, las capas superiores suponen que la l\u00f3gica de procesamiento ha fallado. Sin embargo, la operaci\u00f3n de sondeo se realiz\u00f3 antes sin una operaci\u00f3n de eliminaci\u00f3n correspondiente. Dado que el sondeo realmente asigna recursos, no realizar la operaci\u00f3n de eliminaci\u00f3n podr\u00eda provocar problemas. Para solucionar este problema, seguimos la l\u00f3gica de liberaci\u00f3n de recursos de la funci\u00f3n xenbus_dev_remove() agregando un nuevo bloque fail_remove antes del bloque fail_put. Despu\u00e9s de ingresar a la rama if (err) en la l\u00ednea 313, la funci\u00f3n usar\u00e1 una declaraci\u00f3n goto para saltar al bloque fail_remove, lo que garantiza que los recursos adquiridos previamente se liberen correctamente, evitando as\u00ed la fuga del recuento de referencias. Este error fue identificado por una herramienta de an\u00e1lisis est\u00e1tico experimental desarrollada por nuestro equipo. La herramienta se especializa en analizar operaciones de recuento de referencias y detectar posibles problemas en los que los recursos no se administran correctamente. En este caso, la herramienta marc\u00f3 la operaci\u00f3n de liberaci\u00f3n faltante como un problema potencial, lo que llev\u00f3 al desarrollo de este parche."
}
],
"id": "CVE-2024-53198",
"lastModified": "2026-08-04T11:22:04.490",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"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"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-53198",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T20:04:00.609421Z",
"version": "2.0.3"
}
}
]
},
"published": "2024-12-27T14:15:27.497",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3fc0996d2fefe61219375fd650601724b8cf2d30"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/804b96f8d0a02fa10b92f28b2e042f9128ed3ffc"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/afc545da381ba0c651b2658966ac737032676f01"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e8823e6ff313465910edea07581627d85e68d9fd"
},
{
"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/03/msg00002.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-401"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-401"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-HQF9-CPXC-Q47R
Vulnerability from github – Published: 2024-12-27 15:31 – Updated: 2025-11-03 21:31In the Linux kernel, the following vulnerability has been resolved:
xen: Fix the issue of resource not being properly released in xenbus_dev_probe()
This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems.
To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak.
This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.
{
"affected": [],
"aliases": [
"CVE-2024-53198"
],
"database_specific": {
"cwe_ids": [
"CWE-401"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-27T14:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u003eprobe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch.",
"id": "GHSA-hqf9-cpxc-q47r",
"modified": "2025-11-03T21:31:48Z",
"published": "2024-12-27T15:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53198"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0aa9e30b5b4af5dd504801689d6d84c584290a45"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/217bdce88b104269b73603b84d0ab4dd04f481bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2f977a4c82d35d063f5fe198bbc501c4b1c5ea0e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3fc0996d2fefe61219375fd650601724b8cf2d30"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/804b96f8d0a02fa10b92f28b2e042f9128ed3ffc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/87106169b4ce26f85561f953d13d1fd86d99b612"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/afc545da381ba0c651b2658966ac737032676f01"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e8823e6ff313465910edea07581627d85e68d9fd"
},
{
"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/03/msg00002.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"
}
]
}
ICSA-25-226-07
Vulnerability from csaf_cisa - Published: 2025-08-12 00:00 - Updated: 2026-02-25 07:00OESA-2025-1095 (CVE-2023-52480)
Vulnerability from osv_openeuler – Published: 2025-02-08 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix race condition between session lookup and expire
Thread A + Thread B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | +
This patch add rwsem to fix race condition between ksmbd_session_lookup and ksmbd_expire_session.(CVE-2023-52480)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Fix connection failure handling
In case immediate MPA request processing fails, the newly created endpoint unlinks the listening endpoint and is ready to be dropped. This special case was not handled correctly by the code handling the later TCP socket close, causing a NULL dereference crash in siw_cm_work_handler() when dereferencing a NULL listener. We now also cancel the useless MPA timeout, if immediate MPA request processing fails.
This patch furthermore simplifies MPA processing in general: Scheduling a useless TCP socket read in sk_data_ready() upcall is now surpressed, if the socket is already moved out of TCP_ESTABLISHED state.(CVE-2023-52513)
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Fix buffer overflow in trans_stat_show
Fix buffer overflow in trans_stat_show().
Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE.
Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled.
Return -EFBIG in the case where we don't have enough space to write the full transition table.
Also document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad7091r: Allow users to configure device events
AD7091R-5 devices are supported by the ad7091r-5 driver together with the ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall bellow the thresholds of low limit registers or above the values set in high limit registers. However, to configure iio events and their thresholds, a set of callback functions must be implemented and those were not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback functions was a null pointer dereference in the kernel because the pointers to the callback functions were not set.
Implement event configuration callbacks allowing users to read/write event thresholds and enable/disable event generation.
Since the event spec structs are generic to AD7091R devices, also move those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix potential context UAFs
gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the last thing that gem_context_register() does with the ctx pointer.
[tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)
A race condition was found in the Linux kernel's net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.
(CVE-2024-24857)
A race condition was found in the Linux kernel's net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.
(CVE-2024-24859)
In the Linux kernel, the following vulnerability has been resolved:
xhci: handle isoc Babble and Buffer Overrun events properly
xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs.
The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message.
Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion.
Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Fix out-of-bounds memory access
Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.(CVE-2024-26664)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations
- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.
- Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.(CVE-2024-26673)
In the Linux kernel, the following vulnerability has been resolved:
usb: roles: fix NULL pointer issue when put module's reference
In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference.
This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations.(CVE-2024-26747)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix memory double free when handle zero packet
829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);
Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again.
Log:
[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]
Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()
... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ...
'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it.
[ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28
Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem.(CVE-2024-26749)
In the Linux kernel, the following vulnerability has been resolved:
crypto: virtio/akcipher - Fix stack overflow on memcpy
sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o(CVE-2024-26753)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix possible deadlock in subflow diag
Syzbot and Eric reported a lockdep splat in the subflow diag:
WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted
syz-executor.2/24141 is trying to acquire lock: ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137
but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&h->lhash2[i].lock){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743 inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261 __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217 inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239 rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316 rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577 ops_init+0x352/0x610 net/core/net_namespace.c:136 __register_pernet_operations net/core/net_namespace.c:1214 [inline] register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283 register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370 rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735 do_one_initcall+0x238/0x830 init/main.c:1236 do_initcall_level+0x157/0x210 init/main.c:1298 do_initcalls+0x3f/0x80 init/main.c:1314 kernel_init_freeable+0x42f/0x5d0 init/main.c:1551 kernel_init+0x1d/0x2a0 init/main.c:1441 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242
-> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_fast include/net/sock.h:1723 [inline] subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77
As noted by Eric we can break the lock dependency chain avoid dumping ---truncated---(CVE-2024-26781)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read
There is chip (ls1028a) errata:
The SoC may hang on 16 byte unaligned read transactions by QDMA.
Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller.
Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ).
Implement this workaround.(CVE-2024-26790)
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
[ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] _syssendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated---(CVE-2024-26793)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix potencial out-of-bounds when buffer offset is invalid
I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length.(CVE-2024-26952)
In the Linux kernel, the following vulnerability has been resolved:
clk: Get runtime PM before walking tree during disable_unused
Doug reported [1] the following hung task:
INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20
The first thread is walking the clk tree and calling clk_pm_runtime_get() to power on devices required to read the clk hardware via struct clk_ops::is_enabled(). This thread holds the clk prepare_lock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clk_prepare(), trying to grab the prepare_lock waiting on the first thread.
This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held. Actually doing that is near impossible today because the global prepare_lock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again.
Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---(CVE-2024-27004)
In the Linux kernel, the following vulnerability has been resolved:
fpga: bridge: add owner module and take its refcount
The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner.
Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge.
Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions.(CVE-2024-36479)
In the Linux kernel, the following vulnerability has been resolved:
net: relax socket state check at accept time.
Christoph reported the following splat:
WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0 Modules linked in: CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759 Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd <0f> 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80 RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293 RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64 R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000 R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800 FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786 do_accept+0x435/0x620 net/socket.c:1929 __sys_accept4_file net/socket.c:1969 [inline] __sys_accept4+0x9b/0x110 net/socket.c:1999 __do_sys_accept net/socket.c:2016 [inline] __se_sys_accept net/socket.c:2013 [inline] __x64_sys_accept+0x7d/0x90 net/socket.c:2013 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x4315f9 Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300 R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 </TASK>
The reproducer invokes shutdown() before entering the listener status. After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets"), the above causes the child to reach the accept syscall in FIN_WAIT1 status.
Eric noted we can relax the existing assertion in __inet_accept()(CVE-2024-36484)
In the Linux kernel, the following vulnerability has been resolved:
fpga: manager: add owner module and take its refcount
The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner.
Also, update the documentation to keep it consistent with the new interface for registering an fpga manager.
Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions.(CVE-2024-37021)
In the Linux kernel, the following vulnerability has been resolved:
i2c: lpi2c: Avoid calling clk_get_rate during transfer
Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.(CVE-2024-40965)
In the Linux kernel, the following vulnerability has been resolved:
arm64: probes: Fix uprobes for big-endian kernels
The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems:
-
The kernel may may erroneously reject probing an instruction which can safely be probed.
-
The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely.
-
The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding.
The endianness mismatch isn't caught by the compiler or sparse because:
-
The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness.
-
While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning.
Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change.
At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity.
Tested with the following:
| #include <stdio.h> | #include <stdbool.h> | | #define noinline attribute((noinline)) | | static noinline void adrp_self(void) | { | void addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char argv) | { | void ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | }
.... where the adrp_self() function was compiled to:
| 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret
Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result:
| # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL
After this patch, the ADRP is correctly recognized and simulated:
| # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL(CVE-2024-50194)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix flushing uninitialized delayed_work on cache_ctr error
An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error.
Reproduce steps:
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
Kernel logs:
(snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890
Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb ("dm cache: Fix UAF in destroy()")) as cache_dtr is not changed.(CVE-2024-50280)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".
This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints.
This patch (of 2):
It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled.
This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller.
Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place.
So this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)
In the Linux kernel, the following vulnerability has been resolved:
um: net: Do not use drvdata in release
The drvdata is not available in release. Let's just use container_of() to get the uml_net instance. Otherwise, removing a network device will result in a crash:
RIP: 0033:net_device_release+0x10/0x6f RSP: 00000000e20c7c40 EFLAGS: 00010206 RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0 RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028 RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70 R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000 R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mc_work_proc Stack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010 Call Trace: [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<6002ec9c>] net_remove+0x63/0x69 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<60087d40>] ? __remove_hrtimer+0x38/0x74 [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98 [<6006b3cf>] ? dl_server_stop+0x3f/0x48 [<6006b390>] ? dl_server_stop+0x0/0x48 [<600672e8>] ? dequeue_entities+0x327/0x390 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6(CVE-2024-53183)
In the Linux kernel, the following vulnerability has been resolved:
xen: Fix the issue of resource not being properly released in xenbus_dev_probe()
This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems.
To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak.
This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.(CVE-2024-53198)
In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx->plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
Replace one-element array with a flexible-array member in struct
mwifiex_ie_types_wildcard_ssid_params to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like:
ssid_len = user_scan_in->ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[i].ssid, ssid_len);
There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed.(CVE-2024-56539)
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Require entities to have a non-zero unique ID
Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID.
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
So, deny allocating an entity with ID 0 or an ID that belongs to a unit that is already added to the list of entities.
This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings.
In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid.
Here is a sample stack trace for one of those cases.
[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1fd/0x290 [ 21.056413] uvc_probe+0x380e/0x3dc0 [ 21.056676] ? __lock_acquire+0x5aa/0x26e0 [ 21.056946] ? find_held_lock+0x33/0xa0 [ 21.057196] ? kernfs_activate+0x70/0x80 [ 21.057533] ? usb_match_dy ---truncated---(CVE-2024-56571)
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Create all dump files during debugfs initialization
For the current debugfs of hisi_sas, after user triggers dump, the driver allocate memory space to save the register information and create debugfs files to display the saved information. In this process, the debugfs files created after each dump.
Therefore, when the dump is triggered while the driver is unbind, the following hang occurs:
[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [67840.862947] Mem abort info: [67840.865855] ESR = 0x0000000096000004 [67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits [67840.875125] SET = 0, FnV = 0 [67840.878291] EA = 0, S1PTW = 0 [67840.881545] FSC = 0x04: level 0 translation fault [67840.886528] Data abort info: [67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000 [67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000 [67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [67841.003628] pc : down_write+0x30/0x98 [67841.007546] lr : start_creating.part.0+0x60/0x198 [67841.012495] sp : ffff8000b979ba20 [67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40 [67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8 [67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18 [67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020 [67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff [67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18 [67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18 [67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9 [67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001 [67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0 [67841.089759] Call trace: [67841.092456] down_write+0x30/0x98 [67841.096017] start_creating.part.0+0x60/0x198 [67841.100613] debugfs_create_dir+0x48/0x1f8 [67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw] [67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw] [67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw] [67841.125115] full_proxy_write+0x68/0xc8 [67841.129175] vfs_write+0xd8/0x3f0 [67841.132708] ksys_write+0x70/0x108 [67841.136317] __arm64_sys_write+0x24/0x38 [67841.140440] invoke_syscall+0x50/0x128 [67841.144385] el0_svc_common.constprop.0+0xc8/0xf0 [67841.149273] do_el0_svc+0x24/0x38 [67841.152773] el0_svc+0x38/0xd8 [67841.156009] el0t_64_sync_handler+0xc0/0xc8 [67841.160361] el0t_64_sync+0x1a4/0x1a8 [67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05) [67841.170443] ---[ end trace 0000000000000000 ]---
To fix this issue, create all directories and files during debugfs initialization. In this way, the driver only needs to allocate memory space to save information each time the user triggers dumping.(CVE-2024-56588)
In the Linux kernel, the following vulnerability has been resolved:
kcsan: Turn report_filterlist_lock into a raw_spinlock
Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see splats like:
| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 10002, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 156674 | hardirqs last enabled at (156673): [<ffffffff81130bd9>] do_idle+0x1f9/0x240 | hardirqs last disabled at (156674): [<ffffffff82254f84>] sysvec_apic_timer_interrupt+0x14/0xc0 | softirqs last enabled at (0): [<ffffffff81099f47>] copy_process+0xfc7/0x4b60 | softirqs last disabled at (0): [<0000000000000000>] 0x0 | Preemption disabled at: | [<ffffffff814a3e2a>] paint_ptr+0x2a/0x90 | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 | Call Trace: | <IRQ> | dump_stack_lvl+0x7e/0xc0 | dump_stack+0x1d/0x30 | __might_resched+0x1a2/0x270 | rt_spin_lock+0x68/0x170 | kcsan_skip_report_debugfs+0x43/0xe0 | print_report+0xb5/0x590 | kcsan_report_known_origin+0x1b1/0x1d0 | kcsan_setup_watchpoint+0x348/0x650 | __tsan_unaligned_write1+0x16d/0x1d0 | hrtimer_interrupt+0x3d6/0x430 | __sysvec_apic_timer_interrupt+0xe8/0x3a0 | sysvec_apic_timer_interrupt+0x97/0xc0 | </IRQ>
On a detected data race, KCSAN's reporting logic checks if it should filter the report. That list is protected by the report_filterlist_lock non-raw spinlock which may sleep on RT kernels.
Since KCSAN may report data races in any context, convert it to a raw_spinlock.
This requires being careful about when to allocate memory for the filter list itself which can be done via KCSAN's debugfs interface. Concurrent modification of the filter list via debugfs should be rare: the chosen strategy is to optimistically pre-allocate memory before the critical section and discard if unused.(CVE-2024-56610)
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM
We currently assume that there is at least one VMA in a MM, which isn't true.
So we might end up having find_vma() return NULL, to then de-reference NULL. So properly handle find_vma() returning NULL.
This fixes the report:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline] RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194 Code: ... RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000 RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044 RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1 R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003 R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8 FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
akpm@linux-foundation.org: add unlikely()
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix use after free on unload
System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpc_thread to terminate (UNLOADING flag and kthread_stop).
On setting the UNLOADING flag when dpc_thread happens to run at the time and sees the flag, this causes dpc_thread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free.
Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop as the main signal to exit dpc_thread.
[596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360
... [596663.813008] Call Trace: [596663.813022] ? __dentry_kill+0x121/0x170 [596663.813030] ? _cond_resched+0x15/0x30 [596663.813034] ? _cond_resched+0x15/0x30 [596663.813039] ? wait_for_completion+0x35/0x190 [596663.813048] ? try_to_wake_up+0x63/0x540 [596663.813055] free_task+0x5a/0x60 [596663.813061] kthread_stop+0xf3/0x100 [596663.813103] qla2x00_remove_one+0x284/0x440 qla2xxx
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport
Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL.(CVE-2024-56688)
In the Linux kernel, the following vulnerability has been resolved:
9p/xen: fix release of IRQ
Kernel logs indicate an IRQ was double-freed.
Pass correct device ID during IRQ release.
Dominique: remove confusing variable reset to 0
In the Linux kernel, the following vulnerability has been resolved:
ionic: Fix netdev notifier unregister on failure
If register_netdev() fails, then the driver leaks the netdev notifier. Fix this by calling ionic_lif_unregister() on register_netdev() failure. This will also call ionic_lif_unregister_phc() if it has already been registered.(CVE-2024-56715)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()
When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead.(CVE-2024-56746)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv
When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is the dangling pointer.
During the remounting process, the pointer dqi_priv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOT_SUSPENDED flag instead of setting the DQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2_get_next_id is called and only checks the quota usage flags and not the quota suspended flags.
To fix this, I set dqi_priv to null when it is freed after remounting with read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"perf-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-248.0.0.150.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-248.0.0.150.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"perf-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-248.0.0.150.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-248.0.0.150.oe2203sp3"
}
],
"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:\n\nksmbd: fix race condition between session lookup and expire\n\n Thread A + Thread B\n ksmbd_session_lookup | smb2_sess_setup\n sess = xa_load |\n |\n | xa_erase(\u0026amp;conn-\u0026gt;sessions, sess-\u0026gt;id);\n |\n | ksmbd_session_destroy(sess) --\u0026gt; kfree(sess)\n |\n // UAF! |\n sess-\u0026gt;last_active = jiffies |\n +\n\nThis patch add rwsem to fix race condition between ksmbd_session_lookup\nand ksmbd_expire_session.(CVE-2023-52480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Fix connection failure handling\n\nIn case immediate MPA request processing fails, the newly\ncreated endpoint unlinks the listening endpoint and is\nready to be dropped. This special case was not handled\ncorrectly by the code handling the later TCP socket close,\ncausing a NULL dereference crash in siw_cm_work_handler()\nwhen dereferencing a NULL listener. We now also cancel\nthe useless MPA timeout, if immediate MPA request\nprocessing fails.\n\nThis patch furthermore simplifies MPA processing in general:\nScheduling a useless TCP socket read in sk_data_ready() upcall\nis now surpressed, if the socket is already moved out of\nTCP_ESTABLISHED state.(CVE-2023-52513)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Fix buffer overflow in trans_stat_show\n\nFix buffer overflow in trans_stat_show().\n\nConvert simple snprintf to the more secure scnprintf with size of\nPAGE_SIZE.\n\nAdd condition checking if we are exceeding PAGE_SIZE and exit early from\nloop. Also add at the end a warning that we exceeded PAGE_SIZE and that\nstats is disabled.\n\nReturn -EFBIG in the case where we don\u0026apos;t have enough space to write the\nfull transition table.\n\nAlso document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7091r: Allow users to configure device events\n\nAD7091R-5 devices are supported by the ad7091r-5 driver together with\nthe ad7091r-base driver. Those drivers declared iio events for notifying\nuser space when ADC readings fall bellow the thresholds of low limit\nregisters or above the values set in high limit registers.\nHowever, to configure iio events and their thresholds, a set of callback\nfunctions must be implemented and those were not present until now.\nThe consequence of trying to configure ad7091r-5 events without the\nproper callback functions was a null pointer dereference in the kernel\nbecause the pointers to the callback functions were not set.\n\nImplement event configuration callbacks allowing users to read/write\nevent thresholds and enable/disable event generation.\n\nSince the event spec structs are generic to AD7091R devices, also move\nthose from the ad7091r-5 driver the base driver so they can be reused\nwhen support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix potential context UAFs\n\ngem_context_register() makes the context visible to userspace, and which\npoint a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.\nSo we need to ensure that nothing uses the ctx ptr after this. And we\nneed to ensure that adding the ctx to the xarray is the *last* thing\nthat gem_context_register() does with the ctx pointer.\n\n[tursulin: Stable and fixes tags add/tidy.]\n(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.\n\n\n\n\n(CVE-2024-24857)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.\n\n\n\n\n\n\n\n(CVE-2024-24859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxhci: handle isoc Babble and Buffer Overrun events properly\n\nxHCI 4.9 explicitly forbids assuming that the xHC has released its\nownership of a multi-TRB TD when it reports an error on one of the\nearly TRBs. Yet the driver makes such assumption and releases the TD,\nallowing the remaining TRBs to be freed or overwritten by new TDs.\n\nThe xHC should also report completion of the final TRB due to its IOC\nflag being set by us, regardless of prior errors. This event cannot\nbe recognized if the TD has already been freed earlier, resulting in\n\u0026quot;Transfer event TRB DMA ptr not part of current TD\u0026quot; error message.\n\nFix this by reusing the logic for processing isoc Transaction Errors.\nThis also handles hosts which fail to report the final completion.\n\nFix transfer length reporting on Babble errors. They may be caused by\ndevice malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) Fix out-of-bounds memory access\n\nFix a bug that pdata-\u0026gt;cpu_map[] is set before out-of-bounds check.\nThe problem might be triggered on systems with more than 128 cores per\npackage.(CVE-2024-26664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations\n\n- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.\n- Disallow layer 4 protocol with no ports, since destination port is a\n mandatory attribute for this object.(CVE-2024-26673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: roles: fix NULL pointer issue when put module\u0026apos;s reference\n\nIn current design, usb role class driver will get usb_role_switch parent\u0026apos;s\nmodule reference after the user get usb_role_switch device and put the\nreference after the user put the usb_role_switch device. However, the\nparent device of usb_role_switch may be removed before the user put the\nusb_role_switch. If so, then, NULL pointer issue will be met when the user\nput the parent module\u0026apos;s reference.\n\nThis will save the module pointer in structure of usb_role_switch. Then,\nwe don\u0026apos;t need to find module by iterating long relations.(CVE-2024-26747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix memory double free when handle zero packet\n\n829 if (request-\u0026gt;complete) {\n830 spin_unlock(\u0026amp;priv_dev-\u0026gt;lock);\n831 usb_gadget_giveback_request(\u0026amp;priv_ep-\u0026gt;endpoint,\n832 request);\n833 spin_lock(\u0026amp;priv_dev-\u0026gt;lock);\n834 }\n835\n836 if (request-\u0026gt;buf == priv_dev-\u0026gt;zlp_buf)\n837 cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, request);\n\nDriver append an additional zero packet request when queue a packet, which\nlength mod max packet size is 0. When transfer complete, run to line 831,\nusb_gadget_giveback_request() will free this requestion. 836 condition is\ntrue, so cdns3_gadget_ep_free_request() free this request again.\n\nLog:\n\n[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.140696][ T150]\n[ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):\n[ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]\n\nAdd check at line 829, skip call usb_gadget_giveback_request() if it is\nadditional zero length packet request. Needn\u0026apos;t call\nusb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()\n\n ...\n cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, \u0026amp;priv_req-\u0026gt;request);\n list_del_init(\u0026amp;priv_req-\u0026gt;list);\n ...\n\n\u0026apos;priv_req\u0026apos; actually free at cdns3_gadget_ep_free_request(). But\nlist_del_init() use priv_req-\u0026gt;list after it.\n\n[ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4\n[ 1542.642868][ T534]\n[ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):\n[ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4\n[ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]\n[ 1542.671571][ T534] usb_ep_disable+0x44/0xe4\n[ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8\n[ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368\n[ 1542.685478][ T534] ffs_func_disable+0x18/0x28\n\nMove list_del_init() before cdns3_gadget_ep_free_request() to resolve this\nproblem.(CVE-2024-26749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: virtio/akcipher - Fix stack overflow on memcpy\n\nsizeof(struct virtio_crypto_akcipher_session_para) is less than\nsizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from\nstack variable leads stack overflow. Clang reports this issue by\ncommands:\nmake -j CC=clang-14 mrproper \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build CC=clang-14 allmodconfig \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/\n virtio_crypto_akcipher_algs.o(CVE-2024-26753)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix possible deadlock in subflow diag\n\nSyzbot and Eric reported a lockdep splat in the subflow diag:\n\n WARNING: possible circular locking dependency detected\n 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted\n\n syz-executor.2/24141 is trying to acquire lock:\n ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n\n but task is already holding lock:\n ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at: spin_lock\n include/linux/spinlock.h:351 [inline]\n ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at:\n inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u0026gt; #1 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}:\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]\n _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154\n spin_lock include/linux/spinlock.h:351 [inline]\n __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743\n inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261\n __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217\n inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239\n rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316\n rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577\n ops_init+0x352/0x610 net/core/net_namespace.c:136\n __register_pernet_operations net/core/net_namespace.c:1214 [inline]\n register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283\n register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370\n rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735\n do_one_initcall+0x238/0x830 init/main.c:1236\n do_initcall_level+0x157/0x210 init/main.c:1298\n do_initcalls+0x3f/0x80 init/main.c:1314\n kernel_init_freeable+0x42f/0x5d0 init/main.c:1551\n kernel_init+0x1d/0x2a0 init/main.c:1441\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242\n\n -\u0026gt; #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:\n check_prev_add kernel/locking/lockdep.c:3134 [inline]\n check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869\n __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n lock_sock_fast include/net/sock.h:1723 [inline]\n subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28\n tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345\n inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061\n __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263\n inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371\n netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264\n __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:338 [inline]\n inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405\n sock_diag_rcv_msg+0xe7/0x410\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\nAs noted by Eric we can break the lock dependency chain avoid\ndumping \n---truncated---(CVE-2024-26781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read\n\nThere is chip (ls1028a) errata:\n\nThe SoC may hang on 16 byte unaligned read transactions by QDMA.\n\nUnaligned read transactions initiated by QDMA may stall in the NOC\n(Network On-Chip), causing a deadlock condition. Stalled transactions will\ntrigger completion timeouts in PCIe controller.\n\nWorkaround:\nEnable prefetch by setting the source descriptor prefetchable bit\n( SD[PF] = 1 ).\n\nImplement this workaround.(CVE-2024-26790)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngtp: fix use-after-free and null-ptr-deref in gtp_newlink()\n\nThe gtp_link_ops operations structure for the subsystem must be\nregistered after registering the gtp_net_ops pernet operations structure.\n\nSyzkaller hit \u0026apos;general protection fault in gtp_genl_dump_pdp\u0026apos; bug:\n\n[ 1010.702740] gtp: GTP module unloaded\n[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\n[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1\n[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\n[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00\n[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203\n[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000\n[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282\n[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000\n[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80\n[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400\n[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000\n[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0\n[ 1010.715968] PKRU: 55555554\n[ 1010.715972] Call Trace:\n[ 1010.715985] ? __die_body.cold+0x1a/0x1f\n[ 1010.715995] ? die_addr+0x43/0x70\n[ 1010.716002] ? exc_general_protection+0x199/0x2f0\n[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30\n[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]\n[ 1010.716042] __rtnl_newlink+0x1063/0x1700\n[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0\n[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0\n[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0\n[ 1010.716076] ? __kernel_text_address+0x56/0xa0\n[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0\n[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30\n[ 1010.716098] ? arch_stack_walk+0x9e/0xf0\n[ 1010.716106] ? stack_trace_save+0x91/0xd0\n[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170\n[ 1010.716121] ? __lock_acquire+0x15c5/0x5380\n[ 1010.716139] ? mark_held_locks+0x9e/0xe0\n[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0\n[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700\n[ 1010.716160] rtnl_newlink+0x69/0xa0\n[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50\n[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716179] ? lock_acquire+0x1fe/0x560\n[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50\n[ 1010.716196] netlink_rcv_skb+0x14d/0x440\n[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716208] ? netlink_ack+0xab0/0xab0\n[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50\n[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50\n[ 1010.716226] ? __virt_addr_valid+0x30b/0x590\n[ 1010.716233] netlink_unicast+0x54b/0x800\n[ 1010.716240] ? netlink_attachskb+0x870/0x870\n[ 1010.716248] ? __check_object_size+0x2de/0x3b0\n[ 1010.716254] netlink_sendmsg+0x938/0xe40\n[ 1010.716261] ? netlink_unicast+0x800/0x800\n[ 1010.716269] ? __import_iovec+0x292/0x510\n[ 1010.716276] ? netlink_unicast+0x800/0x800\n[ 1010.716284] __sock_sendmsg+0x159/0x190\n[ 1010.716290] ____sys_sendmsg+0x712/0x880\n[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0\n[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270\n[ 1010.716309] ? lock_acquire+0x1fe/0x560\n[ 1010.716315] ? drain_array_locked+0x90/0x90\n[ 1010.716324] ___sys_sendmsg+0xf8/0x170\n[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170\n[ 1010.716337] ? lockdep_init_map\n---truncated---(CVE-2024-26793)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix potencial out-of-bounds when buffer offset is invalid\n\nI found potencial out-of-bounds when buffer offset fields of a few requests\nis invalid. This patch set the minimum value of buffer offset field to\n-\u0026gt;Buffer offset to validate buffer length.(CVE-2024-26952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree during disable_unused\n\nDoug reported [1] the following hung task:\n\n INFO: task swapper/0:1 blocked for more than 122 seconds.\n Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008\n Call trace:\n __switch_to+0xf4/0x1f4\n __schedule+0x418/0xb80\n schedule+0x5c/0x10c\n rpm_resume+0xe0/0x52c\n rpm_resume+0x178/0x52c\n __pm_runtime_resume+0x58/0x98\n clk_pm_runtime_get+0x30/0xb0\n clk_disable_unused_subtree+0x58/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused+0x4c/0xe4\n do_one_initcall+0xcc/0x2d8\n do_initcall_level+0xa4/0x148\n do_initcalls+0x5c/0x9c\n do_basic_setup+0x24/0x30\n kernel_init_freeable+0xec/0x164\n kernel_init+0x28/0x120\n ret_from_fork+0x10/0x20\n INFO: task kworker/u16:0:9 blocked for more than 122 seconds.\n Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n __switch_to+0xf4/0x1f4\n __schedule+0x418/0xb80\n schedule+0x5c/0x10c\n schedule_preempt_disabled+0x2c/0x48\n __mutex_lock+0x238/0x488\n __mutex_lock_slowpath+0x1c/0x28\n mutex_lock+0x50/0x74\n clk_prepare_lock+0x7c/0x9c\n clk_core_prepare_lock+0x20/0x44\n clk_prepare+0x24/0x30\n clk_bulk_prepare+0x40/0xb0\n mdss_runtime_resume+0x54/0x1c8\n pm_generic_runtime_resume+0x30/0x44\n __genpd_runtime_resume+0x68/0x7c\n genpd_runtime_resume+0x108/0x1f4\n __rpm_callback+0x84/0x144\n rpm_callback+0x30/0x88\n rpm_resume+0x1f4/0x52c\n rpm_resume+0x178/0x52c\n __pm_runtime_resume+0x58/0x98\n __device_attach+0xe0/0x170\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x3c/0x9c\n device_add+0x644/0x814\n mipi_dsi_device_register_full+0xe4/0x170\n devm_mipi_dsi_device_register_full+0x28/0x70\n ti_sn_bridge_probe+0x1dc/0x2c0\n auxiliary_bus_probe+0x4c/0x94\n really_probe+0xcc/0x2c8\n __driver_probe_device+0xa8/0x130\n driver_probe_device+0x48/0x110\n __device_attach_driver+0xa4/0xcc\n bus_for_each_drv+0x8c/0xd8\n __device_attach+0xf8/0x170\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x3c/0x9c\n deferred_probe_work_func+0x9c/0xd8\n process_one_work+0x148/0x518\n worker_thread+0x138/0x350\n kthread+0x138/0x1e0\n ret_from_fork+0x10/0x20\n\nThe first thread is walking the clk tree and calling\nclk_pm_runtime_get() to power on devices required to read the clk\nhardware via struct clk_ops::is_enabled(). This thread holds the clk\nprepare_lock, and is trying to runtime PM resume a device, when it finds\nthat the device is in the process of resuming so the thread schedule()s\naway waiting for the device to finish resuming before continuing. The\nsecond thread is runtime PM resuming the same device, but the runtime\nresume callback is calling clk_prepare(), trying to grab the\nprepare_lock waiting on the first thread.\n\nThis is a classic ABBA deadlock. To properly fix the deadlock, we must\nnever runtime PM resume or suspend a device with the clk prepare_lock\nheld. Actually doing that is near impossible today because the global\nprepare_lock would have to be dropped in the middle of the tree, the\ndevice runtime PM resumed/suspended, and then the prepare_lock grabbed\nagain to ensure consistency of the clk tree topology. If anything\nchanges with the clk tree in the meantime, we\u0026apos;ve lost and will need to\nstart the operation all over again.\n\nLuckily, most of the time we\u0026apos;re simply incrementing or decrementing the\nruntime PM count on an active device, so we don\u0026apos;t have the chance to\nschedule away with the prepare_lock held. Let\u0026apos;s fix this immediate\nproblem that can be\n---truncated---(CVE-2024-27004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: bridge: add owner module and take its refcount\n\nThe current implementation of the fpga bridge assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the bridge if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_bridge\nstruct and use it to take the module\u0026apos;s refcount. Modify the function for\nregistering a bridge to take an additional owner module parameter and\nrename it to avoid conflicts. Use the old function name for a helper macro\nthat automatically sets the module that registers the bridge as the owner.\nThis ensures compatibility with existing low-level control modules and\nreduces the chances of registering a bridge without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga bridge.\n\nOther changes: opportunistically move put_device() from __fpga_bridge_get()\nto fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since\nthe bridge device is taken in these functions.(CVE-2024-36479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: relax socket state check at accept time.\n\nChristoph reported the following splat:\n\nWARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0\nModules linked in:\nCPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nRIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759\nCode: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd \u0026lt;0f\u0026gt; 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80\nRSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293\nRAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64\nR10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000\nR13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800\nFS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786\n do_accept+0x435/0x620 net/socket.c:1929\n __sys_accept4_file net/socket.c:1969 [inline]\n __sys_accept4+0x9b/0x110 net/socket.c:1999\n __do_sys_accept net/socket.c:2016 [inline]\n __se_sys_accept net/socket.c:2013 [inline]\n __x64_sys_accept+0x7d/0x90 net/socket.c:2013\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x4315f9\nCode: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00\nRSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b\nRAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004\nRBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300\nR10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055\n \u0026lt;/TASK\u0026gt;\n\nThe reproducer invokes shutdown() before entering the listener status.\nAfter commit 94062790aedb (\u0026quot;tcp: defer shutdown(SEND_SHUTDOWN) for\nTCP_SYN_RECV sockets\u0026quot;), the above causes the child to reach the accept\nsyscall in FIN_WAIT1 status.\n\nEric noted we can relax the existing assertion in __inet_accept()(CVE-2024-36484)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: manager: add owner module and take its refcount\n\nThe current implementation of the fpga manager assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the manager if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_manager\nstruct and use it to take the module\u0026apos;s refcount. Modify the functions for\nregistering the manager to take an additional owner module parameter and\nrename them to avoid conflicts. Use the old function names for helper\nmacros that automatically set the module that registers the manager as the\nowner. This ensures compatibility with existing low-level control modules\nand reduces the chances of registering a manager without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga manager.\n\nOther changes: opportunistically move put_device() from __fpga_mgr_get() to\nfpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the\nmanager device is taken in these functions.(CVE-2024-37021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: lpi2c: Avoid calling clk_get_rate during transfer\n\nInstead of repeatedly calling clk_get_rate for each transfer, lock\nthe clock rate and cache the value.\nA deadlock has been observed while adding tlv320aic32x4 audio codec to\nthe system. When this clock provider adds its clock, the clk mutex is\nlocked already, it needs to access i2c, which in return needs the mutex\nfor clk_get_rate as well.(CVE-2024-40965)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Fix uprobes for big-endian kernels\n\nThe arm64 uprobes code is broken for big-endian kernels as it doesn\u0026apos;t\nconvert the in-memory instruction encoding (which is always\nlittle-endian) into the kernel\u0026apos;s native endianness before analyzing and\nsimulating instructions. This may result in a few distinct problems:\n\n* The kernel may may erroneously reject probing an instruction which can\n safely be probed.\n\n* The kernel may erroneously erroneously permit stepping an\n instruction out-of-line when that instruction cannot be stepped\n out-of-line safely.\n\n* The kernel may erroneously simulate instruction incorrectly dur to\n interpretting the byte-swapped encoding.\n\nThe endianness mismatch isn\u0026apos;t caught by the compiler or sparse because:\n\n* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so\n the compiler and sparse have no idea these contain a little-endian\n 32-bit value. The core uprobes code populates these with a memcpy()\n which similarly does not handle endianness.\n\n* While the uprobe_opcode_t type is an alias for __le32, both\n arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]\n to the similarly-named probe_opcode_t, which is an alias for u32.\n Hence there is no endianness conversion warning.\n\nFix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and\nadding the appropriate __le32_to_cpu() conversions prior to consuming\nthe instruction encoding. The core uprobes copies these fields as opaque\nranges of bytes, and so is unaffected by this change.\n\nAt the same time, remove MAX_UINSN_BYTES and consistently use\nAARCH64_INSN_SIZE for clarity.\n\nTested with the following:\n\n| #include \u0026lt;stdio.h\u0026gt;\n| #include \u0026lt;stdbool.h\u0026gt;\n|\n| #define noinline __attribute__((noinline))\n|\n| static noinline void *adrp_self(void)\n| {\n| void *addr;\n|\n| asm volatile(\n| \u0026quot; adrp %x0, adrp_self\\n\u0026quot;\n| \u0026quot; add %x0, %x0, :lo12:adrp_self\\n\u0026quot;\n| : \u0026quot;=r\u0026quot; (addr));\n| }\n|\n|\n| int main(int argc, char *argv)\n| {\n| void *ptr = adrp_self();\n| bool equal = (ptr == adrp_self);\n|\n| printf(\u0026quot;adrp_self =\u0026gt; %p\\n\u0026quot;\n| \u0026quot;adrp_self() =\u0026gt; %p\\n\u0026quot;\n| \u0026quot;%s\\n\u0026quot;,\n| adrp_self, ptr, equal ? \u0026quot;EQUAL\u0026quot; : \u0026quot;NOT EQUAL\u0026quot;);\n|\n| return 0;\n| }\n\n.... where the adrp_self() function was compiled to:\n\n| 00000000004007e0 \u0026lt;adrp_self\u0026gt;:\n| 4007e0: 90000000 adrp x0, 400000 \u0026lt;__ehdr_start\u0026gt;\n| 4007e4: 911f8000 add x0, x0, #0x7e0\n| 4007e8: d65f03c0 ret\n\nBefore this patch, the ADRP is not recognized, and is assumed to be\nsteppable, resulting in corruption of the result:\n\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0xffffffffff7e0\n| NOT EQUAL\n\nAfter this patch, the ADRP is correctly recognized and simulated:\n\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| #\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL(CVE-2024-50194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix flushing uninitialized delayed_work on cache_ctr error\n\nAn unexpected WARN_ON from flush_work() may occur when cache creation\nfails, caused by destroying the uninitialized delayed_work waker in the\nerror path of cache_create(). For example, the warning appears on the\nsuperblock checksum error.\n\nReproduce steps:\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\nKernel logs:\n\n(snip)\nWARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890\n\nFix by pulling out the cancel_delayed_work_sync() from the constructor\u0026apos;s\nerror path. This patch doesn\u0026apos;t affect the use-after-free fix for\nconcurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\u0026quot;dm cache: Fix\nUAF in destroy()\u0026quot;)) as cache_dtr is not changed.(CVE-2024-50280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix null-ptr-deref in block_touch_buffer tracepoint\n\nPatch series \u0026quot;nilfs2: fix null-ptr-deref bugs on block tracepoints\u0026quot;.\n\nThis series fixes null pointer dereference bugs that occur when using\nnilfs2 and two block-related tracepoints.\n\n\nThis patch (of 2):\n\nIt has been reported that when using \u0026quot;block:block_touch_buffer\u0026quot;\ntracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a\nNULL pointer dereference, or a general protection fault when KASAN is\nenabled.\n\nThis happens because since the tracepoint was added in touch_buffer(), it\nreferences the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the\nbuffer head has a pointer to a block_device structure. In the current\nimplementation, the block_device structure is set after the function\nreturns to the caller.\n\nHere, touch_buffer() is used to mark the folio/page that owns the buffer\nhead as accessed, but the common search helper for folio/page used by the\ncaller function was optimized to mark the folio/page as accessed when it\nwas reimplemented a long time ago, eliminating the need to call\ntouch_buffer() here in the first place.\n\nSo this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: net: Do not use drvdata in release\n\nThe drvdata is not available in release. Let\u0026apos;s just use container_of()\nto get the uml_net instance. Otherwise, removing a network device will\nresult in a crash:\n\nRIP: 0033:net_device_release+0x10/0x6f\nRSP: 00000000e20c7c40 EFLAGS: 00010206\nRAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0\nRDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028\nRBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70\nR10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000\nR13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 627af028 62c7af00 e20c7c80 60276fcd\n 62778000 603f5820 627af028 00000000\n e20c7cb0 603a2bcd 627af000 62770010\nCall Trace:\n [\u0026lt;60276fcd\u0026gt;] device_release+0x70/0xba\n [\u0026lt;603a2bcd\u0026gt;] kobject_put+0xba/0xe7\n [\u0026lt;60277265\u0026gt;] put_device+0x19/0x1c\n [\u0026lt;60281266\u0026gt;] platform_device_put+0x26/0x29\n [\u0026lt;60281e5f\u0026gt;] platform_device_unregister+0x2c/0x2e\n [\u0026lt;6002ec9c\u0026gt;] net_remove+0x63/0x69\n [\u0026lt;60031316\u0026gt;] ? mconsole_reply+0x0/0x50\n [\u0026lt;600310c8\u0026gt;] mconsole_remove+0x160/0x1cc\n [\u0026lt;60087d40\u0026gt;] ? __remove_hrtimer+0x38/0x74\n [\u0026lt;60087ff8\u0026gt;] ? hrtimer_try_to_cancel+0x8c/0x98\n [\u0026lt;6006b3cf\u0026gt;] ? dl_server_stop+0x3f/0x48\n [\u0026lt;6006b390\u0026gt;] ? dl_server_stop+0x0/0x48\n [\u0026lt;600672e8\u0026gt;] ? dequeue_entities+0x327/0x390\n [\u0026lt;60038fa6\u0026gt;] ? um_set_signals+0x0/0x43\n [\u0026lt;6003070c\u0026gt;] mc_work_proc+0x77/0x91\n [\u0026lt;60057664\u0026gt;] process_scheduled_works+0x1b3/0x2dd\n [\u0026lt;60055f32\u0026gt;] ? assign_work+0x0/0x58\n [\u0026lt;60057f0a\u0026gt;] worker_thread+0x1e9/0x293\n [\u0026lt;6005406f\u0026gt;] ? set_pf_worker+0x0/0x64\n [\u0026lt;6005d65d\u0026gt;] ? arch_local_irq_save+0x0/0x2d\n [\u0026lt;6005d748\u0026gt;] ? kthread_exit+0x0/0x3a\n [\u0026lt;60057d21\u0026gt;] ? worker_thread+0x0/0x293\n [\u0026lt;6005dbf1\u0026gt;] kthread+0x126/0x12b\n [\u0026lt;600219c5\u0026gt;] new_thread_handler+0x85/0xb6(CVE-2024-53183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u0026gt;probe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch.(CVE-2024-53198)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()\n\nReplace one-element array with a flexible-array member in `struct\nmwifiex_ie_types_wildcard_ssid_params` to fix the following warning\non a MT8173 Chromebook (mt8173-elm-hana):\n\n[ 356.775250] ------------[ cut here ]------------\n[ 356.784543] memcpy: detected field-spanning write (size 6) of single field \u0026quot;wildcard_ssid_tlv-\u0026gt;ssid\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)\n[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]\n\nThe \u0026quot;(size 6)\u0026quot; above is exactly the length of the SSID of the network\nthis device was connected to. The source of the warning looks like:\n\n ssid_len = user_scan_in-\u0026gt;ssid_list[i].ssid_len;\n [...]\n memcpy(wildcard_ssid_tlv-\u0026gt;ssid,\n user_scan_in-\u0026gt;ssid_list[i].ssid, ssid_len);\n\nThere is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this\nstruct, but it already didn\u0026apos;t account for the size of the one-element\narray, so it doesn\u0026apos;t need to be changed.(CVE-2024-56539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Require entities to have a non-zero unique ID\n\nPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero\nunique ID.\n\n```\nEach Unit and Terminal within the video function is assigned a unique\nidentification number, the Unit ID (UID) or Terminal ID (TID), contained in\nthe bUnitID or bTerminalID field of the descriptor. The value 0x00 is\nreserved for undefined ID,\n```\n\nSo, deny allocating an entity with ID 0 or an ID that belongs to a unit\nthat is already added to the list of entities.\n\nThis also prevents some syzkaller reproducers from triggering warnings due\nto a chain of entities referring to themselves. In one particular case, an\nOutput Unit is connected to an Input Unit, both with the same ID of 1. But\nwhen looking up for the source ID of the Output Unit, that same entity is\nfound instead of the input entity, which leads to such warnings.\n\nIn another case, a backward chain was considered finished as the source ID\nwas 0. Later on, that entity was found, but its pads were not valid.\n\nHere is a sample stack trace for one of those cases.\n\n[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd\n[ 20.830206] usb 1-1: Using ep0 maxpacket: 8\n[ 20.833501] usb 1-1: config 0 descriptor??\n[ 21.038518] usb 1-1: string descriptor 0 read error: -71\n[ 21.038893] usb 1-1: Found UVC 0.00 device \u0026lt;unnamed\u0026gt; (2833:0201)\n[ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!\n[ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!\n[ 21.042218] ------------[ cut here ]------------\n[ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0\n[ 21.043195] Modules linked in:\n[ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444\n[ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[ 21.044639] Workqueue: usb_hub_wq hub_event\n[ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0\n[ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 \u0026lt;0f\u0026gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00\n[ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246\n[ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1\n[ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290\n[ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000\n[ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003\n[ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000\n[ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000\n[ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0\n[ 21.051136] PKRU: 55555554\n[ 21.051331] Call Trace:\n[ 21.051480] \u0026lt;TASK\u0026gt;\n[ 21.051611] ? __warn+0xc4/0x210\n[ 21.051861] ? media_create_pad_link+0x2c4/0x2e0\n[ 21.052252] ? report_bug+0x11b/0x1a0\n[ 21.052540] ? trace_hardirqs_on+0x31/0x40\n[ 21.052901] ? handle_bug+0x3d/0x70\n[ 21.053197] ? exc_invalid_op+0x1a/0x50\n[ 21.053511] ? asm_exc_invalid_op+0x1a/0x20\n[ 21.053924] ? media_create_pad_link+0x91/0x2e0\n[ 21.054364] ? media_create_pad_link+0x2c4/0x2e0\n[ 21.054834] ? media_create_pad_link+0x91/0x2e0\n[ 21.055131] ? _raw_spin_unlock+0x1e/0x40\n[ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210\n[ 21.055837] uvc_mc_register_entities+0x358/0x400\n[ 21.056144] uvc_register_chains+0x1fd/0x290\n[ 21.056413] uvc_probe+0x380e/0x3dc0\n[ 21.056676] ? __lock_acquire+0x5aa/0x26e0\n[ 21.056946] ? find_held_lock+0x33/0xa0\n[ 21.057196] ? kernfs_activate+0x70/0x80\n[ 21.057533] ? usb_match_dy\n---truncated---(CVE-2024-56571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Create all dump files during debugfs initialization\n\nFor the current debugfs of hisi_sas, after user triggers dump, the\ndriver allocate memory space to save the register information and create\ndebugfs files to display the saved information. In this process, the\ndebugfs files created after each dump.\n\nTherefore, when the dump is triggered while the driver is unbind, the\nfollowing hang occurs:\n\n[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0\n[67840.862947] Mem abort info:\n[67840.865855] ESR = 0x0000000096000004\n[67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits\n[67840.875125] SET = 0, FnV = 0\n[67840.878291] EA = 0, S1PTW = 0\n[67840.881545] FSC = 0x04: level 0 translation fault\n[67840.886528] Data abort info:\n[67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000\n[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000\n[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[67841.003628] pc : down_write+0x30/0x98\n[67841.007546] lr : start_creating.part.0+0x60/0x198\n[67841.012495] sp : ffff8000b979ba20\n[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40\n[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8\n[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18\n[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020\n[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff\n[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18\n[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18\n[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9\n[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001\n[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0\n[67841.089759] Call trace:\n[67841.092456] down_write+0x30/0x98\n[67841.096017] start_creating.part.0+0x60/0x198\n[67841.100613] debugfs_create_dir+0x48/0x1f8\n[67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]\n[67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]\n[67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]\n[67841.125115] full_proxy_write+0x68/0xc8\n[67841.129175] vfs_write+0xd8/0x3f0\n[67841.132708] ksys_write+0x70/0x108\n[67841.136317] __arm64_sys_write+0x24/0x38\n[67841.140440] invoke_syscall+0x50/0x128\n[67841.144385] el0_svc_common.constprop.0+0xc8/0xf0\n[67841.149273] do_el0_svc+0x24/0x38\n[67841.152773] el0_svc+0x38/0xd8\n[67841.156009] el0t_64_sync_handler+0xc0/0xc8\n[67841.160361] el0t_64_sync+0x1a4/0x1a8\n[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)\n[67841.170443] ---[ end trace 0000000000000000 ]---\n\nTo fix this issue, create all directories and files during debugfs\ninitialization. In this way, the driver only needs to allocate memory\nspace to save information each time the user triggers dumping.(CVE-2024-56588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkcsan: Turn report_filterlist_lock into a raw_spinlock\n\nRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see\nsplats like:\n\n| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n| preempt_count: 10002, expected: 0\n| RCU nest depth: 0, expected: 0\n| no locks held by swapper/1/0.\n| irq event stamp: 156674\n| hardirqs last enabled at (156673): [\u0026lt;ffffffff81130bd9\u0026gt;] do_idle+0x1f9/0x240\n| hardirqs last disabled at (156674): [\u0026lt;ffffffff82254f84\u0026gt;] sysvec_apic_timer_interrupt+0x14/0xc0\n| softirqs last enabled at (0): [\u0026lt;ffffffff81099f47\u0026gt;] copy_process+0xfc7/0x4b60\n| softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n| Preemption disabled at:\n| [\u0026lt;ffffffff814a3e2a\u0026gt;] paint_ptr+0x2a/0x90\n| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3\n| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014\n| Call Trace:\n| \u0026lt;IRQ\u0026gt;\n| dump_stack_lvl+0x7e/0xc0\n| dump_stack+0x1d/0x30\n| __might_resched+0x1a2/0x270\n| rt_spin_lock+0x68/0x170\n| kcsan_skip_report_debugfs+0x43/0xe0\n| print_report+0xb5/0x590\n| kcsan_report_known_origin+0x1b1/0x1d0\n| kcsan_setup_watchpoint+0x348/0x650\n| __tsan_unaligned_write1+0x16d/0x1d0\n| hrtimer_interrupt+0x3d6/0x430\n| __sysvec_apic_timer_interrupt+0xe8/0x3a0\n| sysvec_apic_timer_interrupt+0x97/0xc0\n| \u0026lt;/IRQ\u0026gt;\n\nOn a detected data race, KCSAN\u0026apos;s reporting logic checks if it should\nfilter the report. That list is protected by the report_filterlist_lock\n*non-raw* spinlock which may sleep on RT kernels.\n\nSince KCSAN may report data races in any context, convert it to a\nraw_spinlock.\n\nThis requires being careful about when to allocate memory for the filter\nlist itself which can be done via KCSAN\u0026apos;s debugfs interface. Concurrent\nmodification of the filter list via debugfs should be rare: the chosen\nstrategy is to optimistically pre-allocate memory before the critical\nsection and discard if unused.(CVE-2024-56610)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM\n\nWe currently assume that there is at least one VMA in a MM, which isn\u0026apos;t\ntrue.\n\nSo we might end up having find_vma() return NULL, to then de-reference\nNULL. So properly handle find_vma() returning NULL.\n\nThis fixes the report:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nRIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]\nRIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194\nCode: ...\nRSP: 0018:ffffc9000375fd08 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000\nRDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044\nRBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1\nR10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003\nR13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8\nFS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709\n __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]\n __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]\n __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[akpm@linux-foundation.org: add unlikely()](CVE-2024-56611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix use after free on unload\n\nSystem crash is observed with stack trace warning of use after\nfree. There are 2 signals to tell dpc_thread to terminate (UNLOADING\nflag and kthread_stop).\n\nOn setting the UNLOADING flag when dpc_thread happens to run at the time\nand sees the flag, this causes dpc_thread to exit and clean up\nitself. When kthread_stop is called for final cleanup, this causes use\nafter free.\n\nRemove UNLOADING signal to terminate dpc_thread. Use the kthread_stop\nas the main signal to exit dpc_thread.\n\n[596663.812935] kernel BUG at mm/slub.c:294!\n[596663.812950] invalid opcode: 0000 [#1] SMP PTI\n[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1\n[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012\n[596663.812974] RIP: 0010:__slab_free+0x17d/0x360\n\n...\n[596663.813008] Call Trace:\n[596663.813022] ? __dentry_kill+0x121/0x170\n[596663.813030] ? _cond_resched+0x15/0x30\n[596663.813034] ? _cond_resched+0x15/0x30\n[596663.813039] ? wait_for_completion+0x35/0x190\n[596663.813048] ? try_to_wake_up+0x63/0x540\n[596663.813055] free_task+0x5a/0x60\n[596663.813061] kthread_stop+0xf3/0x100\n[596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx](CVE-2024-56623)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport\n\nSince transport-\u0026gt;sock has been set to NULL during reset transport,\nXPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the\nxs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()\nto dereference the transport-\u0026gt;sock that has been set to NULL.(CVE-2024-56688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nionic: Fix netdev notifier unregister on failure\n\nIf register_netdev() fails, then the driver leaks the netdev notifier.\nFix this by calling ionic_lif_unregister() on register_netdev()\nfailure. This will also call ionic_lif_unregister_phc() if it has\nalready been registered.(CVE-2024-56715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info-\u0026gt;screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.(CVE-2024-56746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix slab-use-after-free due to dangling pointer dqi_priv\n\nWhen mounting ocfs2 and then remounting it as read-only, a\nslab-use-after-free occurs after the user uses a syscall to\nquota_getnextquota. Specifically, sb_dqinfo(sb, type)-\u0026gt;dqi_priv is the\ndangling pointer.\n\nDuring the remounting process, the pointer dqi_priv is freed but is never\nset as null leaving it to be accessed. Additionally, the read-only option\nfor remounting sets the DQUOT_SUSPENDED flag instead of setting the\nDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the\nnext quota, the function ocfs2_get_next_id is called and only checks the\nquota usage flags and not the quota suspended flags.\n\nTo fix this, I set dqi_priv to null when it is freed after remounting with\nread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.\n\n[akpm@linux-foundation.org: coding-style cleanups](CVE-2024-57892)",
"id": "OESA-2025-1095",
"modified": "2026-08-06T11:08:11Z",
"published": "2025-02-08T11:08:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52480"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52513"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52614"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52627"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24857"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26659"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26748"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26753"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26781"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26790"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26793"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36479"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36484"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53183"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56539"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56571"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56588"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56610"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56623"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56688"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56746"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57892"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2023-52480",
"CVE-2023-52513",
"CVE-2023-52614",
"CVE-2023-52627",
"CVE-2023-52913",
"CVE-2024-24857",
"CVE-2024-24859",
"CVE-2024-26659",
"CVE-2024-26664",
"CVE-2024-26673",
"CVE-2024-26747",
"CVE-2024-26748",
"CVE-2024-26749",
"CVE-2024-26753",
"CVE-2024-26781",
"CVE-2024-26790",
"CVE-2024-26793",
"CVE-2024-26952",
"CVE-2024-27004",
"CVE-2024-36479",
"CVE-2024-36484",
"CVE-2024-37021",
"CVE-2024-40965",
"CVE-2024-50194",
"CVE-2024-50280",
"CVE-2024-53131",
"CVE-2024-53183",
"CVE-2024-53198",
"CVE-2024-53201",
"CVE-2024-56539",
"CVE-2024-56571",
"CVE-2024-56588",
"CVE-2024-56610",
"CVE-2024-56611",
"CVE-2024-56623",
"CVE-2024-56688",
"CVE-2024-56704",
"CVE-2024-56715",
"CVE-2024-56746",
"CVE-2024-57892"
]
}
OESA-2025-1096 (CVE-2023-52434)
Vulnerability from osv_openeuler – Published: 2025-02-08 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential OOBs in smb2_parse_contexts()
Validate offsets and lengths before dereferencing create contexts in smb2_parse_contexts().
This fixes following oops when accessing invalid create contexts from server:
BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e(CVE-2023-52434)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix race condition between session lookup and expire
Thread A + Thread B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | +
This patch add rwsem to fix race condition between ksmbd_session_lookup and ksmbd_expire_session.(CVE-2023-52480)
In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Fix buffer overflow in trans_stat_show
Fix buffer overflow in trans_stat_show().
Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE.
Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled.
Return -EFBIG in the case where we don't have enough space to write the full transition table.
Also document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad7091r: Allow users to configure device events
AD7091R-5 devices are supported by the ad7091r-5 driver together with the ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall bellow the thresholds of low limit registers or above the values set in high limit registers. However, to configure iio events and their thresholds, a set of callback functions must be implemented and those were not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback functions was a null pointer dereference in the kernel because the pointers to the callback functions were not set.
Implement event configuration callbacks allowing users to read/write event thresholds and enable/disable event generation.
Since the event spec structs are generic to AD7091R devices, also move those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)
In the Linux kernel, the following vulnerability has been resolved:
drm/i915: Fix potential context UAFs
gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the last thing that gem_context_register() does with the ctx pointer.
[tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)
A race condition was found in the Linux kernel's net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.
(CVE-2024-24857)
A race condition was found in the Linux kernel's net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.
(CVE-2024-24859)
In the Linux kernel, the following vulnerability has been resolved:
xhci: handle isoc Babble and Buffer Overrun events properly
xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs.
The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message.
Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion.
Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (coretemp) Fix out-of-bounds memory access
Fix a bug that pdata->cpu_map[] is set before out-of-bounds check. The problem might be triggered on systems with more than 128 cores per package.(CVE-2024-26664)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations
- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.
- Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.(CVE-2024-26673)
In the Linux kernel, the following vulnerability has been resolved:
usb: roles: fix NULL pointer issue when put module's reference
In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference.
This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations.(CVE-2024-26747)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix memory double free when handle zero packet
829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);
Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again.
Log:
[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]
Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()
... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ...
'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it.
[ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28
Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem.(CVE-2024-26749)
In the Linux kernel, the following vulnerability has been resolved:
crypto: virtio/akcipher - Fix stack overflow on memcpy
sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o(CVE-2024-26753)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix possible deadlock in subflow diag
Syzbot and Eric reported a lockdep splat in the subflow diag:
WARNING: possible circular locking dependency detected 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted
syz-executor.2/24141 is trying to acquire lock: ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137
but task is already holding lock: ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffffc9000135e488 (&h->lhash2[i].lock){+.+.}-{2:2}, at: inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&h->lhash2[i].lock){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743 inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261 __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217 inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239 rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316 rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577 ops_init+0x352/0x610 net/core/net_namespace.c:136 __register_pernet_operations net/core/net_namespace.c:1214 [inline] register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283 register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370 rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735 do_one_initcall+0x238/0x830 init/main.c:1236 do_initcall_level+0x157/0x210 init/main.c:1298 do_initcalls+0x3f/0x80 init/main.c:1314 kernel_init_freeable+0x42f/0x5d0 init/main.c:1551 kernel_init+0x1d/0x2a0 init/main.c:1441 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242
-> #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 lock_sock_fast include/net/sock.h:1723 [inline] subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28 tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline] tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137 inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345 inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061 __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263 inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371 netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405 sock_diag_rcv_msg+0xe7/0x410 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77
As noted by Eric we can break the lock dependency chain avoid dumping ---truncated---(CVE-2024-26781)
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read
There is chip (ls1028a) errata:
The SoC may hang on 16 byte unaligned read transactions by QDMA.
Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller.
Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ).
Implement this workaround.(CVE-2024-26790)
In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_newlink()
The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
[ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] _syssendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated---(CVE-2024-26793)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix potencial out-of-bounds when buffer offset is invalid
I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length.(CVE-2024-26952)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()
If ->NameOffset of smb2_create_req is smaller than Buffer offset of smb2_create_req, slab-out-of-bounds read can happen from smb2_open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2_create_req().(CVE-2024-26954)
In the Linux kernel, the following vulnerability has been resolved:
clk: Get runtime PM before walking tree during disable_unused
Doug reported [1] the following hung task:
INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20
The first thread is walking the clk tree and calling clk_pm_runtime_get() to power on devices required to read the clk hardware via struct clk_ops::is_enabled(). This thread holds the clk prepare_lock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clk_prepare(), trying to grab the prepare_lock waiting on the first thread.
This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk prepare_lock held. Actually doing that is near impossible today because the global prepare_lock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the prepare_lock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again.
Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the prepare_lock held. Let's fix this immediate problem that can be ---truncated---(CVE-2024-27004)
In the Linux kernel, the following vulnerability has been resolved:
fpga: bridge: add owner module and take its refcount
The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner.
Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge.
Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions.(CVE-2024-36479)
In the Linux kernel, the following vulnerability has been resolved:
fpga: manager: add owner module and take its refcount
The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner.
Also, update the documentation to keep it consistent with the new interface for registering an fpga manager.
Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions.(CVE-2024-37021)
In the Linux kernel, the following vulnerability has been resolved:
i2c: lpi2c: Avoid calling clk_get_rate during transfer
Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.(CVE-2024-40965)
In the Linux kernel, the following vulnerability has been resolved:
arm64: probes: Fix uprobes for big-endian kernels
The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems:
-
The kernel may may erroneously reject probing an instruction which can safely be probed.
-
The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely.
-
The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding.
The endianness mismatch isn't caught by the compiler or sparse because:
-
The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness.
-
While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning.
Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change.
At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity.
Tested with the following:
| #include <stdio.h> | #include <stdbool.h> | | #define noinline attribute((noinline)) | | static noinline void adrp_self(void) | { | void addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char argv) | { | void ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | }
.... where the adrp_self() function was compiled to:
| 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret
Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result:
| # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL
After this patch, the ADRP is correctly recognized and simulated:
| # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL(CVE-2024-50194)
In the Linux kernel, the following vulnerability has been resolved:
dm cache: fix flushing uninitialized delayed_work on cache_ctr error
An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error.
Reproduce steps:
dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"
Kernel logs:
(snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890
Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb ("dm cache: Fix UAF in destroy()")) as cache_dtr is not changed.(CVE-2024-50280)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint
Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".
This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints.
This patch (of 2):
It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled.
This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller.
Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place.
So this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)
In the Linux kernel, the following vulnerability has been resolved:
um: net: Do not use drvdata in release
The drvdata is not available in release. Let's just use container_of() to get the uml_net instance. Otherwise, removing a network device will result in a crash:
RIP: 0033:net_device_release+0x10/0x6f RSP: 00000000e20c7c40 EFLAGS: 00010206 RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0 RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028 RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70 R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000 R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6 Kernel panic - not syncing: Segfault with no mm CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1 Workqueue: events mc_work_proc Stack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010 Call Trace: [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<6002ec9c>] net_remove+0x63/0x69 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<60087d40>] ? __remove_hrtimer+0x38/0x74 [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98 [<6006b3cf>] ? dl_server_stop+0x3f/0x48 [<6006b390>] ? dl_server_stop+0x0/0x48 [<600672e8>] ? dequeue_entities+0x327/0x390 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6(CVE-2024-53183)
In the Linux kernel, the following vulnerability has been resolved:
xen: Fix the issue of resource not being properly released in xenbus_dev_probe()
This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems.
To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak.
This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.(CVE-2024-53198)
In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx->plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()
Replace one-element array with a flexible-array member in struct
mwifiex_ie_types_wildcard_ssid_params to fix the following warning
on a MT8173 Chromebook (mt8173-elm-hana):
[ 356.775250] ------------[ cut here ]------------ [ 356.784543] memcpy: detected field-spanning write (size 6) of single field "wildcard_ssid_tlv->ssid" at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1) [ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]
The "(size 6)" above is exactly the length of the SSID of the network this device was connected to. The source of the warning looks like:
ssid_len = user_scan_in->ssid_list[i].ssid_len;
[...]
memcpy(wildcard_ssid_tlv->ssid,
user_scan_in->ssid_list[i].ssid, ssid_len);
There is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this struct, but it already didn't account for the size of the one-element array, so it doesn't need to be changed.(CVE-2024-56539)
In the Linux kernel, the following vulnerability has been resolved:
media: uvcvideo: Require entities to have a non-zero unique ID
Per UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero unique ID.
Each Unit and Terminal within the video function is assigned a unique
identification number, the Unit ID (UID) or Terminal ID (TID), contained in
the bUnitID or bTerminalID field of the descriptor. The value 0x00 is
reserved for undefined ID,
So, deny allocating an entity with ID 0 or an ID that belongs to a unit that is already added to the list of entities.
This also prevents some syzkaller reproducers from triggering warnings due to a chain of entities referring to themselves. In one particular case, an Output Unit is connected to an Input Unit, both with the same ID of 1. But when looking up for the source ID of the Output Unit, that same entity is found instead of the input entity, which leads to such warnings.
In another case, a backward chain was considered finished as the source ID was 0. Later on, that entity was found, but its pads were not valid.
Here is a sample stack trace for one of those cases.
[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd [ 20.830206] usb 1-1: Using ep0 maxpacket: 8 [ 20.833501] usb 1-1: config 0 descriptor?? [ 21.038518] usb 1-1: string descriptor 0 read error: -71 [ 21.038893] usb 1-1: Found UVC 0.00 device <unnamed> (2833:0201) [ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized! [ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized! [ 21.042218] ------------[ cut here ]------------ [ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0 [ 21.043195] Modules linked in: [ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444 [ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 21.044639] Workqueue: usb_hub_wq hub_event [ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0 [ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 <0f> 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00 [ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246 [ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1 [ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290 [ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000 [ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003 [ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000 [ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0 [ 21.051136] PKRU: 55555554 [ 21.051331] Call Trace: [ 21.051480] <TASK> [ 21.051611] ? __warn+0xc4/0x210 [ 21.051861] ? media_create_pad_link+0x2c4/0x2e0 [ 21.052252] ? report_bug+0x11b/0x1a0 [ 21.052540] ? trace_hardirqs_on+0x31/0x40 [ 21.052901] ? handle_bug+0x3d/0x70 [ 21.053197] ? exc_invalid_op+0x1a/0x50 [ 21.053511] ? asm_exc_invalid_op+0x1a/0x20 [ 21.053924] ? media_create_pad_link+0x91/0x2e0 [ 21.054364] ? media_create_pad_link+0x2c4/0x2e0 [ 21.054834] ? media_create_pad_link+0x91/0x2e0 [ 21.055131] ? _raw_spin_unlock+0x1e/0x40 [ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210 [ 21.055837] uvc_mc_register_entities+0x358/0x400 [ 21.056144] uvc_register_chains+0x1fd/0x290 [ 21.056413] uvc_probe+0x380e/0x3dc0 [ 21.056676] ? __lock_acquire+0x5aa/0x26e0 [ 21.056946] ? find_held_lock+0x33/0xa0 [ 21.057196] ? kernfs_activate+0x70/0x80 [ 21.057533] ? usb_match_dy ---truncated---(CVE-2024-56571)
In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Create all dump files during debugfs initialization
For the current debugfs of hisi_sas, after user triggers dump, the driver allocate memory space to save the register information and create debugfs files to display the saved information. In this process, the debugfs files created after each dump.
Therefore, when the dump is triggered while the driver is unbind, the following hang occurs:
[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [67840.862947] Mem abort info: [67840.865855] ESR = 0x0000000096000004 [67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits [67840.875125] SET = 0, FnV = 0 [67840.878291] EA = 0, S1PTW = 0 [67840.881545] FSC = 0x04: level 0 translation fault [67840.886528] Data abort info: [67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000 [67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000 [67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [67841.003628] pc : down_write+0x30/0x98 [67841.007546] lr : start_creating.part.0+0x60/0x198 [67841.012495] sp : ffff8000b979ba20 [67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40 [67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8 [67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18 [67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020 [67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff [67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18 [67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18 [67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9 [67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001 [67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0 [67841.089759] Call trace: [67841.092456] down_write+0x30/0x98 [67841.096017] start_creating.part.0+0x60/0x198 [67841.100613] debugfs_create_dir+0x48/0x1f8 [67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw] [67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw] [67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw] [67841.125115] full_proxy_write+0x68/0xc8 [67841.129175] vfs_write+0xd8/0x3f0 [67841.132708] ksys_write+0x70/0x108 [67841.136317] __arm64_sys_write+0x24/0x38 [67841.140440] invoke_syscall+0x50/0x128 [67841.144385] el0_svc_common.constprop.0+0xc8/0xf0 [67841.149273] do_el0_svc+0x24/0x38 [67841.152773] el0_svc+0x38/0xd8 [67841.156009] el0t_64_sync_handler+0xc0/0xc8 [67841.160361] el0t_64_sync+0x1a4/0x1a8 [67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05) [67841.170443] ---[ end trace 0000000000000000 ]---
To fix this issue, create all directories and files during debugfs initialization. In this way, the driver only needs to allocate memory space to save information each time the user triggers dumping.(CVE-2024-56588)
In the Linux kernel, the following vulnerability has been resolved:
kcsan: Turn report_filterlist_lock into a raw_spinlock
Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see splats like:
| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 | preempt_count: 10002, expected: 0 | RCU nest depth: 0, expected: 0 | no locks held by swapper/1/0. | irq event stamp: 156674 | hardirqs last enabled at (156673): [<ffffffff81130bd9>] do_idle+0x1f9/0x240 | hardirqs last disabled at (156674): [<ffffffff82254f84>] sysvec_apic_timer_interrupt+0x14/0xc0 | softirqs last enabled at (0): [<ffffffff81099f47>] copy_process+0xfc7/0x4b60 | softirqs last disabled at (0): [<0000000000000000>] 0x0 | Preemption disabled at: | [<ffffffff814a3e2a>] paint_ptr+0x2a/0x90 | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 | Call Trace: | <IRQ> | dump_stack_lvl+0x7e/0xc0 | dump_stack+0x1d/0x30 | __might_resched+0x1a2/0x270 | rt_spin_lock+0x68/0x170 | kcsan_skip_report_debugfs+0x43/0xe0 | print_report+0xb5/0x590 | kcsan_report_known_origin+0x1b1/0x1d0 | kcsan_setup_watchpoint+0x348/0x650 | __tsan_unaligned_write1+0x16d/0x1d0 | hrtimer_interrupt+0x3d6/0x430 | __sysvec_apic_timer_interrupt+0xe8/0x3a0 | sysvec_apic_timer_interrupt+0x97/0xc0 | </IRQ>
On a detected data race, KCSAN's reporting logic checks if it should filter the report. That list is protected by the report_filterlist_lock non-raw spinlock which may sleep on RT kernels.
Since KCSAN may report data races in any context, convert it to a raw_spinlock.
This requires being careful about when to allocate memory for the filter list itself which can be done via KCSAN's debugfs interface. Concurrent modification of the filter list via debugfs should be rare: the chosen strategy is to optimistically pre-allocate memory before the critical section and discard if unused.(CVE-2024-56610)
In the Linux kernel, the following vulnerability has been resolved:
mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM
We currently assume that there is at least one VMA in a MM, which isn't true.
So we might end up having find_vma() return NULL, to then de-reference NULL. So properly handle find_vma() returning NULL.
This fixes the report:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline] RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194 Code: ... RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000 RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044 RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1 R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003 R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8 FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
akpm@linux-foundation.org: add unlikely()
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix use after free on unload
System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpc_thread to terminate (UNLOADING flag and kthread_stop).
On setting the UNLOADING flag when dpc_thread happens to run at the time and sees the flag, this causes dpc_thread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free.
Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop as the main signal to exit dpc_thread.
[596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360
... [596663.813008] Call Trace: [596663.813022] ? __dentry_kill+0x121/0x170 [596663.813030] ? _cond_resched+0x15/0x30 [596663.813034] ? _cond_resched+0x15/0x30 [596663.813039] ? wait_for_completion+0x35/0x190 [596663.813048] ? try_to_wake_up+0x63/0x540 [596663.813055] free_task+0x5a/0x60 [596663.813061] kthread_stop+0xf3/0x100 [596663.813103] qla2x00_remove_one+0x284/0x440 qla2xxx
In the Linux kernel, the following vulnerability has been resolved:
sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport
Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL.(CVE-2024-56688)
In the Linux kernel, the following vulnerability has been resolved:
9p/xen: fix release of IRQ
Kernel logs indicate an IRQ was double-freed.
Pass correct device ID during IRQ release.
Dominique: remove confusing variable reset to 0
In the Linux kernel, the following vulnerability has been resolved:
ionic: Fix netdev notifier unregister on failure
If register_netdev() fails, then the driver leaks the netdev notifier. Fix this by calling ionic_lif_unregister() on register_netdev() failure. This will also call ionic_lif_unregister_phc() if it has already been registered.(CVE-2024-56715)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()
When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead.(CVE-2024-56746)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv
When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is the dangling pointer.
During the remounting process, the pointer dqi_priv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOT_SUSPENDED flag instead of setting the DQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2_get_next_id is called and only checks the quota usage flags and not the quota suspended flags.
To fix this, I set dqi_priv to null when it is freed after remounting with read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-248.0.0.147.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-248.0.0.147.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-248.0.0.147.oe2203sp4"
}
],
"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:\n\nsmb: client: fix potential OOBs in smb2_parse_contexts()\n\nValidate offsets and lengths before dereferencing create contexts in\nsmb2_parse_contexts().\n\nThis fixes following oops when accessing invalid create contexts from\nserver:\n\n BUG: unable to handle page fault for address: ffff8881178d8cc3\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 4a01067 P4D 4a01067 PUD 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\n rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\n RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]\n Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00\n 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 \u0026lt;0f\u0026gt; b7\n 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00\n RSP: 0018:ffffc900007939e0 EFLAGS: 00010216\n RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90\n RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000\n RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000\n R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000\n R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22\n FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)\n knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x181/0x480\n ? search_module_extables+0x19/0x60\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? exc_page_fault+0x1b6/0x1c0\n ? asm_exc_page_fault+0x26/0x30\n ? smb2_parse_contexts+0xa0/0x3a0 [cifs]\n SMB2_open+0x38d/0x5f0 [cifs]\n ? smb2_is_path_accessible+0x138/0x260 [cifs]\n smb2_is_path_accessible+0x138/0x260 [cifs]\n cifs_is_path_remote+0x8d/0x230 [cifs]\n cifs_mount+0x7e/0x350 [cifs]\n cifs_smb3_do_mount+0x128/0x780 [cifs]\n smb3_get_tree+0xd9/0x290 [cifs]\n vfs_get_tree+0x2c/0x100\n ? capable+0x37/0x70\n path_mount+0x2d7/0xb80\n ? srso_alias_return_thunk+0x5/0xfbef5\n ? _raw_spin_unlock_irqrestore+0x44/0x60\n __x64_sys_mount+0x11a/0x150\n do_syscall_64+0x47/0xf0\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n RIP: 0033:0x7f8737657b1e(CVE-2023-52434)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix race condition between session lookup and expire\n\n Thread A + Thread B\n ksmbd_session_lookup | smb2_sess_setup\n sess = xa_load |\n |\n | xa_erase(\u0026amp;conn-\u0026gt;sessions, sess-\u0026gt;id);\n |\n | ksmbd_session_destroy(sess) --\u0026gt; kfree(sess)\n |\n // UAF! |\n sess-\u0026gt;last_active = jiffies |\n +\n\nThis patch add rwsem to fix race condition between ksmbd_session_lookup\nand ksmbd_expire_session.(CVE-2023-52480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM / devfreq: Fix buffer overflow in trans_stat_show\n\nFix buffer overflow in trans_stat_show().\n\nConvert simple snprintf to the more secure scnprintf with size of\nPAGE_SIZE.\n\nAdd condition checking if we are exceeding PAGE_SIZE and exit early from\nloop. Also add at the end a warning that we exceeded PAGE_SIZE and that\nstats is disabled.\n\nReturn -EFBIG in the case where we don\u0026apos;t have enough space to write the\nfull transition table.\n\nAlso document in the ABI that this function can return -EFBIG error.(CVE-2023-52614)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: ad7091r: Allow users to configure device events\n\nAD7091R-5 devices are supported by the ad7091r-5 driver together with\nthe ad7091r-base driver. Those drivers declared iio events for notifying\nuser space when ADC readings fall bellow the thresholds of low limit\nregisters or above the values set in high limit registers.\nHowever, to configure iio events and their thresholds, a set of callback\nfunctions must be implemented and those were not present until now.\nThe consequence of trying to configure ad7091r-5 events without the\nproper callback functions was a null pointer dereference in the kernel\nbecause the pointers to the callback functions were not set.\n\nImplement event configuration callbacks allowing users to read/write\nevent thresholds and enable/disable event generation.\n\nSince the event spec structs are generic to AD7091R devices, also move\nthose from the ad7091r-5 driver the base driver so they can be reused\nwhen support for ad7091r-2/-4/-8 be added.(CVE-2023-52627)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix potential context UAFs\n\ngem_context_register() makes the context visible to userspace, and which\npoint a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl.\nSo we need to ensure that nothing uses the ctx ptr after this. And we\nneed to ensure that adding the ctx to the xarray is the *last* thing\nthat gem_context_register() does with the ctx pointer.\n\n[tursulin: Stable and fixes tags add/tidy.]\n(cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c)(CVE-2023-52913)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth device driver in conn_info_{min,max}_age_set() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.\n\n\n\n\n(CVE-2024-24857)\n\nA race condition was found in the Linux kernel\u0026apos;s net/bluetooth in sniff_{min,max}_interval_set() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.\n\n\n\n\n\n\n\n(CVE-2024-24859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxhci: handle isoc Babble and Buffer Overrun events properly\n\nxHCI 4.9 explicitly forbids assuming that the xHC has released its\nownership of a multi-TRB TD when it reports an error on one of the\nearly TRBs. Yet the driver makes such assumption and releases the TD,\nallowing the remaining TRBs to be freed or overwritten by new TDs.\n\nThe xHC should also report completion of the final TRB due to its IOC\nflag being set by us, regardless of prior errors. This event cannot\nbe recognized if the TD has already been freed earlier, resulting in\n\u0026quot;Transfer event TRB DMA ptr not part of current TD\u0026quot; error message.\n\nFix this by reusing the logic for processing isoc Transaction Errors.\nThis also handles hosts which fail to report the final completion.\n\nFix transfer length reporting on Babble errors. They may be caused by\ndevice malfunction, no guarantee that the buffer has been filled.(CVE-2024-26659)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (coretemp) Fix out-of-bounds memory access\n\nFix a bug that pdata-\u0026gt;cpu_map[] is set before out-of-bounds check.\nThe problem might be triggered on systems with more than 128 cores per\npackage.(CVE-2024-26664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations\n\n- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.\n- Disallow layer 4 protocol with no ports, since destination port is a\n mandatory attribute for this object.(CVE-2024-26673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: roles: fix NULL pointer issue when put module\u0026apos;s reference\n\nIn current design, usb role class driver will get usb_role_switch parent\u0026apos;s\nmodule reference after the user get usb_role_switch device and put the\nreference after the user put the usb_role_switch device. However, the\nparent device of usb_role_switch may be removed before the user put the\nusb_role_switch. If so, then, NULL pointer issue will be met when the user\nput the parent module\u0026apos;s reference.\n\nThis will save the module pointer in structure of usb_role_switch. Then,\nwe don\u0026apos;t need to find module by iterating long relations.(CVE-2024-26747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix memory double free when handle zero packet\n\n829 if (request-\u0026gt;complete) {\n830 spin_unlock(\u0026amp;priv_dev-\u0026gt;lock);\n831 usb_gadget_giveback_request(\u0026amp;priv_ep-\u0026gt;endpoint,\n832 request);\n833 spin_lock(\u0026amp;priv_dev-\u0026gt;lock);\n834 }\n835\n836 if (request-\u0026gt;buf == priv_dev-\u0026gt;zlp_buf)\n837 cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, request);\n\nDriver append an additional zero packet request when queue a packet, which\nlength mod max packet size is 0. When transfer complete, run to line 831,\nusb_gadget_giveback_request() will free this requestion. 836 condition is\ntrue, so cdns3_gadget_ep_free_request() free this request again.\n\nLog:\n\n[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.140696][ T150]\n[ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):\n[ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3]\n[ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]\n\nAdd check at line 829, skip call usb_gadget_giveback_request() if it is\nadditional zero length packet request. Needn\u0026apos;t call\nusb_gadget_giveback_request() because it is allocated in this driver.(CVE-2024-26748)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()\n\n ...\n cdns3_gadget_ep_free_request(\u0026amp;priv_ep-\u0026gt;endpoint, \u0026amp;priv_req-\u0026gt;request);\n list_del_init(\u0026amp;priv_req-\u0026gt;list);\n ...\n\n\u0026apos;priv_req\u0026apos; actually free at cdns3_gadget_ep_free_request(). But\nlist_del_init() use priv_req-\u0026gt;list after it.\n\n[ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4\n[ 1542.642868][ T534]\n[ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):\n[ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4\n[ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3]\n[ 1542.671571][ T534] usb_ep_disable+0x44/0xe4\n[ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8\n[ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368\n[ 1542.685478][ T534] ffs_func_disable+0x18/0x28\n\nMove list_del_init() before cdns3_gadget_ep_free_request() to resolve this\nproblem.(CVE-2024-26749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: virtio/akcipher - Fix stack overflow on memcpy\n\nsizeof(struct virtio_crypto_akcipher_session_para) is less than\nsizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from\nstack variable leads stack overflow. Clang reports this issue by\ncommands:\nmake -j CC=clang-14 mrproper \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build CC=clang-14 allmodconfig \u0026gt;/dev/null 2\u0026gt;\u0026amp;1\nmake -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/\n virtio_crypto_akcipher_algs.o(CVE-2024-26753)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix possible deadlock in subflow diag\n\nSyzbot and Eric reported a lockdep splat in the subflow diag:\n\n WARNING: possible circular locking dependency detected\n 6.8.0-rc4-syzkaller-00212-g40b9385dd8e6 #0 Not tainted\n\n syz-executor.2/24141 is trying to acquire lock:\n ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n ffff888045870130 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at:\n tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n\n but task is already holding lock:\n ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at: spin_lock\n include/linux/spinlock.h:351 [inline]\n ffffc9000135e488 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}, at:\n inet_diag_dump_icsk+0x39f/0x1f80 net/ipv4/inet_diag.c:1038\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -\u0026gt; #1 (\u0026amp;h-\u0026gt;lhash2[i].lock){+.+.}-{2:2}:\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]\n _raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:154\n spin_lock include/linux/spinlock.h:351 [inline]\n __inet_hash+0x335/0xbe0 net/ipv4/inet_hashtables.c:743\n inet_csk_listen_start+0x23a/0x320 net/ipv4/inet_connection_sock.c:1261\n __inet_listen_sk+0x2a2/0x770 net/ipv4/af_inet.c:217\n inet_listen+0xa3/0x110 net/ipv4/af_inet.c:239\n rds_tcp_listen_init+0x3fd/0x5a0 net/rds/tcp_listen.c:316\n rds_tcp_init_net+0x141/0x320 net/rds/tcp.c:577\n ops_init+0x352/0x610 net/core/net_namespace.c:136\n __register_pernet_operations net/core/net_namespace.c:1214 [inline]\n register_pernet_operations+0x2cb/0x660 net/core/net_namespace.c:1283\n register_pernet_device+0x33/0x80 net/core/net_namespace.c:1370\n rds_tcp_init+0x62/0xd0 net/rds/tcp.c:735\n do_one_initcall+0x238/0x830 init/main.c:1236\n do_initcall_level+0x157/0x210 init/main.c:1298\n do_initcalls+0x3f/0x80 init/main.c:1314\n kernel_init_freeable+0x42f/0x5d0 init/main.c:1551\n kernel_init+0x1d/0x2a0 init/main.c:1441\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242\n\n -\u0026gt; #0 (k-sk_lock-AF_INET6){+.+.}-{0:0}:\n check_prev_add kernel/locking/lockdep.c:3134 [inline]\n check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n validate_chain+0x18ca/0x58e0 kernel/locking/lockdep.c:3869\n __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137\n lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754\n lock_sock_fast include/net/sock.h:1723 [inline]\n subflow_get_info+0x166/0xd20 net/mptcp/diag.c:28\n tcp_diag_put_ulp net/ipv4/tcp_diag.c:100 [inline]\n tcp_diag_get_aux+0x738/0x830 net/ipv4/tcp_diag.c:137\n inet_sk_diag_fill+0x10ed/0x1e00 net/ipv4/inet_diag.c:345\n inet_diag_dump_icsk+0x55b/0x1f80 net/ipv4/inet_diag.c:1061\n __inet_diag_dump+0x211/0x3a0 net/ipv4/inet_diag.c:1263\n inet_diag_dump_compat+0x1c1/0x2d0 net/ipv4/inet_diag.c:1371\n netlink_dump+0x59b/0xc80 net/netlink/af_netlink.c:2264\n __netlink_dump_start+0x5df/0x790 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:338 [inline]\n inet_diag_rcv_msg_compat+0x209/0x4c0 net/ipv4/inet_diag.c:1405\n sock_diag_rcv_msg+0xe7/0x410\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:745\n ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n ___sys_sendmsg net/socket.c:2638 [inline]\n __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\n\nAs noted by Eric we can break the lock dependency chain avoid\ndumping \n---truncated---(CVE-2024-26781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read\n\nThere is chip (ls1028a) errata:\n\nThe SoC may hang on 16 byte unaligned read transactions by QDMA.\n\nUnaligned read transactions initiated by QDMA may stall in the NOC\n(Network On-Chip), causing a deadlock condition. Stalled transactions will\ntrigger completion timeouts in PCIe controller.\n\nWorkaround:\nEnable prefetch by setting the source descriptor prefetchable bit\n( SD[PF] = 1 ).\n\nImplement this workaround.(CVE-2024-26790)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngtp: fix use-after-free and null-ptr-deref in gtp_newlink()\n\nThe gtp_link_ops operations structure for the subsystem must be\nregistered after registering the gtp_net_ops pernet operations structure.\n\nSyzkaller hit \u0026apos;general protection fault in gtp_genl_dump_pdp\u0026apos; bug:\n\n[ 1010.702740] gtp: GTP module unloaded\n[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI\n[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\n[ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1\n[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014\n[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00\n[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203\n[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000\n[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282\n[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000\n[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80\n[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400\n[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000\n[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0\n[ 1010.715968] PKRU: 55555554\n[ 1010.715972] Call Trace:\n[ 1010.715985] ? __die_body.cold+0x1a/0x1f\n[ 1010.715995] ? die_addr+0x43/0x70\n[ 1010.716002] ? exc_general_protection+0x199/0x2f0\n[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30\n[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp]\n[ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp]\n[ 1010.716042] __rtnl_newlink+0x1063/0x1700\n[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0\n[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0\n[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0\n[ 1010.716076] ? __kernel_text_address+0x56/0xa0\n[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0\n[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30\n[ 1010.716098] ? arch_stack_walk+0x9e/0xf0\n[ 1010.716106] ? stack_trace_save+0x91/0xd0\n[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170\n[ 1010.716121] ? __lock_acquire+0x15c5/0x5380\n[ 1010.716139] ? mark_held_locks+0x9e/0xe0\n[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0\n[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700\n[ 1010.716160] rtnl_newlink+0x69/0xa0\n[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50\n[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716179] ? lock_acquire+0x1fe/0x560\n[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50\n[ 1010.716196] netlink_rcv_skb+0x14d/0x440\n[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0\n[ 1010.716208] ? netlink_ack+0xab0/0xab0\n[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50\n[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50\n[ 1010.716226] ? __virt_addr_valid+0x30b/0x590\n[ 1010.716233] netlink_unicast+0x54b/0x800\n[ 1010.716240] ? netlink_attachskb+0x870/0x870\n[ 1010.716248] ? __check_object_size+0x2de/0x3b0\n[ 1010.716254] netlink_sendmsg+0x938/0xe40\n[ 1010.716261] ? netlink_unicast+0x800/0x800\n[ 1010.716269] ? __import_iovec+0x292/0x510\n[ 1010.716276] ? netlink_unicast+0x800/0x800\n[ 1010.716284] __sock_sendmsg+0x159/0x190\n[ 1010.716290] ____sys_sendmsg+0x712/0x880\n[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0\n[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270\n[ 1010.716309] ? lock_acquire+0x1fe/0x560\n[ 1010.716315] ? drain_array_locked+0x90/0x90\n[ 1010.716324] ___sys_sendmsg+0xf8/0x170\n[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170\n[ 1010.716337] ? lockdep_init_map\n---truncated---(CVE-2024-26793)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix potencial out-of-bounds when buffer offset is invalid\n\nI found potencial out-of-bounds when buffer offset fields of a few requests\nis invalid. This patch set the minimum value of buffer offset field to\n-\u0026gt;Buffer offset to validate buffer length.(CVE-2024-26952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()\n\nIf -\u0026gt;NameOffset of smb2_create_req is smaller than Buffer offset of\nsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.\nThis patch set the minimum value of the name offset to the buffer offset\nto validate name length of smb2_create_req().(CVE-2024-26954)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: Get runtime PM before walking tree during disable_unused\n\nDoug reported [1] the following hung task:\n\n INFO: task swapper/0:1 blocked for more than 122 seconds.\n Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008\n Call trace:\n __switch_to+0xf4/0x1f4\n __schedule+0x418/0xb80\n schedule+0x5c/0x10c\n rpm_resume+0xe0/0x52c\n rpm_resume+0x178/0x52c\n __pm_runtime_resume+0x58/0x98\n clk_pm_runtime_get+0x30/0xb0\n clk_disable_unused_subtree+0x58/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused_subtree+0x38/0x208\n clk_disable_unused+0x4c/0xe4\n do_one_initcall+0xcc/0x2d8\n do_initcall_level+0xa4/0x148\n do_initcalls+0x5c/0x9c\n do_basic_setup+0x24/0x30\n kernel_init_freeable+0xec/0x164\n kernel_init+0x28/0x120\n ret_from_fork+0x10/0x20\n INFO: task kworker/u16:0:9 blocked for more than 122 seconds.\n Not tainted 5.15.149-21875-gf795ebc40eb8 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n __switch_to+0xf4/0x1f4\n __schedule+0x418/0xb80\n schedule+0x5c/0x10c\n schedule_preempt_disabled+0x2c/0x48\n __mutex_lock+0x238/0x488\n __mutex_lock_slowpath+0x1c/0x28\n mutex_lock+0x50/0x74\n clk_prepare_lock+0x7c/0x9c\n clk_core_prepare_lock+0x20/0x44\n clk_prepare+0x24/0x30\n clk_bulk_prepare+0x40/0xb0\n mdss_runtime_resume+0x54/0x1c8\n pm_generic_runtime_resume+0x30/0x44\n __genpd_runtime_resume+0x68/0x7c\n genpd_runtime_resume+0x108/0x1f4\n __rpm_callback+0x84/0x144\n rpm_callback+0x30/0x88\n rpm_resume+0x1f4/0x52c\n rpm_resume+0x178/0x52c\n __pm_runtime_resume+0x58/0x98\n __device_attach+0xe0/0x170\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x3c/0x9c\n device_add+0x644/0x814\n mipi_dsi_device_register_full+0xe4/0x170\n devm_mipi_dsi_device_register_full+0x28/0x70\n ti_sn_bridge_probe+0x1dc/0x2c0\n auxiliary_bus_probe+0x4c/0x94\n really_probe+0xcc/0x2c8\n __driver_probe_device+0xa8/0x130\n driver_probe_device+0x48/0x110\n __device_attach_driver+0xa4/0xcc\n bus_for_each_drv+0x8c/0xd8\n __device_attach+0xf8/0x170\n device_initial_probe+0x1c/0x28\n bus_probe_device+0x3c/0x9c\n deferred_probe_work_func+0x9c/0xd8\n process_one_work+0x148/0x518\n worker_thread+0x138/0x350\n kthread+0x138/0x1e0\n ret_from_fork+0x10/0x20\n\nThe first thread is walking the clk tree and calling\nclk_pm_runtime_get() to power on devices required to read the clk\nhardware via struct clk_ops::is_enabled(). This thread holds the clk\nprepare_lock, and is trying to runtime PM resume a device, when it finds\nthat the device is in the process of resuming so the thread schedule()s\naway waiting for the device to finish resuming before continuing. The\nsecond thread is runtime PM resuming the same device, but the runtime\nresume callback is calling clk_prepare(), trying to grab the\nprepare_lock waiting on the first thread.\n\nThis is a classic ABBA deadlock. To properly fix the deadlock, we must\nnever runtime PM resume or suspend a device with the clk prepare_lock\nheld. Actually doing that is near impossible today because the global\nprepare_lock would have to be dropped in the middle of the tree, the\ndevice runtime PM resumed/suspended, and then the prepare_lock grabbed\nagain to ensure consistency of the clk tree topology. If anything\nchanges with the clk tree in the meantime, we\u0026apos;ve lost and will need to\nstart the operation all over again.\n\nLuckily, most of the time we\u0026apos;re simply incrementing or decrementing the\nruntime PM count on an active device, so we don\u0026apos;t have the chance to\nschedule away with the prepare_lock held. Let\u0026apos;s fix this immediate\nproblem that can be\n---truncated---(CVE-2024-27004)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: bridge: add owner module and take its refcount\n\nThe current implementation of the fpga bridge assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the bridge if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_bridge\nstruct and use it to take the module\u0026apos;s refcount. Modify the function for\nregistering a bridge to take an additional owner module parameter and\nrename it to avoid conflicts. Use the old function name for a helper macro\nthat automatically sets the module that registers the bridge as the owner.\nThis ensures compatibility with existing low-level control modules and\nreduces the chances of registering a bridge without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga bridge.\n\nOther changes: opportunistically move put_device() from __fpga_bridge_get()\nto fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since\nthe bridge device is taken in these functions.(CVE-2024-36479)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfpga: manager: add owner module and take its refcount\n\nThe current implementation of the fpga manager assumes that the low-level\nmodule registers a driver for the parent device and uses its owner pointer\nto take the module\u0026apos;s refcount. This approach is problematic since it can\nlead to a null pointer dereference while attempting to get the manager if\nthe parent device does not have a driver.\n\nTo address this problem, add a module owner pointer to the fpga_manager\nstruct and use it to take the module\u0026apos;s refcount. Modify the functions for\nregistering the manager to take an additional owner module parameter and\nrename them to avoid conflicts. Use the old function names for helper\nmacros that automatically set the module that registers the manager as the\nowner. This ensures compatibility with existing low-level control modules\nand reduces the chances of registering a manager without setting the owner.\n\nAlso, update the documentation to keep it consistent with the new interface\nfor registering an fpga manager.\n\nOther changes: opportunistically move put_device() from __fpga_mgr_get() to\nfpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the\nmanager device is taken in these functions.(CVE-2024-37021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: lpi2c: Avoid calling clk_get_rate during transfer\n\nInstead of repeatedly calling clk_get_rate for each transfer, lock\nthe clock rate and cache the value.\nA deadlock has been observed while adding tlv320aic32x4 audio codec to\nthe system. When this clock provider adds its clock, the clk mutex is\nlocked already, it needs to access i2c, which in return needs the mutex\nfor clk_get_rate as well.(CVE-2024-40965)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Fix uprobes for big-endian kernels\n\nThe arm64 uprobes code is broken for big-endian kernels as it doesn\u0026apos;t\nconvert the in-memory instruction encoding (which is always\nlittle-endian) into the kernel\u0026apos;s native endianness before analyzing and\nsimulating instructions. This may result in a few distinct problems:\n\n* The kernel may may erroneously reject probing an instruction which can\n safely be probed.\n\n* The kernel may erroneously erroneously permit stepping an\n instruction out-of-line when that instruction cannot be stepped\n out-of-line safely.\n\n* The kernel may erroneously simulate instruction incorrectly dur to\n interpretting the byte-swapped encoding.\n\nThe endianness mismatch isn\u0026apos;t caught by the compiler or sparse because:\n\n* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so\n the compiler and sparse have no idea these contain a little-endian\n 32-bit value. The core uprobes code populates these with a memcpy()\n which similarly does not handle endianness.\n\n* While the uprobe_opcode_t type is an alias for __le32, both\n arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]\n to the similarly-named probe_opcode_t, which is an alias for u32.\n Hence there is no endianness conversion warning.\n\nFix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and\nadding the appropriate __le32_to_cpu() conversions prior to consuming\nthe instruction encoding. The core uprobes copies these fields as opaque\nranges of bytes, and so is unaffected by this change.\n\nAt the same time, remove MAX_UINSN_BYTES and consistently use\nAARCH64_INSN_SIZE for clarity.\n\nTested with the following:\n\n| #include \u0026lt;stdio.h\u0026gt;\n| #include \u0026lt;stdbool.h\u0026gt;\n|\n| #define noinline __attribute__((noinline))\n|\n| static noinline void *adrp_self(void)\n| {\n| void *addr;\n|\n| asm volatile(\n| \u0026quot; adrp %x0, adrp_self\\n\u0026quot;\n| \u0026quot; add %x0, %x0, :lo12:adrp_self\\n\u0026quot;\n| : \u0026quot;=r\u0026quot; (addr));\n| }\n|\n|\n| int main(int argc, char *argv)\n| {\n| void *ptr = adrp_self();\n| bool equal = (ptr == adrp_self);\n|\n| printf(\u0026quot;adrp_self =\u0026gt; %p\\n\u0026quot;\n| \u0026quot;adrp_self() =\u0026gt; %p\\n\u0026quot;\n| \u0026quot;%s\\n\u0026quot;,\n| adrp_self, ptr, equal ? \u0026quot;EQUAL\u0026quot; : \u0026quot;NOT EQUAL\u0026quot;);\n|\n| return 0;\n| }\n\n.... where the adrp_self() function was compiled to:\n\n| 00000000004007e0 \u0026lt;adrp_self\u0026gt;:\n| 4007e0: 90000000 adrp x0, 400000 \u0026lt;__ehdr_start\u0026gt;\n| 4007e4: 911f8000 add x0, x0, #0x7e0\n| 4007e8: d65f03c0 ret\n\nBefore this patch, the ADRP is not recognized, and is assumed to be\nsteppable, resulting in corruption of the result:\n\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0xffffffffff7e0\n| NOT EQUAL\n\nAfter this patch, the ADRP is correctly recognized and simulated:\n\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL\n| #\n| # echo \u0026apos;p /root/adrp-self:0x007e0\u0026apos; \u0026gt; /sys/kernel/tracing/uprobe_events\n| # echo 1 \u0026gt; /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self =\u0026gt; 0x4007e0\n| adrp_self() =\u0026gt; 0x4007e0\n| EQUAL(CVE-2024-50194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: fix flushing uninitialized delayed_work on cache_ctr error\n\nAn unexpected WARN_ON from flush_work() may occur when cache creation\nfails, caused by destroying the uninitialized delayed_work waker in the\nerror path of cache_create(). For example, the warning appears on the\nsuperblock checksum error.\n\nReproduce steps:\n\ndmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot;\ndmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot;\ndmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot;\ndd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct\ndmsetup create cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\\n/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot;\n\nKernel logs:\n\n(snip)\nWARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890\n\nFix by pulling out the cancel_delayed_work_sync() from the constructor\u0026apos;s\nerror path. This patch doesn\u0026apos;t affect the use-after-free fix for\nconcurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\u0026quot;dm cache: Fix\nUAF in destroy()\u0026quot;)) as cache_dtr is not changed.(CVE-2024-50280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix null-ptr-deref in block_touch_buffer tracepoint\n\nPatch series \u0026quot;nilfs2: fix null-ptr-deref bugs on block tracepoints\u0026quot;.\n\nThis series fixes null pointer dereference bugs that occur when using\nnilfs2 and two block-related tracepoints.\n\n\nThis patch (of 2):\n\nIt has been reported that when using \u0026quot;block:block_touch_buffer\u0026quot;\ntracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a\nNULL pointer dereference, or a general protection fault when KASAN is\nenabled.\n\nThis happens because since the tracepoint was added in touch_buffer(), it\nreferences the dev_t member bh-\u0026gt;b_bdev-\u0026gt;bd_dev regardless of whether the\nbuffer head has a pointer to a block_device structure. In the current\nimplementation, the block_device structure is set after the function\nreturns to the caller.\n\nHere, touch_buffer() is used to mark the folio/page that owns the buffer\nhead as accessed, but the common search helper for folio/page used by the\ncaller function was optimized to mark the folio/page as accessed when it\nwas reimplemented a long time ago, eliminating the need to call\ntouch_buffer() here in the first place.\n\nSo this solves the issue by eliminating the touch_buffer() call itself.(CVE-2024-53131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: net: Do not use drvdata in release\n\nThe drvdata is not available in release. Let\u0026apos;s just use container_of()\nto get the uml_net instance. Otherwise, removing a network device will\nresult in a crash:\n\nRIP: 0033:net_device_release+0x10/0x6f\nRSP: 00000000e20c7c40 EFLAGS: 00010206\nRAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0\nRDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028\nRBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70\nR10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000\nR13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 627af028 62c7af00 e20c7c80 60276fcd\n 62778000 603f5820 627af028 00000000\n e20c7cb0 603a2bcd 627af000 62770010\nCall Trace:\n [\u0026lt;60276fcd\u0026gt;] device_release+0x70/0xba\n [\u0026lt;603a2bcd\u0026gt;] kobject_put+0xba/0xe7\n [\u0026lt;60277265\u0026gt;] put_device+0x19/0x1c\n [\u0026lt;60281266\u0026gt;] platform_device_put+0x26/0x29\n [\u0026lt;60281e5f\u0026gt;] platform_device_unregister+0x2c/0x2e\n [\u0026lt;6002ec9c\u0026gt;] net_remove+0x63/0x69\n [\u0026lt;60031316\u0026gt;] ? mconsole_reply+0x0/0x50\n [\u0026lt;600310c8\u0026gt;] mconsole_remove+0x160/0x1cc\n [\u0026lt;60087d40\u0026gt;] ? __remove_hrtimer+0x38/0x74\n [\u0026lt;60087ff8\u0026gt;] ? hrtimer_try_to_cancel+0x8c/0x98\n [\u0026lt;6006b3cf\u0026gt;] ? dl_server_stop+0x3f/0x48\n [\u0026lt;6006b390\u0026gt;] ? dl_server_stop+0x0/0x48\n [\u0026lt;600672e8\u0026gt;] ? dequeue_entities+0x327/0x390\n [\u0026lt;60038fa6\u0026gt;] ? um_set_signals+0x0/0x43\n [\u0026lt;6003070c\u0026gt;] mc_work_proc+0x77/0x91\n [\u0026lt;60057664\u0026gt;] process_scheduled_works+0x1b3/0x2dd\n [\u0026lt;60055f32\u0026gt;] ? assign_work+0x0/0x58\n [\u0026lt;60057f0a\u0026gt;] worker_thread+0x1e9/0x293\n [\u0026lt;6005406f\u0026gt;] ? set_pf_worker+0x0/0x64\n [\u0026lt;6005d65d\u0026gt;] ? arch_local_irq_save+0x0/0x2d\n [\u0026lt;6005d748\u0026gt;] ? kthread_exit+0x0/0x3a\n [\u0026lt;60057d21\u0026gt;] ? worker_thread+0x0/0x293\n [\u0026lt;6005dbf1\u0026gt;] kthread+0x126/0x12b\n [\u0026lt;600219c5\u0026gt;] new_thread_handler+0x85/0xb6(CVE-2024-53183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u0026gt;probe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch.(CVE-2024-53198)\n\nIn the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue indcn20_program_pipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipe_ctx-\u0026gt;plane_state in dcn20_program_pipe )partially fixed the null pointer dereference issue. However, indcn20_update_dchubp_dpp(), the variable pipe_ctx is passed in, andplane_state is accessed again through pipe_ctx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_config_scan()\n\nReplace one-element array with a flexible-array member in `struct\nmwifiex_ie_types_wildcard_ssid_params` to fix the following warning\non a MT8173 Chromebook (mt8173-elm-hana):\n\n[ 356.775250] ------------[ cut here ]------------\n[ 356.784543] memcpy: detected field-spanning write (size 6) of single field \u0026quot;wildcard_ssid_tlv-\u0026gt;ssid\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:904 (size 1)\n[ 356.813403] WARNING: CPU: 3 PID: 742 at drivers/net/wireless/marvell/mwifiex/scan.c:904 mwifiex_scan_networks+0x4fc/0xf28 [mwifiex]\n\nThe \u0026quot;(size 6)\u0026quot; above is exactly the length of the SSID of the network\nthis device was connected to. The source of the warning looks like:\n\n ssid_len = user_scan_in-\u0026gt;ssid_list[i].ssid_len;\n [...]\n memcpy(wildcard_ssid_tlv-\u0026gt;ssid,\n user_scan_in-\u0026gt;ssid_list[i].ssid, ssid_len);\n\nThere is a #define WILDCARD_SSID_TLV_MAX_SIZE that uses sizeof() on this\nstruct, but it already didn\u0026apos;t account for the size of the one-element\narray, so it doesn\u0026apos;t need to be changed.(CVE-2024-56539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: uvcvideo: Require entities to have a non-zero unique ID\n\nPer UVC 1.1+ specification 3.7.2, units and terminals must have a non-zero\nunique ID.\n\n```\nEach Unit and Terminal within the video function is assigned a unique\nidentification number, the Unit ID (UID) or Terminal ID (TID), contained in\nthe bUnitID or bTerminalID field of the descriptor. The value 0x00 is\nreserved for undefined ID,\n```\n\nSo, deny allocating an entity with ID 0 or an ID that belongs to a unit\nthat is already added to the list of entities.\n\nThis also prevents some syzkaller reproducers from triggering warnings due\nto a chain of entities referring to themselves. In one particular case, an\nOutput Unit is connected to an Input Unit, both with the same ID of 1. But\nwhen looking up for the source ID of the Output Unit, that same entity is\nfound instead of the input entity, which leads to such warnings.\n\nIn another case, a backward chain was considered finished as the source ID\nwas 0. Later on, that entity was found, but its pads were not valid.\n\nHere is a sample stack trace for one of those cases.\n\n[ 20.650953] usb 1-1: new high-speed USB device number 2 using dummy_hcd\n[ 20.830206] usb 1-1: Using ep0 maxpacket: 8\n[ 20.833501] usb 1-1: config 0 descriptor??\n[ 21.038518] usb 1-1: string descriptor 0 read error: -71\n[ 21.038893] usb 1-1: Found UVC 0.00 device \u0026lt;unnamed\u0026gt; (2833:0201)\n[ 21.039299] uvcvideo 1-1:0.0: Entity type for entity Output 1 was not initialized!\n[ 21.041583] uvcvideo 1-1:0.0: Entity type for entity Input 1 was not initialized!\n[ 21.042218] ------------[ cut here ]------------\n[ 21.042536] WARNING: CPU: 0 PID: 9 at drivers/media/mc/mc-entity.c:1147 media_create_pad_link+0x2c4/0x2e0\n[ 21.043195] Modules linked in:\n[ 21.043535] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Not tainted 6.11.0-rc7-00030-g3480e43aeccf #444\n[ 21.044101] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[ 21.044639] Workqueue: usb_hub_wq hub_event\n[ 21.045100] RIP: 0010:media_create_pad_link+0x2c4/0x2e0\n[ 21.045508] Code: fe e8 20 01 00 00 b8 f4 ff ff ff 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 0f 0b eb e9 0f 0b eb 0a 0f 0b eb 06 \u0026lt;0f\u0026gt; 0b eb 02 0f 0b b8 ea ff ff ff eb d4 66 2e 0f 1f 84 00 00 00 00\n[ 21.046801] RSP: 0018:ffffc9000004b318 EFLAGS: 00010246\n[ 21.047227] RAX: ffff888004e5d458 RBX: 0000000000000000 RCX: ffffffff818fccf1\n[ 21.047719] RDX: 000000000000007b RSI: 0000000000000000 RDI: ffff888004313290\n[ 21.048241] RBP: ffff888004313290 R08: 0001ffffffffffff R09: 0000000000000000\n[ 21.048701] R10: 0000000000000013 R11: 0001888004313290 R12: 0000000000000003\n[ 21.049138] R13: ffff888004313080 R14: ffff888004313080 R15: 0000000000000000\n[ 21.049648] FS: 0000000000000000(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000\n[ 21.050271] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 21.050688] CR2: 0000592cc27635b0 CR3: 000000000431c000 CR4: 0000000000750ef0\n[ 21.051136] PKRU: 55555554\n[ 21.051331] Call Trace:\n[ 21.051480] \u0026lt;TASK\u0026gt;\n[ 21.051611] ? __warn+0xc4/0x210\n[ 21.051861] ? media_create_pad_link+0x2c4/0x2e0\n[ 21.052252] ? report_bug+0x11b/0x1a0\n[ 21.052540] ? trace_hardirqs_on+0x31/0x40\n[ 21.052901] ? handle_bug+0x3d/0x70\n[ 21.053197] ? exc_invalid_op+0x1a/0x50\n[ 21.053511] ? asm_exc_invalid_op+0x1a/0x20\n[ 21.053924] ? media_create_pad_link+0x91/0x2e0\n[ 21.054364] ? media_create_pad_link+0x2c4/0x2e0\n[ 21.054834] ? media_create_pad_link+0x91/0x2e0\n[ 21.055131] ? _raw_spin_unlock+0x1e/0x40\n[ 21.055441] ? __v4l2_device_register_subdev+0x202/0x210\n[ 21.055837] uvc_mc_register_entities+0x358/0x400\n[ 21.056144] uvc_register_chains+0x1fd/0x290\n[ 21.056413] uvc_probe+0x380e/0x3dc0\n[ 21.056676] ? __lock_acquire+0x5aa/0x26e0\n[ 21.056946] ? find_held_lock+0x33/0xa0\n[ 21.057196] ? kernfs_activate+0x70/0x80\n[ 21.057533] ? usb_match_dy\n---truncated---(CVE-2024-56571)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Create all dump files during debugfs initialization\n\nFor the current debugfs of hisi_sas, after user triggers dump, the\ndriver allocate memory space to save the register information and create\ndebugfs files to display the saved information. In this process, the\ndebugfs files created after each dump.\n\nTherefore, when the dump is triggered while the driver is unbind, the\nfollowing hang occurs:\n\n[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0\n[67840.862947] Mem abort info:\n[67840.865855] ESR = 0x0000000096000004\n[67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits\n[67840.875125] SET = 0, FnV = 0\n[67840.878291] EA = 0, S1PTW = 0\n[67840.881545] FSC = 0x04: level 0 translation fault\n[67840.886528] Data abort info:\n[67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000\n[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000\n[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[67841.003628] pc : down_write+0x30/0x98\n[67841.007546] lr : start_creating.part.0+0x60/0x198\n[67841.012495] sp : ffff8000b979ba20\n[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40\n[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8\n[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18\n[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020\n[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff\n[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18\n[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18\n[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9\n[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001\n[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0\n[67841.089759] Call trace:\n[67841.092456] down_write+0x30/0x98\n[67841.096017] start_creating.part.0+0x60/0x198\n[67841.100613] debugfs_create_dir+0x48/0x1f8\n[67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw]\n[67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw]\n[67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw]\n[67841.125115] full_proxy_write+0x68/0xc8\n[67841.129175] vfs_write+0xd8/0x3f0\n[67841.132708] ksys_write+0x70/0x108\n[67841.136317] __arm64_sys_write+0x24/0x38\n[67841.140440] invoke_syscall+0x50/0x128\n[67841.144385] el0_svc_common.constprop.0+0xc8/0xf0\n[67841.149273] do_el0_svc+0x24/0x38\n[67841.152773] el0_svc+0x38/0xd8\n[67841.156009] el0t_64_sync_handler+0xc0/0xc8\n[67841.160361] el0t_64_sync+0x1a4/0x1a8\n[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)\n[67841.170443] ---[ end trace 0000000000000000 ]---\n\nTo fix this issue, create all directories and files during debugfs\ninitialization. In this way, the driver only needs to allocate memory\nspace to save information each time the user triggers dumping.(CVE-2024-56588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nkcsan: Turn report_filterlist_lock into a raw_spinlock\n\nRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see\nsplats like:\n\n| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n| preempt_count: 10002, expected: 0\n| RCU nest depth: 0, expected: 0\n| no locks held by swapper/1/0.\n| irq event stamp: 156674\n| hardirqs last enabled at (156673): [\u0026lt;ffffffff81130bd9\u0026gt;] do_idle+0x1f9/0x240\n| hardirqs last disabled at (156674): [\u0026lt;ffffffff82254f84\u0026gt;] sysvec_apic_timer_interrupt+0x14/0xc0\n| softirqs last enabled at (0): [\u0026lt;ffffffff81099f47\u0026gt;] copy_process+0xfc7/0x4b60\n| softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n| Preemption disabled at:\n| [\u0026lt;ffffffff814a3e2a\u0026gt;] paint_ptr+0x2a/0x90\n| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3\n| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014\n| Call Trace:\n| \u0026lt;IRQ\u0026gt;\n| dump_stack_lvl+0x7e/0xc0\n| dump_stack+0x1d/0x30\n| __might_resched+0x1a2/0x270\n| rt_spin_lock+0x68/0x170\n| kcsan_skip_report_debugfs+0x43/0xe0\n| print_report+0xb5/0x590\n| kcsan_report_known_origin+0x1b1/0x1d0\n| kcsan_setup_watchpoint+0x348/0x650\n| __tsan_unaligned_write1+0x16d/0x1d0\n| hrtimer_interrupt+0x3d6/0x430\n| __sysvec_apic_timer_interrupt+0xe8/0x3a0\n| sysvec_apic_timer_interrupt+0x97/0xc0\n| \u0026lt;/IRQ\u0026gt;\n\nOn a detected data race, KCSAN\u0026apos;s reporting logic checks if it should\nfilter the report. That list is protected by the report_filterlist_lock\n*non-raw* spinlock which may sleep on RT kernels.\n\nSince KCSAN may report data races in any context, convert it to a\nraw_spinlock.\n\nThis requires being careful about when to allocate memory for the filter\nlist itself which can be done via KCSAN\u0026apos;s debugfs interface. Concurrent\nmodification of the filter list via debugfs should be rare: the chosen\nstrategy is to optimistically pre-allocate memory before the critical\nsection and discard if unused.(CVE-2024-56610)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM\n\nWe currently assume that there is at least one VMA in a MM, which isn\u0026apos;t\ntrue.\n\nSo we might end up having find_vma() return NULL, to then de-reference\nNULL. So properly handle find_vma() returning NULL.\n\nThis fixes the report:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\nRIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]\nRIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194\nCode: ...\nRSP: 0018:ffffc9000375fd08 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000\nRDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044\nRBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1\nR10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003\nR13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8\nFS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709\n __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]\n __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]\n __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n[akpm@linux-foundation.org: add unlikely()](CVE-2024-56611)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix use after free on unload\n\nSystem crash is observed with stack trace warning of use after\nfree. There are 2 signals to tell dpc_thread to terminate (UNLOADING\nflag and kthread_stop).\n\nOn setting the UNLOADING flag when dpc_thread happens to run at the time\nand sees the flag, this causes dpc_thread to exit and clean up\nitself. When kthread_stop is called for final cleanup, this causes use\nafter free.\n\nRemove UNLOADING signal to terminate dpc_thread. Use the kthread_stop\nas the main signal to exit dpc_thread.\n\n[596663.812935] kernel BUG at mm/slub.c:294!\n[596663.812950] invalid opcode: 0000 [#1] SMP PTI\n[596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1\n[596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012\n[596663.812974] RIP: 0010:__slab_free+0x17d/0x360\n\n...\n[596663.813008] Call Trace:\n[596663.813022] ? __dentry_kill+0x121/0x170\n[596663.813030] ? _cond_resched+0x15/0x30\n[596663.813034] ? _cond_resched+0x15/0x30\n[596663.813039] ? wait_for_completion+0x35/0x190\n[596663.813048] ? try_to_wake_up+0x63/0x540\n[596663.813055] free_task+0x5a/0x60\n[596663.813061] kthread_stop+0xf3/0x100\n[596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx](CVE-2024-56623)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport\n\nSince transport-\u0026gt;sock has been set to NULL during reset transport,\nXPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the\nxs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()\nto dereference the transport-\u0026gt;sock that has been set to NULL.(CVE-2024-56688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\n9p/xen: fix release of IRQ\n\nKernel logs indicate an IRQ was double-freed.\n\nPass correct device ID during IRQ release.\n\n[Dominique: remove confusing variable reset to 0](CVE-2024-56704)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nionic: Fix netdev notifier unregister on failure\n\nIf register_netdev() fails, then the driver leaks the netdev notifier.\nFix this by calling ionic_lif_unregister() on register_netdev()\nfailure. This will also call ionic_lif_unregister_phc() if it has\nalready been registered.(CVE-2024-56715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()\n\nWhen information such as info-\u0026gt;screen_base is not ready, calling\nsh7760fb_free_mem() does not release memory correctly. Call\ndma_free_coherent() instead.(CVE-2024-56746)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix slab-use-after-free due to dangling pointer dqi_priv\n\nWhen mounting ocfs2 and then remounting it as read-only, a\nslab-use-after-free occurs after the user uses a syscall to\nquota_getnextquota. Specifically, sb_dqinfo(sb, type)-\u0026gt;dqi_priv is the\ndangling pointer.\n\nDuring the remounting process, the pointer dqi_priv is freed but is never\nset as null leaving it to be accessed. Additionally, the read-only option\nfor remounting sets the DQUOT_SUSPENDED flag instead of setting the\nDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the\nnext quota, the function ocfs2_get_next_id is called and only checks the\nquota usage flags and not the quota suspended flags.\n\nTo fix this, I set dqi_priv to null when it is freed after remounting with\nread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.\n\n[akpm@linux-foundation.org: coding-style cleanups](CVE-2024-57892)",
"id": "OESA-2025-1096",
"modified": "2026-08-06T11:08:11Z",
"published": "2025-02-08T11:08:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1096"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52434"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52480"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52614"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52627"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24857"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-24859"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26659"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26747"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26748"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26753"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26781"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26790"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26793"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26954"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27004"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36479"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37021"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40965"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53183"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56539"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56571"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56588"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56610"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56611"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56623"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56688"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56704"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56746"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57892"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2023-52434",
"CVE-2023-52480",
"CVE-2023-52614",
"CVE-2023-52627",
"CVE-2023-52913",
"CVE-2024-24857",
"CVE-2024-24859",
"CVE-2024-26659",
"CVE-2024-26664",
"CVE-2024-26673",
"CVE-2024-26747",
"CVE-2024-26748",
"CVE-2024-26749",
"CVE-2024-26753",
"CVE-2024-26781",
"CVE-2024-26790",
"CVE-2024-26793",
"CVE-2024-26952",
"CVE-2024-26954",
"CVE-2024-27004",
"CVE-2024-36479",
"CVE-2024-37021",
"CVE-2024-40965",
"CVE-2024-50194",
"CVE-2024-50280",
"CVE-2024-53131",
"CVE-2024-53183",
"CVE-2024-53198",
"CVE-2024-53201",
"CVE-2024-56539",
"CVE-2024-56571",
"CVE-2024-56588",
"CVE-2024-56610",
"CVE-2024-56611",
"CVE-2024-56623",
"CVE-2024-56688",
"CVE-2024-56704",
"CVE-2024-56715",
"CVE-2024-56746",
"CVE-2024-57892"
]
}
OESA-2025-1625 (CVE-2024-53198)
Vulnerability from osv_openeuler – Published: 2025-06-13 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
xen: Fix the issue of resource not being properly released in xenbus_dev_probe()
This patch fixes an issue in the function xenbus_dev_probe(). In the xenbus_dev_probe() function, within the if (err) branch at line 313, the program incorrectly returns err directly without releasing the resources allocated by err = drv->probe(dev, id). As the return value is non-zero, the upper layers assume the processing logic has failed. However, the probe operation was performed earlier without a corresponding remove operation. Since the probe actually allocates resources, failing to perform the remove operation could lead to problems.
To fix this issue, we followed the resource release logic of the xenbus_dev_remove() function by adding a new block fail_remove before the fail_put block. After entering the branch if (err) at line 313, the function will use a goto statement to jump to the fail_remove block, ensuring that the previously acquired resources are correctly released, thus preventing the reference count leak.
This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.(CVE-2024-53198)
In the Linux kernel, the following vulnerability has been resolved:
bpf: check changes_pkt_data property for extension programs
When processing calls to global sub-programs, verifier decides whether to invalidate all packet pointers in current state depending on the changes_pkt_data property of the global sub-program.
Because of this, an extension program replacing a global sub-program must be compatible with changes_pkt_data property of the sub-program being replaced.
This commit: - adds changes_pkt_data flag to struct bpf_prog_aux: - this flag is set in check_cfg() for main sub-program; - in jit_subprogs() for other sub-programs; - modifies bpf_check_attach_btf_id() to check changes_pkt_data flag; - moves call to check_attach_btf_id() after the call to check_cfg(), because it needs changes_pkt_data flag to be set:
bpf_check:
... ...
- check_attach_btf_id resolve_pseudo_ldimm64
resolve_pseudo_ldimm64 --> bpf_prog_is_offloaded
bpf_prog_is_offloaded check_cfg
check_cfg + check_attach_btf_id
... ...
The following fields are set by check_attach_btf_id(): - env->ops - prog->aux->attach_btf_trace - prog->aux->attach_func_name - prog->aux->attach_func_proto - prog->aux->dst_trampoline - prog->aux->mod - prog->aux->saved_dst_attach_type - prog->aux->saved_dst_prog_type - prog->expected_attach_type
Neither of these fields are used by resolve_pseudo_ldimm64() or bpf_prog_offload_verifier_prep() (for netronome and netdevsim drivers), so the reordering is safe.(CVE-2024-58100)
In the Linux kernel, the following vulnerability has been resolved:
efi: Don't map the entire mokvar table to determine its size
Currently, when validating the mokvar table, we (re)map the entire table on each iteration of the loop, adding space as we discover new entries. If the table grows over a certain size, this fails due to limitations of early_memmap(), and we get a failure and traceback:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220 ... Call Trace: <TASK> ? __early_ioremap+0xef/0x220 ? __warn.cold+0x93/0xfa ? __early_ioremap+0xef/0x220 ? report_bug+0xff/0x140 ? early_fixup_exception+0x5d/0xb0 ? early_idt_handler_common+0x2f/0x3a ? __early_ioremap+0xef/0x220 ? efi_mokvar_table_init+0xce/0x1d0 ? setup_arch+0x864/0xc10 ? start_kernel+0x6b/0xa10 ? x86_64_start_reservations+0x24/0x30 ? x86_64_start_kernel+0xed/0xf0 ? common_startup_64+0x13e/0x141 </TASK> ---[ end trace 0000000000000000 ]--- mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.
Mapping the entire structure isn't actually necessary, as we don't ever need more than one entry header mapped at once.
Changes efi_mokvar_table_init() to only map each entry header, not the entire table, when determining the table size. Since we're not mapping any data past the variable name, it also changes the code to enforce that each variable name is NUL terminated, rather than attempting to verify it in place.(CVE-2025-21872)
In the Linux kernel, the following vulnerability has been resolved:
llc: do not use skb_get() before dev_queue_xmit()
syzbot is able to crash hosts [1], using llc and devices not supporting IFF_TX_SKB_SHARING.
In this case, e1000 driver calls eth_skb_pad(), while the skb is shared.
Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.c
Note that e1000 driver might have an issue with pktgen, because it does not clear IFF_TX_SKB_SHARING, this is an orthogonal change.
We need to audit other skb_get() uses in net/llc.
[1]
kernel BUG at net/core/skbuff.c:2178 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178 Call Trace: <TASK> __skb_pad+0x18a/0x610 net/core/skbuff.c:2466 __skb_put_padto include/linux/skbuff.h:3843 [inline] skb_put_padto include/linux/skbuff.h:3862 [inline] eth_skb_pad include/linux/etherdevice.h:656 [inline] e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3806 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:4045 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621 dev_queue_xmit include/linux/netdevice.h:3313 [inline] llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209 llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993 sock_sendmsg_nosec net/socket.c:718 inline
In the Linux kernel, the following vulnerability has been resolved:
dm-flakey: Fix memory corruption in optional corrupt_bio_byte feature
Fix memory corruption due to incorrect parameter being passed to bio_init(CVE-2025-21966)
In the Linux kernel, the following vulnerability has been resolved:
md: fix mddev uaf while iterating all_mddevs list
While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF:
t1: spin_lock //list_for_each_entry_safe(mddev, n, ...) mddev_get(mddev1) // assume mddev2 is the next entry spin_unlock t2: //remove mddev2 ... mddev_free spin_lock list_del spin_unlock kfree(mddev2) mddev_put(mddev1) spin_lock //continue dereference mddev2->all_mddevs
The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex.
Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem.(CVE-2025-22126)
In the Linux kernel, the following vulnerability has been resolved:
dlm: prevent NPD when writing a positive value to event_done
do_uevent returns the value written to event_done. In case it is a positive value, new_lockspace would undo all the work, and lockspace would not be set. __dlm_new_lockspace, however, would treat that positive value as a success due to commit 8511a2728ab8 ("dlm: fix use count with multiple joins").
Down the line, device_create_lockspace would pass that NULL lockspace to dlm_find_lockspace_local, leading to a NULL pointer dereference.
Treating such positive values as successes prevents the problem. Given this has been broken for so long, this is unlikely to break userspace expectations.(CVE-2025-23131)
In the Linux kernel, the following vulnerability has been resolved:
soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()
soc_dev_attr->revision could be NULL, thus, a pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c").
This issue is found by our static analysis tool.(CVE-2025-23148)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi_parser: refactor hfi packet parsing logic
words_count denotes the number of words in total payload, while data points to payload of various property within it. When words_count reaches last word, data can access memory beyond the total payload. This can lead to OOB access. With this patch, the utility api for handling individual properties now returns the size of data consumed. Accordingly remaining bytes are calculated before parsing the payload, thereby eliminates the OOB access possibilities.(CVE-2025-23156)
In the Linux kernel, the following vulnerability has been resolved:
scsi: st: Fix array overflow in st_setup()
Change the array size to follow parms size instead of a fixed value.(CVE-2025-37857)
In the Linux kernel, the following vulnerability has been resolved:
pds_core: remove write-after-free of client_id
A use-after-free error popped up in stress testing:
[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47): [Mon Apr 21 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core] [Mon Apr 21 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core] [Mon Apr 21 21:21:33 2025] pci_device_remove+0x24/0x70 [Mon Apr 21 21:21:33 2025] device_release_driver_internal+0x11f/0x180 [Mon Apr 21 21:21:33 2025] driver_detach+0x45/0x80 [Mon Apr 21 21:21:33 2025] bus_remove_driver+0x83/0xe0 [Mon Apr 21 21:21:33 2025] pci_unregister_driver+0x1a/0x80
The actual device uninit usually happens on a separate thread scheduled after this code runs, but there is no guarantee of order of thread execution, so this could be a problem. There's no actual need to clear the client_id at this point, so simply remove the offending code.(CVE-2025-37916)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: vnifilter: Fix unlocked deletion of default FDB entry
When a VNI is deleted from a VXLAN device in 'vnifilter' mode, the FDB entry associated with the default remote (assuming one was configured) is deleted without holding the hash lock. This is wrong and will result in a warning [1] being generated by the lockdep annotation that was added by commit ebe642067455 ("vxlan: Create wrappers for FDB lookup").
Reproducer:
# ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1 # bridge vni add vni 10010 remote 198.51.100.1 dev vx0 # bridge vni del vni 10010 dev vx0
Fix by acquiring the hash lock before the deletion and releasing it afterwards. Blame the original commit that introduced the issue rather than the one that exposed it.
[1] WARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0 [...] RIP: 0010:vxlan_find_mac+0x17f/0x1a0 [...] Call Trace: <TASK> __vxlan_fdb_delete+0xbe/0x560 vxlan_vni_delete_group+0x2ba/0x940 vxlan_vni_del.isra.0+0x15f/0x580 vxlan_process_vni_filter+0x38b/0x7b0 vxlan_vnifilter_process+0x3bb/0x510 rtnetlink_rcv_msg+0x2f7/0xb70 netlink_rcv_skb+0x131/0x360 netlink_unicast+0x426/0x710 netlink_sendmsg+0x75a/0xc20 __sock_sendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _sys_sendmsg+0xfc/0x180 __sys_sendmsg+0x121/0x1b0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-37921)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix oob write in trace_seq_to_buffer()
syzbot reported this bug:
BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260
CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 .... ==================================================================
It has been reported that trace_seq_to_buffer() tries to copy more data than PAGE_SIZE to buf. Therefore, to prevent this, we should use the smaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.(CVE-2025-37923)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbd_session_rpc_open
A UAF issue can occur due to a race condition between ksmbd_session_rpc_open() and __session_rpc_close(). Add rpc_lock to the session to protect it.(CVE-2025-37926)
In the Linux kernel, the following vulnerability has been resolved:
mm/huge_memory: fix dereferencing invalid pmd migration entry
When migrating a THP, concurrent access to the PMD migration entry during a deferred split scan can lead to an invalid address access, as illustrated below. To prevent this invalid access, it is necessary to check the PMD migration entry and return early. In this context, there is no need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the equality of the target folio. Since the PMD migration entry is locked, it cannot be served as the target.
Mailing list discussion and explanation from Hugh Dickins: "An anon_vma lookup points to a location which may contain the folio of interest, but might instead contain another folio: and weeding out those other folios is precisely what the "folio != pmd_folio((*pmd)" check (and the "risk of replacing the wrong folio" comment a few lines above it) is for."
BUG: unable to handle page fault for address: ffffea60001db008 CPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60 Call Trace: <TASK> try_to_migrate_one+0x28c/0x3730 rmap_walk_anon+0x4f6/0x770 unmap_folio+0x196/0x1f0 split_huge_page_to_list_to_order+0x9f6/0x1560 deferred_split_scan+0xac5/0x12a0 shrinker_debugfs_scan_write+0x376/0x470 full_proxy_write+0x15c/0x220 vfs_write+0x2fc/0xcb0 ksys_write+0x146/0x250 do_syscall_64+0x6a/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e
The bug is found by syzkaller on an internal kernel, then confirmed on upstream.(CVE-2025-37958)
In the Linux kernel, the following vulnerability has been resolved:
iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo
Prevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in case pattern_len is equal to zero and the device FIFO is not empty.(CVE-2025-37969)
In the Linux kernel, the following vulnerability has been resolved:
module: ensure that kobject_put() is safe for module type kobjects
In 'lookup_or_create_module_kobject()', an internal kobject is created using 'module_ktype'. So call to 'kobject_put()' on error handling path causes an attempt to use an uninitialized completion pointer in 'module_kobject_release()'. In this scenario, we just want to release kobject without an extra synchronization required for a regular module unloading process, so adding an extra check whether 'complete()' is actually required makes 'kobject_put()' safe.(CVE-2025-37995)
In the Linux kernel, the following vulnerability has been resolved:
md/raid10: wait barrier before returning discard request with REQ_NOWAIT
raid10_handle_discard should wait barrier before returning a discard bio which has REQ_NOWAIT. And there is no need to print warning calltrace if a discard bio has REQ_NOWAIT flag. Quality engineer usually checks dmesg and reports error if dmesg has warning/error calltrace.(CVE-2025-40325)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"perf-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-96.0.0.100.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-96.0.0.100.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"perf-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-96.0.0.100.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-96.0.0.100.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-96.0.0.100.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:\n\nxen: Fix the issue of resource not being properly released in xenbus_dev_probe()\n\nThis patch fixes an issue in the function xenbus_dev_probe(). In the\nxenbus_dev_probe() function, within the if (err) branch at line 313, the\nprogram incorrectly returns err directly without releasing the resources\nallocated by err = drv-\u0026gt;probe(dev, id). As the return value is non-zero,\nthe upper layers assume the processing logic has failed. However, the probe\noperation was performed earlier without a corresponding remove operation.\nSince the probe actually allocates resources, failing to perform the remove\noperation could lead to problems.\n\nTo fix this issue, we followed the resource release logic of the\nxenbus_dev_remove() function by adding a new block fail_remove before the\nfail_put block. After entering the branch if (err) at line 313, the\nfunction will use a goto statement to jump to the fail_remove block,\nensuring that the previously acquired resources are correctly released,\nthus preventing the reference count leak.\n\nThis bug was identified by an experimental static analysis tool developed\nby our team. The tool specializes in analyzing reference count operations\nand detecting potential issues where resources are not properly managed.\nIn this case, the tool flagged the missing release operation as a\npotential problem, which led to the development of this patch.(CVE-2024-53198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: check changes_pkt_data property for extension programs\n\nWhen processing calls to global sub-programs, verifier decides whether\nto invalidate all packet pointers in current state depending on the\nchanges_pkt_data property of the global sub-program.\n\nBecause of this, an extension program replacing a global sub-program\nmust be compatible with changes_pkt_data property of the sub-program\nbeing replaced.\n\nThis commit:\n- adds changes_pkt_data flag to struct bpf_prog_aux:\n - this flag is set in check_cfg() for main sub-program;\n - in jit_subprogs() for other sub-programs;\n- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;\n- moves call to check_attach_btf_id() after the call to check_cfg(),\n because it needs changes_pkt_data flag to be set:\n\n bpf_check:\n ... ...\n - check_attach_btf_id resolve_pseudo_ldimm64\n resolve_pseudo_ldimm64 --\u0026gt; bpf_prog_is_offloaded\n bpf_prog_is_offloaded check_cfg\n check_cfg + check_attach_btf_id\n ... ...\n\nThe following fields are set by check_attach_btf_id():\n- env-\u0026gt;ops\n- prog-\u0026gt;aux-\u0026gt;attach_btf_trace\n- prog-\u0026gt;aux-\u0026gt;attach_func_name\n- prog-\u0026gt;aux-\u0026gt;attach_func_proto\n- prog-\u0026gt;aux-\u0026gt;dst_trampoline\n- prog-\u0026gt;aux-\u0026gt;mod\n- prog-\u0026gt;aux-\u0026gt;saved_dst_attach_type\n- prog-\u0026gt;aux-\u0026gt;saved_dst_prog_type\n- prog-\u0026gt;expected_attach_type\n\nNeither of these fields are used by resolve_pseudo_ldimm64() or\nbpf_prog_offload_verifier_prep() (for netronome and netdevsim\ndrivers), so the reordering is safe.(CVE-2024-58100)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nefi: Don\u0026apos;t map the entire mokvar table to determine its size\n\nCurrently, when validating the mokvar table, we (re)map the entire table\non each iteration of the loop, adding space as we discover new entries.\nIf the table grows over a certain size, this fails due to limitations of\nearly_memmap(), and we get a failure and traceback:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __early_ioremap+0xef/0x220\n ? __warn.cold+0x93/0xfa\n ? __early_ioremap+0xef/0x220\n ? report_bug+0xff/0x140\n ? early_fixup_exception+0x5d/0xb0\n ? early_idt_handler_common+0x2f/0x3a\n ? __early_ioremap+0xef/0x220\n ? efi_mokvar_table_init+0xce/0x1d0\n ? setup_arch+0x864/0xc10\n ? start_kernel+0x6b/0xa10\n ? x86_64_start_reservations+0x24/0x30\n ? x86_64_start_kernel+0xed/0xf0\n ? common_startup_64+0x13e/0x141\n \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.\n\nMapping the entire structure isn\u0026apos;t actually necessary, as we don\u0026apos;t ever\nneed more than one entry header mapped at once.\n\nChanges efi_mokvar_table_init() to only map each entry header, not the\nentire table, when determining the table size. Since we\u0026apos;re not mapping\nany data past the variable name, it also changes the code to enforce\nthat each variable name is NUL terminated, rather than attempting to\nverify it in place.(CVE-2025-21872)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nllc: do not use skb_get() before dev_queue_xmit()\n\nsyzbot is able to crash hosts [1], using llc and devices\nnot supporting IFF_TX_SKB_SHARING.\n\nIn this case, e1000 driver calls eth_skb_pad(), while\nthe skb is shared.\n\nSimply replace skb_get() by skb_clone() in net/llc/llc_s_ac.c\n\nNote that e1000 driver might have an issue with pktgen,\nbecause it does not clear IFF_TX_SKB_SHARING, this is an\northogonal change.\n\nWe need to audit other skb_get() uses in net/llc.\n\n[1]\n\nkernel BUG at net/core/skbuff.c:2178 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __skb_pad+0x18a/0x610 net/core/skbuff.c:2466\n __skb_put_padto include/linux/skbuff.h:3843 [inline]\n skb_put_padto include/linux/skbuff.h:3862 [inline]\n eth_skb_pad include/linux/etherdevice.h:656 [inline]\n e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128\n __netdev_start_xmit include/linux/netdevice.h:5151 [inline]\n netdev_start_xmit include/linux/netdevice.h:5160 [inline]\n xmit_one net/core/dev.c:3806 [inline]\n dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822\n sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343\n __dev_xmit_skb net/core/dev.c:4045 [inline]\n __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621\n dev_queue_xmit include/linux/netdevice.h:3313 [inline]\n llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144\n llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209\n llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993\n sock_sendmsg_nosec net/socket.c:718 [inline](CVE-2025-21925)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm-flakey: Fix memory corruption in optional corrupt_bio_byte feature\n\nFix memory corruption due to incorrect parameter being passed to bio_init(CVE-2025-21966)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix mddev uaf while iterating all_mddevs list\n\nWhile iterating all_mddevs list from md_notify_reboot() and md_exit(),\nlist_for_each_entry_safe is used, and this can race with deletint the\nnext mddev, causing UAF:\n\nt1:\nspin_lock\n//list_for_each_entry_safe(mddev, n, ...)\n mddev_get(mddev1)\n // assume mddev2 is the next entry\n spin_unlock\n t2:\n //remove mddev2\n ...\n mddev_free\n spin_lock\n list_del\n spin_unlock\n kfree(mddev2)\n mddev_put(mddev1)\n spin_lock\n //continue dereference mddev2-\u0026gt;all_mddevs\n\nThe old helper for_each_mddev() actually grab the reference of mddev2\nwhile holding the lock, to prevent from being freed. This problem can be\nfixed the same way, however, the code will be complex.\n\nHence switch to use list_for_each_entry, in this case mddev_put() can free\nthe mddev1 and it\u0026apos;s not safe as well. Refer to md_seq_show(), also factor\nout a helper mddev_put_locked() to fix this problem.(CVE-2025-22126)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: prevent NPD when writing a positive value to event_done\n\ndo_uevent returns the value written to event_done. In case it is a\npositive value, new_lockspace would undo all the work, and lockspace\nwould not be set. __dlm_new_lockspace, however, would treat that\npositive value as a success due to commit 8511a2728ab8 (\u0026quot;dlm: fix use\ncount with multiple joins\u0026quot;).\n\nDown the line, device_create_lockspace would pass that NULL lockspace to\ndlm_find_lockspace_local, leading to a NULL pointer dereference.\n\nTreating such positive values as successes prevents the problem. Given\nthis has been broken for so long, this is unlikely to break userspace\nexpectations.(CVE-2025-23131)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()\n\nsoc_dev_attr-\u0026gt;revision could be NULL, thus,\na pointer check is added to prevent potential NULL pointer dereference.\nThis is similar to the fix in commit 3027e7b15b02\n(\u0026quot;ice: Fix some null pointer dereference issues in ice_ptp.c\u0026quot;).\n\nThis issue is found by our static analysis tool.(CVE-2025-23148)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi_parser: refactor hfi packet parsing logic\n\nwords_count denotes the number of words in total payload, while data\npoints to payload of various property within it. When words_count\nreaches last word, data can access memory beyond the total payload. This\ncan lead to OOB access. With this patch, the utility api for handling\nindividual properties now returns the size of data consumed. Accordingly\nremaining bytes are calculated before parsing the payload, thereby\neliminates the OOB access possibilities.(CVE-2025-23156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: st: Fix array overflow in st_setup()\n\nChange the array size to follow parms size instead of a fixed value.(CVE-2025-37857)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: remove write-after-free of client_id\n\nA use-after-free error popped up in stress testing:\n\n[Mon Apr 21 21:21:33 2025] BUG: KFENCE: use-after-free write in pdsc_auxbus_dev_del+0xef/0x160 [pds_core]\n[Mon Apr 21 21:21:33 2025] Use-after-free write at 0x000000007013ecd1 (in kfence-#47):\n[Mon Apr 21 21:21:33 2025] pdsc_auxbus_dev_del+0xef/0x160 [pds_core]\n[Mon Apr 21 21:21:33 2025] pdsc_remove+0xc0/0x1b0 [pds_core]\n[Mon Apr 21 21:21:33 2025] pci_device_remove+0x24/0x70\n[Mon Apr 21 21:21:33 2025] device_release_driver_internal+0x11f/0x180\n[Mon Apr 21 21:21:33 2025] driver_detach+0x45/0x80\n[Mon Apr 21 21:21:33 2025] bus_remove_driver+0x83/0xe0\n[Mon Apr 21 21:21:33 2025] pci_unregister_driver+0x1a/0x80\n\nThe actual device uninit usually happens on a separate thread\nscheduled after this code runs, but there is no guarantee of order\nof thread execution, so this could be a problem. There\u0026apos;s no\nactual need to clear the client_id at this point, so simply\nremove the offending code.(CVE-2025-37916)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: vnifilter: Fix unlocked deletion of default FDB entry\n\nWhen a VNI is deleted from a VXLAN device in \u0026apos;vnifilter\u0026apos; mode, the FDB\nentry associated with the default remote (assuming one was configured)\nis deleted without holding the hash lock. This is wrong and will result\nin a warning [1] being generated by the lockdep annotation that was\nadded by commit ebe642067455 (\u0026quot;vxlan: Create wrappers for FDB lookup\u0026quot;).\n\nReproducer:\n\n # ip link add vx0 up type vxlan dstport 4789 external vnifilter local 192.0.2.1\n # bridge vni add vni 10010 remote 198.51.100.1 dev vx0\n # bridge vni del vni 10010 dev vx0\n\nFix by acquiring the hash lock before the deletion and releasing it\nafterwards. Blame the original commit that introduced the issue rather\nthan the one that exposed it.\n\n[1]\nWARNING: CPU: 3 PID: 392 at drivers/net/vxlan/vxlan_core.c:417 vxlan_find_mac+0x17f/0x1a0\n[...]\nRIP: 0010:vxlan_find_mac+0x17f/0x1a0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __vxlan_fdb_delete+0xbe/0x560\n vxlan_vni_delete_group+0x2ba/0x940\n vxlan_vni_del.isra.0+0x15f/0x580\n vxlan_process_vni_filter+0x38b/0x7b0\n vxlan_vnifilter_process+0x3bb/0x510\n rtnetlink_rcv_msg+0x2f7/0xb70\n netlink_rcv_skb+0x131/0x360\n netlink_unicast+0x426/0x710\n netlink_sendmsg+0x75a/0xc20\n __sock_sendmsg+0xc1/0x150\n ____sys_sendmsg+0x5aa/0x7b0\n ___sys_sendmsg+0xfc/0x180\n __sys_sendmsg+0x121/0x1b0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53(CVE-2025-37921)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix oob write in trace_seq_to_buffer()\n\nsyzbot reported this bug:\n==================================================================\nBUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]\nBUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822\nWrite of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260\n\nCPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106\n trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]\n tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822\n ....\n==================================================================\n\nIt has been reported that trace_seq_to_buffer() tries to copy more data\nthan PAGE_SIZE to buf. Therefore, to prevent this, we should use the\nsmaller of trace_seq_used(\u0026amp;iter-\u0026gt;seq) and PAGE_SIZE as an argument.(CVE-2025-37923)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_session_rpc_open\n\nA UAF issue can occur due to a race condition between\nksmbd_session_rpc_open() and __session_rpc_close().\nAdd rpc_lock to the session to protect it.(CVE-2025-37926)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix dereferencing invalid pmd migration entry\n\nWhen migrating a THP, concurrent access to the PMD migration entry during\na deferred split scan can lead to an invalid address access, as\nillustrated below. To prevent this invalid access, it is necessary to\ncheck the PMD migration entry and return early. In this context, there is\nno need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the\nequality of the target folio. Since the PMD migration entry is locked, it\ncannot be served as the target.\n\nMailing list discussion and explanation from Hugh Dickins: \u0026quot;An anon_vma\nlookup points to a location which may contain the folio of interest, but\nmight instead contain another folio: and weeding out those other folios is\nprecisely what the \u0026quot;folio != pmd_folio((*pmd)\u0026quot; check (and the \u0026quot;risk of\nreplacing the wrong folio\u0026quot; comment a few lines above it) is for.\u0026quot;\n\nBUG: unable to handle page fault for address: ffffea60001db008\nCPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60\nCall Trace:\n\u0026lt;TASK\u0026gt;\ntry_to_migrate_one+0x28c/0x3730\nrmap_walk_anon+0x4f6/0x770\nunmap_folio+0x196/0x1f0\nsplit_huge_page_to_list_to_order+0x9f6/0x1560\ndeferred_split_scan+0xac5/0x12a0\nshrinker_debugfs_scan_write+0x376/0x470\nfull_proxy_write+0x15c/0x220\nvfs_write+0x2fc/0xcb0\nksys_write+0x146/0x250\ndo_syscall_64+0x6a/0x120\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe bug is found by syzkaller on an internal kernel, then confirmed on\nupstream.(CVE-2025-37958)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifo\n\nPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop in\ncase pattern_len is equal to zero and the device FIFO is not empty.(CVE-2025-37969)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmodule: ensure that kobject_put() is safe for module type kobjects\n\nIn \u0026apos;lookup_or_create_module_kobject()\u0026apos;, an internal kobject is created\nusing \u0026apos;module_ktype\u0026apos;. So call to \u0026apos;kobject_put()\u0026apos; on error handling\npath causes an attempt to use an uninitialized completion pointer in\n\u0026apos;module_kobject_release()\u0026apos;. In this scenario, we just want to release\nkobject without an extra synchronization required for a regular module\nunloading process, so adding an extra check whether \u0026apos;complete()\u0026apos; is\nactually required makes \u0026apos;kobject_put()\u0026apos; safe.(CVE-2025-37995)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: wait barrier before returning discard request with REQ_NOWAIT\n\nraid10_handle_discard should wait barrier before returning a discard bio\nwhich has REQ_NOWAIT. And there is no need to print warning calltrace\nif a discard bio has REQ_NOWAIT flag. Quality engineer usually checks\ndmesg and reports error if dmesg has warning/error calltrace.(CVE-2025-40325)",
"id": "OESA-2025-1625",
"modified": "2026-08-06T11:08:43Z",
"published": "2025-06-13T11:08:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1625"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53198"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58100"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21872"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21925"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21966"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22126"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23131"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23148"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23156"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37857"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37921"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37923"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37926"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37958"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37969"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37995"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40325"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-53198",
"CVE-2024-58100",
"CVE-2025-21872",
"CVE-2025-21925",
"CVE-2025-21966",
"CVE-2025-22126",
"CVE-2025-23131",
"CVE-2025-23148",
"CVE-2025-23156",
"CVE-2025-37857",
"CVE-2025-37916",
"CVE-2025-37921",
"CVE-2025-37923",
"CVE-2025-37926",
"CVE-2025-37958",
"CVE-2025-37969",
"CVE-2025-37995",
"CVE-2025-40325"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.