Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-38584 (GCVE-0-2025-38584)
Vulnerability from cvelistv5 – Published: 2025-08-19 17:03 – Updated: 2026-10-15 22:02| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
16295bec6398a3eedc9377e1af6ff4c71b98c300 , < a2048e475e22b13dc3e53d485b7e6e11464ed9a6
(git)
Affected: 16295bec6398a3eedc9377e1af6ff4c71b98c300 , < 73f132e60857038416540c3599b1de6033d7575a (git) Affected: 16295bec6398a3eedc9377e1af6ff4c71b98c300 , < 609e59193fc6d9dd323f1c6ae1fdd721f1c79680 (git) Affected: 16295bec6398a3eedc9377e1af6ff4c71b98c300 , < a11a12a9880ab37342b73c93cfe1a3ada02ff0db (git) Affected: 16295bec6398a3eedc9377e1af6ff4c71b98c300 , < f231d5d001ec75f5886c02d496a4c79edc383d45 (git) Affected: 16295bec6398a3eedc9377e1af6ff4c71b98c300 , < dbe3e911a59bda6de96e7cae387ff882c2c177fa (git) Affected: 16295bec6398a3eedc9377e1af6ff4c71b98c300 , < cdf79bd2e1ecb3cc75631c73d8f4149be6019a52 (git) Affected: 16295bec6398a3eedc9377e1af6ff4c71b98c300 , < 71203f68c7749609d7fc8ae6ad054bdedeb24f91 (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.34
Unaffected: 0 , < 2.6.34 (semver) Unaffected: 5.10.258 , ≤ 5.10.* (semver) Unaffected: 5.15.209 , ≤ 5.15.* (semver) Unaffected: 6.1.175 , ≤ 6.1.* (semver) Unaffected: 6.6.140 , ≤ 6.6.* (semver) Unaffected: 6.12.86 , ≤ 6.12.* (semver) Unaffected: 6.15.10 , ≤ 6.15.* (semver) Unaffected: 6.16.1 , ≤ 6.16.* (semver) Unaffected: 6.17 , ≤ * (original_commit_for_fix) |
guessed | |
| Siemens | SIMATIC S7-1500 TM MFP - GNU/Linux subsystem |
Affected:
0 , < *
(custom)
|
guessed |
{
"containers": {
"adp": [
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T01:07:30.115Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-784472.html"
}
],
"x_adpType": "supplier"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-38584",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T21:51:57.371948Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T22:02:26.071Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/linux/padata.h",
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "a2048e475e22b13dc3e53d485b7e6e11464ed9a6",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "73f132e60857038416540c3599b1de6033d7575a",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "609e59193fc6d9dd323f1c6ae1fdd721f1c79680",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "a11a12a9880ab37342b73c93cfe1a3ada02ff0db",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "f231d5d001ec75f5886c02d496a4c79edc383d45",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "dbe3e911a59bda6de96e7cae387ff882c2c177fa",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "cdf79bd2e1ecb3cc75631c73d8f4149be6019a52",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "71203f68c7749609d7fc8ae6ad054bdedeb24f91",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/linux/padata.h",
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.34"
},
{
"lessThan": "2.6.34",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.258",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.209",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.175",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.86",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.1",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.258",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.209",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.175",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.140",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.86",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15.10",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.1",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"versionStartIncluding": "2.6.34",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit. A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly. If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u003eserial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u003eserial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable padata reorder path is only driven by pcrypt AEAD requests, which an unprivileged local user submits via AF_ALG sockets (or in-kernel IPsec); the required `padata_replace()`/`padata_free_shell()` side is a local sysfs/CPU-hotplug/netlink action, so a purely remote attacker cannot set up the necessary state.\nAC:H - The attacker controls only one side of the race (the pcrypt request stream); dropping the base `pd` reference requires `padata_replace()` via root-only sysfs cpumask writes, CPU hotplug, or init-ns CAP_NET_ADMIN `crypto_del_alg` \u2014 conditions truly outside an unprivileged attacker\u0027s control, and the window between `spin_unlock(\u0026squeue-\u003eserial.lock)` and the next `pd` dereference must coincide with the final refcount drop.\nPR:L - An unprivileged user with no capabilities can open AF_ALG sockets and flood `pcrypt(...)` requests to drive `padata_do_parallel`/`padata_do_serial` and hold the race open; no capability check exists on that path.\nUI:N - No victim action is needed \u2014 the `padata_replace()` trigger routinely occurs automatically via CPU hotplug (cloud vCPU resize, thermal/power hotplug on embedded and Android, suspend/resume offlining secondary CPUs) rather than through a human interacting with content.\nS:U - The use-after-free is on a kernel slab/percpu object and its consequences stay within the kernel\u0027s own security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The freed `struct parallel_data` and its freed percpu `reorder_list`/`squeue` are read after free (`pd-\u003ecpu`, `pd-\u003eprocessed`, `reorder-\u003elock`, list pointers), and reclaiming those allocations with attacker-sprayed objects turns the UAF into an arbitrary kernel-memory read primitive.\nI:H - After the free, `padata_reorder()` writes into the freed object (`spin_unlock_bh(\u0026pd-\u003elock)`, `refcount_inc()`, `list_del_init()`) and queues `\u0026pd-\u003ereorder_work` and `\u0026squeue-\u003ework` \u2014 work_structs inside freed memory whose `func` pointer is later invoked, giving control-flow hijack and privilege escalation once the slab is reclaimed.\nA:H - Even unexploited, the use-after-free corrupts freed slab and percpu memory, takes a spinlock in freed storage, and queues a work item with a stale function pointer, reliably producing a kernel oops/panic."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:03:10.424Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/a2048e475e22b13dc3e53d485b7e6e11464ed9a6"
},
{
"url": "https://git.kernel.org/stable/c/73f132e60857038416540c3599b1de6033d7575a"
},
{
"url": "https://git.kernel.org/stable/c/609e59193fc6d9dd323f1c6ae1fdd721f1c79680"
},
{
"url": "https://git.kernel.org/stable/c/a11a12a9880ab37342b73c93cfe1a3ada02ff0db"
},
{
"url": "https://git.kernel.org/stable/c/f231d5d001ec75f5886c02d496a4c79edc383d45"
},
{
"url": "https://git.kernel.org/stable/c/dbe3e911a59bda6de96e7cae387ff882c2c177fa"
},
{
"url": "https://git.kernel.org/stable/c/cdf79bd2e1ecb3cc75631c73d8f4149be6019a52"
},
{
"url": "https://git.kernel.org/stable/c/71203f68c7749609d7fc8ae6ad054bdedeb24f91"
}
],
"title": "padata: Fix pd UAF once and for all",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-38584",
"datePublished": "2025-08-19T17:03:06.172Z",
"dateReserved": "2025-04-16T04:51:24.026Z",
"dateUpdated": "2026-10-15T22:02:26.071Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-38584",
"date": "2026-11-15",
"epss": "0.00194",
"percentile": "0.09115"
},
"microsoft_vex": {
"current_release_date": "2026-10-16T01:45:29.000Z",
"cve": "CVE-2025-38584",
"id": "msrc_CVE-2025-38584",
"initial_release_date": "2025-09-04T04:21:24.000Z",
"product_status:fixed": "1",
"product_status:known_affected": "20",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "padata: Fix pd UAF once and for all",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-38584.json",
"version": "19"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/linux/padata.h",
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "a2048e475e22b13dc3e53d485b7e6e11464ed9a6",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "73f132e60857038416540c3599b1de6033d7575a",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "609e59193fc6d9dd323f1c6ae1fdd721f1c79680",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "a11a12a9880ab37342b73c93cfe1a3ada02ff0db",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "f231d5d001ec75f5886c02d496a4c79edc383d45",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "dbe3e911a59bda6de96e7cae387ff882c2c177fa",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "cdf79bd2e1ecb3cc75631c73d8f4149be6019a52",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "71203f68c7749609d7fc8ae6ad054bdedeb24f91",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/linux/padata.h",
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.34"
},
{
"lessThan": "2.6.34",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.258",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.209",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.175",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.86",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.1",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "70708DCC-6F9D-4EFE-AF47-0CA615284AD2",
"versionEndExcluding": "6.15.10",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "58182352-D7DF-4CC9-841E-03C1D852C3FB",
"versionEndExcluding": "6.16.1",
"versionStartIncluding": "6.16",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit. A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly. If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u003eserial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u003eserial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: Arregla pd UAF de una vez por todas Hay una condici\u00f3n de ejecuci\u00f3n/UAF en padata_reorder que se remonta a la confirmaci\u00f3n inicial. Se toma un recuento de referencias al inicio del proceso en padata_do_parallel y se libera al final en padata_serial_worker. Este recuento de referencias es (y solo es) necesario para que padata_replace funcione correctamente. Si nunca se llama a padata_replace, no hay problema. En la funci\u00f3n padata_reorder que sirve como n\u00facleo de padata, tan pronto como padata se agrega a queue-\u0026gt;serial.list y se libera el bloqueo de giro asociado, ese padata puede procesarse y el recuento de referencias en pd desaparecer\u00eda. Arregla esto obteniendo el siguiente padata antes de que se libere el bloqueo squeue-\u0026gt;serial. Para que esto sea posible, simplifica padata_reorder llam\u00e1ndolo solo una vez que llega el siguiente padata."
}
],
"id": "CVE-2025-38584",
"lastModified": "2026-10-15T22:18:46.183",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.0,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.0,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"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": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-38584",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T21:51:57.371948Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-08-19T17:15:35.723",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/609e59193fc6d9dd323f1c6ae1fdd721f1c79680"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/71203f68c7749609d7fc8ae6ad054bdedeb24f91"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/73f132e60857038416540c3599b1de6033d7575a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a11a12a9880ab37342b73c93cfe1a3ada02ff0db"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a2048e475e22b13dc3e53d485b7e6e11464ed9a6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cdf79bd2e1ecb3cc75631c73d8f4149be6019a52"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/dbe3e911a59bda6de96e7cae387ff882c2c177fa"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f231d5d001ec75f5886c02d496a4c79edc383d45"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-784472.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-11-09T18:08:52+00:00",
"cve": "CVE-2025-38584",
"id": "CVE-2025-38584",
"initial_release_date": "2025-08-19T00:00:00+00:00",
"product_status:known_affected": "186",
"product_status:known_not_affected": "14",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: padata: Fix pd UAF once and for all",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-38584.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T01:07:30.115Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-784472.html"
}
],
"x_adpType": "supplier"
},
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-38584",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T21:51:57.371948Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T21:51:58.359Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/linux/padata.h",
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "a2048e475e22b13dc3e53d485b7e6e11464ed9a6",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "73f132e60857038416540c3599b1de6033d7575a",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "609e59193fc6d9dd323f1c6ae1fdd721f1c79680",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "a11a12a9880ab37342b73c93cfe1a3ada02ff0db",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "f231d5d001ec75f5886c02d496a4c79edc383d45",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "dbe3e911a59bda6de96e7cae387ff882c2c177fa",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "cdf79bd2e1ecb3cc75631c73d8f4149be6019a52",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "71203f68c7749609d7fc8ae6ad054bdedeb24f91",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/linux/padata.h",
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.34"
},
{
"lessThan": "2.6.34",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.258",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.209",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.175",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.86",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.1",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.258",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.209",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.175",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.140",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.86",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15.10",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.1",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"versionStartIncluding": "2.6.34",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit. A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly. If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u003eserial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u003eserial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable padata reorder path is only driven by pcrypt AEAD requests, which an unprivileged local user submits via AF_ALG sockets (or in-kernel IPsec); the required `padata_replace()`/`padata_free_shell()` side is a local sysfs/CPU-hotplug/netlink action, so a purely remote attacker cannot set up the necessary state.\nAC:H - The attacker controls only one side of the race (the pcrypt request stream); dropping the base `pd` reference requires `padata_replace()` via root-only sysfs cpumask writes, CPU hotplug, or init-ns CAP_NET_ADMIN `crypto_del_alg` \u2014 conditions truly outside an unprivileged attacker\u0027s control, and the window between `spin_unlock(\u0026squeue-\u003eserial.lock)` and the next `pd` dereference must coincide with the final refcount drop.\nPR:L - An unprivileged user with no capabilities can open AF_ALG sockets and flood `pcrypt(...)` requests to drive `padata_do_parallel`/`padata_do_serial` and hold the race open; no capability check exists on that path.\nUI:N - No victim action is needed \u2014 the `padata_replace()` trigger routinely occurs automatically via CPU hotplug (cloud vCPU resize, thermal/power hotplug on embedded and Android, suspend/resume offlining secondary CPUs) rather than through a human interacting with content.\nS:U - The use-after-free is on a kernel slab/percpu object and its consequences stay within the kernel\u0027s own security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The freed `struct parallel_data` and its freed percpu `reorder_list`/`squeue` are read after free (`pd-\u003ecpu`, `pd-\u003eprocessed`, `reorder-\u003elock`, list pointers), and reclaiming those allocations with attacker-sprayed objects turns the UAF into an arbitrary kernel-memory read primitive.\nI:H - After the free, `padata_reorder()` writes into the freed object (`spin_unlock_bh(\u0026pd-\u003elock)`, `refcount_inc()`, `list_del_init()`) and queues `\u0026pd-\u003ereorder_work` and `\u0026squeue-\u003ework` \u2014 work_structs inside freed memory whose `func` pointer is later invoked, giving control-flow hijack and privilege escalation once the slab is reclaimed.\nA:H - Even unexploited, the use-after-free corrupts freed slab and percpu memory, takes a spinlock in freed storage, and queues a work item with a stale function pointer, reliably producing a kernel oops/panic."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T12:03:10.424Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/a2048e475e22b13dc3e53d485b7e6e11464ed9a6"
},
{
"url": "https://git.kernel.org/stable/c/73f132e60857038416540c3599b1de6033d7575a"
},
{
"url": "https://git.kernel.org/stable/c/609e59193fc6d9dd323f1c6ae1fdd721f1c79680"
},
{
"url": "https://git.kernel.org/stable/c/a11a12a9880ab37342b73c93cfe1a3ada02ff0db"
},
{
"url": "https://git.kernel.org/stable/c/f231d5d001ec75f5886c02d496a4c79edc383d45"
},
{
"url": "https://git.kernel.org/stable/c/dbe3e911a59bda6de96e7cae387ff882c2c177fa"
},
{
"url": "https://git.kernel.org/stable/c/cdf79bd2e1ecb3cc75631c73d8f4149be6019a52"
},
{
"url": "https://git.kernel.org/stable/c/71203f68c7749609d7fc8ae6ad054bdedeb24f91"
}
],
"title": "padata: Fix pd UAF once and for all",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-38584",
"datePublished": "2025-08-19T17:03:06.172Z",
"dateReserved": "2025-04-16T04:51:24.026Z",
"dateUpdated": "2026-10-15T22:02:26.071Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2026-AVI-1298
Vulnerability from certfr_avis - Published: 2026-10-13 - Updated: 2026-10-13
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 | SIMATIC | SIMATIC ET 200SP CPU 1514SPT-2 PN (6ES7514-2VN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC S7 PLCs Web Server toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1514SP F-2 PN (6ES7514-2SN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Unified Comfort Panel hygienic (6AV2128-3UB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3XB27-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC S7 Webserver API versions antérieures à 3.3.62 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Unified Comfort Panel neutral design (6AV2128-3UB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC WinCC V8.1 versions antérieures à 8.1.7 | ||
| Siemens | SIMATIC | SIMATIC IPC127E Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3QB57-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Unified Comfort Panel hygienic (6AV2128-3MB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SCALANCE | SCALANCE LPE9413 (6GK5998-3GS01-2AC2) toutes versions pour la vulnérabilité CVE-2026-44414 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DK03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs - Windows OS toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3MB57-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC427E Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC S7-1500 versions supérieures ou égales à3.1.7 pour les vulnérabilités CVE-2021-41617, CVE-2023-28531, CVE-2023-51384, CVE-2023-52927, CVE-2023-53292, CVE-2024-26783, CVE-2024-27056, CVE-2024-28956, CVE-2024-36903, CVE-2024-36927, CVE-2024-42079, CVE-2024-46786, CVE-2024-47736, CVE-2024-47809, CVE-2024-49968, CVE-2024-49994, CVE-2024-49998, CVE-2024-50014, CVE-2024-50063, CVE-2024-50164, CVE-2024-50298, CVE-2024-53124, CVE-2024-53170, CVE-2024-54458, CVE-2024-56631, CVE-2024-56703, CVE-2024-56719, CVE-2024-57917, CVE-2024-57924, CVE-2024-57973, CVE-2024-57977, CVE-2024-57979, CVE-2024-58011, CVE-2024-58016, CVE-2024-58020, CVE-2024-58056, CVE-2024-58058, CVE-2024-58061, CVE-2024-58086, CVE-2025-21645, CVE-2025-21648, CVE-2025-21655, CVE-2025-21676, CVE-2025-21682, CVE-2025-21702, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21718, CVE-2025-21731, CVE-2025-21745, CVE-2025-21758, CVE-2025-21760, CVE-2025-21764, CVE-2025-21765, CVE-2025-21780, CVE-2025-21795, CVE-2025-21796, CVE-2025-21802, CVE-2025-21814, CVE-2025-21846, CVE-2025-21853, CVE-2025-21861, CVE-2025-21863, CVE-2025-21864, CVE-2025-21867, CVE-2025-21875, CVE-2025-21887, CVE-2025-21913, CVE-2025-21919, CVE-2025-21925, CVE-2025-21926, CVE-2025-21938, CVE-2025-21959, CVE-2025-21999, CVE-2025-22005, CVE-2025-22015, CVE-2025-22055, CVE-2025-22056, CVE-2025-22060, CVE-2025-22083, CVE-2025-22090, CVE-2025-22095, CVE-2025-22107, CVE-2025-22111, CVE-2025-22121, CVE-2025-23136, CVE-2025-23143, CVE-2025-37785, CVE-2025-37909, CVE-2025-37917, CVE-2025-37945, CVE-2025-37959, CVE-2025-37964, CVE-2025-37972, CVE-2025-37980, CVE-2025-38125, CVE-2025-38162, CVE-2025-38192, CVE-2025-38201, CVE-2025-38232, CVE-2025-38322, CVE-2025-38591, CVE-2025-38614, CVE-2025-38681, CVE-2025-38704, CVE-2025-38721, CVE-2025-38725, CVE-2025-38727, CVE-2025-38732, CVE-2025-38736, CVE-2025-39681, CVE-2025-39691, CVE-2025-39721, CVE-2025-39748, CVE-2025-39756, CVE-2025-39764, CVE-2025-39770, CVE-2025-39773, CVE-2025-39782, CVE-2025-39795, CVE-2025-39826, CVE-2025-39827, CVE-2025-39845, CVE-2025-39866, CVE-2025-39871, CVE-2025-39931, CVE-2025-39953, CVE-2025-39955, CVE-2025-39964, CVE-2025-39977, CVE-2025-39978, CVE-2025-39980, CVE-2025-40022, CVE-2025-40070, CVE-2025-40078, CVE-2025-40080, CVE-2025-40105, CVE-2025-40135, CVE-2025-40149, CVE-2025-40196, CVE-2025-40219, CVE-2025-40261, CVE-2025-40300, CVE-2025-61984, CVE-2025-61985, CVE-2025-68206, CVE-2025-68261, CVE-2025-68264, CVE-2025-68265, CVE-2025-68266, CVE-2025-68291, CVE-2025-68337, CVE-2025-68349, CVE-2025-68363, CVE-2025-68371, CVE-2025-68724, CVE-2025-68725, CVE-2025-68742, CVE-2025-68764, CVE-2025-68773, CVE-2025-68776, CVE-2025-68782, CVE-2025-68787, CVE-2025-68788, CVE-2025-68798, CVE-2025-68803, CVE-2025-68814, CVE-2025-68816, CVE-2025-68818, CVE-2025-68820, CVE-2025-71064, CVE-2025-71075, CVE-2025-71079, CVE-2025-71085, CVE-2025-71086, CVE-2025-71088, CVE-2025-71095, CVE-2025-71097, CVE-2025-71098, CVE-2025-71104, CVE-2025-71112, CVE-2025-71113, CVE-2025-71114, CVE-2025-71120, CVE-2025-71123, CVE-2025-71131, CVE-2025-71161, CVE-2025-71162, CVE-2025-71163, CVE-2025-71185, CVE-2025-71186, CVE-2025-71189, CVE-2025-71190, CVE-2025-71191, CVE-2025-71197, CVE-2025-71221, CVE-2025-71265, CVE-2025-71266, CVE-2025-71267, CVE-2026-3497, CVE-2026-22977, CVE-2026-22979, CVE-2026-22980, CVE-2026-22982, CVE-2026-22992, CVE-2026-22994, CVE-2026-23003, CVE-2026-23005, CVE-2026-23010, CVE-2026-23011, CVE-2026-23019, CVE-2026-23026, CVE-2026-23038, CVE-2026-23054, CVE-2026-23060, CVE-2026-23083, CVE-2026-23084, CVE-2026-23086, CVE-2026-23087, CVE-2026-23095, CVE-2026-23100, CVE-2026-23103, CVE-2026-23110, CVE-2026-23111, CVE-2026-23113, CVE-2026-23154, CVE-2026-23204, CVE-2026-23231, CVE-2026-23242, CVE-2026-23243, CVE-2026-23245, CVE-2026-23255, CVE-2026-23270, CVE-2026-23271, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23284, CVE-2026-23287, CVE-2026-23290, CVE-2026-23293, CVE-2026-23300, CVE-2026-23304, CVE-2026-23319, CVE-2026-23321, CVE-2026-23335, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23359, CVE-2026-23365, CVE-2026-23368, CVE-2026-23370, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23391, CVE-2026-23392, CVE-2026-23397, CVE-2026-23398, CVE-2026-23399, CVE-2026-23414, CVE-2026-23422, CVE-2026-23434, CVE-2026-23438, CVE-2026-23439, CVE-2026-23446, CVE-2026-23449, CVE-2026-23450, CVE-2026-23452, CVE-2026-23454, CVE-2026-23455, CVE-2026-23456, CVE-2026-23457, CVE-2026-23458, CVE-2026-23463, CVE-2026-23474, CVE-2026-23475, CVE-2026-27135, CVE-2026-31389, CVE-2026-31391, CVE-2026-31396, CVE-2026-31402, CVE-2026-31403, CVE-2026-31411, CVE-2026-31414, CVE-2026-31415, CVE-2026-31416, CVE-2026-31417, CVE-2026-31418, CVE-2026-31421, CVE-2026-31422, CVE-2026-31423, CVE-2026-31424, CVE-2026-31427, CVE-2026-31428, CVE-2026-31441, CVE-2026-31446, CVE-2026-31447, CVE-2026-31448, CVE-2026-31449, CVE-2026-31450, CVE-2026-31452, CVE-2026-31466, CVE-2026-31469, CVE-2026-31485, CVE-2026-31494, CVE-2026-31495, CVE-2026-31496, CVE-2026-31503, CVE-2026-31504, CVE-2026-31507, CVE-2026-31508, CVE-2026-31515, CVE-2026-31518, CVE-2026-31521, CVE-2026-31533, CVE-2026-31546, CVE-2026-31555, CVE-2026-31563, CVE-2026-31565, CVE-2026-31628, CVE-2026-31634, CVE-2026-31649, CVE-2026-31651, CVE-2026-31658, CVE-2026-31664, CVE-2026-31665, CVE-2026-31669, CVE-2026-31670, CVE-2026-31671, CVE-2026-31674, CVE-2026-31680, CVE-2026-31681, CVE-2026-31682, CVE-2026-31700, CVE-2026-31737, CVE-2026-31752, CVE-2026-31761, CVE-2026-31768, CVE-2026-40355, CVE-2026-41989, CVE-2026-43011, CVE-2026-43024, CVE-2026-43025, CVE-2026-43026, CVE-2026-43027, CVE-2026-43028, CVE-2026-43030, CVE-2026-43033, CVE-2026-43035, CVE-2026-43038, CVE-2026-43040, CVE-2026-43057, CVE-2026-43071, CVE-2026-43085, CVE-2026-43089, CVE-2026-43116, CVE-2026-43216, CVE-2026-43303, CVE-2026-43492, CVE-2026-43499, CVE-2026-43501, CVE-2026-45841, CVE-2026-46015, CVE-2026-46021, CVE-2026-46033, CVE-2026-46037, CVE-2026-46040, CVE-2026-46046, CVE-2026-46086, CVE-2026-46101, CVE-2026-46116, CVE-2026-46132, CVE-2026-46172, CVE-2026-46173, CVE-2026-46174, CVE-2026-46193, CVE-2026-46303, CVE-2026-46306, CVE-2026-46323, CVE-2026-46333, CVE-2026-52910, CVE-2026-52912, CVE-2026-52930, CVE-2026-52933, CVE-2026-52942, CVE-2026-52943, CVE-2026-52946, CVE-2026-52970, CVE-2026-52986, CVE-2026-52998, CVE-2026-52999, CVE-2026-53001, CVE-2026-53002, CVE-2026-53006, CVE-2026-53012, CVE-2026-53050, CVE-2026-53134, CVE-2026-53218, CVE-2026-53219, CVE-2026-53223, CVE-2026-53236, CVE-2026-53239, CVE-2026-53249, CVE-2026-53268, CVE-2026-53269, CVE-2026-53275, CVE-2026-53295, CVE-2026-53352, CVE-2026-53400, CVE-2026-63810, CVE-2026-64279, CVE-2026-64317, CVE-2026-64370, CVE-2026-64371, CVE-2026-64375, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413, CVE-2026-64422, CVE-2026-64423, CVE-2026-64425, CVE-2026-64538, CVE-2026-64545, CVE-2026-64552 et CVE-2026-64560. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3XB57-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Unified Comfort Panel hygienic (6AV2128-3QB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DM03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK01-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3UB27-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1514SP-2 PN (6ES7514-2DN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Unified Comfort Panel neutral design (6AV2128-3QB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1000, Unified Comfort Panel neutral (6AV2128-3KB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC WinCC V7.5 toutes versions pour la vulnérabilité CVE-2026-59241 | ||
| Siemens | SIMATIC | SIMATIC WinCC V8.0 versions antérieures à 8.0.0.11 | ||
| Siemens | SIMATIC | SIMATIC IoT2050 Advanced IED (6ES7647-0BW00-1YA2) versions antérieures à 1.28.1.2 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3QB27-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Unified Comfort Panel hygienic neutral design (6AV2128-3QB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC227E Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1000 Unified Comfort Panel hygienic neutral design (6AV2128-3KB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3UB57-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Unified Comfort Hygienic (6AV2128-3XB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SM03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Unified Comfort Panel hygienic neutral design (6AV2128-3MB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3XB27-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC227G / IPC277G / IPC277G PRO / IPC327G / IPC377G versions antérieures à 28.01.15 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3UB27-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3UB27-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK01-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC IPC BX-21A Industrial Edge Device versions antérieures à 1.28.1.2 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP700 Unified Comfort Panel (6AV2128-3GB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3QB27-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Unified Comfort Panel (6AV2128-3MB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Unified Comfort Panel (6AV2128-3UB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC227G Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC S7 Webserver API versions antérieures à 3.3.61 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3UB57-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | Desigo | Desigo PXC/PXM versions supérieures ou égales à2.3. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2026-89208. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Unified Comfort Panel (6AV2128-3QB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3UB57-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3XB57-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ01-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V2 CPUs - Windows OS toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC (incl. SIPLUS variants) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3XB27-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC Drive Controller CPU 1507D TF (6ES7615-7DF10-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3MB27-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC S7-1500 TM MFP toutes versions pour les vulnérabilités CVE-2023-52927, CVE-2023-53292, CVE-2023-54271, CVE-2024-26982, CVE-2024-36922, CVE-2024-40945, CVE-2024-47809, CVE-2024-49998, CVE-2024-53166, CVE-2024-56647, CVE-2024-56657, CVE-2024-56719, CVE-2024-57977, CVE-2024-57979, CVE-2024-57980, CVE-2024-57981, CVE-2024-57986, CVE-2024-57993, CVE-2024-57996, CVE-2024-58002, CVE-2024-58005, CVE-2024-58009, CVE-2024-58013, CVE-2024-58014, CVE-2024-58017, CVE-2024-58020, CVE-2024-58058, CVE-2024-58061, CVE-2024-58063, CVE-2024-58068, CVE-2024-58071, CVE-2024-58072, CVE-2024-58077, CVE-2024-58079, CVE-2024-58083, CVE-2025-21682, CVE-2025-21700, CVE-2025-21702, CVE-2025-21703, CVE-2025-21704, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21708, CVE-2025-21716, CVE-2025-21719, CVE-2025-21724, CVE-2025-21725, CVE-2025-21726, CVE-2025-21727, CVE-2025-21728, CVE-2025-21731, CVE-2025-21735, CVE-2025-21738, CVE-2025-21744, CVE-2025-21745, CVE-2025-21753, CVE-2025-21756, CVE-2025-21758, CVE-2025-21760, CVE-2025-21761, CVE-2025-21762, CVE-2025-21763, CVE-2025-21764, CVE-2025-21765, CVE-2025-21766, CVE-2025-21767, CVE-2025-21776, CVE-2025-21779, CVE-2025-21787, CVE-2025-21790, CVE-2025-21791, CVE-2025-21795, CVE-2025-21796, CVE-2025-21806, CVE-2025-21814, CVE-2025-21830, CVE-2025-21832, CVE-2025-21835, CVE-2025-21838, CVE-2025-21844, CVE-2025-21846, CVE-2025-21858, CVE-2025-21859, CVE-2025-21862, CVE-2025-21863, CVE-2025-21864, CVE-2025-21865, CVE-2025-22105, CVE-2025-23131, CVE-2025-38105, CVE-2025-38162, CVE-2025-38192, CVE-2025-38250, CVE-2025-38584, CVE-2025-38704, CVE-2025-39748, CVE-2025-39863, CVE-2025-39997, CVE-2025-40135, CVE-2025-68206, CVE-2025-68239, CVE-2025-68265, CVE-2026-23066, CVE-2026-23100, CVE-2026-23113, CVE-2026-23141, CVE-2026-23154, CVE-2026-23157, CVE-2026-23204, CVE-2026-23231, CVE-2026-23245, CVE-2026-23253, CVE-2026-23255, CVE-2026-23270, CVE-2026-23271, CVE-2026-23272, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23278, CVE-2026-23279, CVE-2026-23281, CVE-2026-23290, CVE-2026-23291, CVE-2026-23292, CVE-2026-23296, CVE-2026-23300, CVE-2026-23302, CVE-2026-23303, CVE-2026-23304, CVE-2026-23310, CVE-2026-23312, CVE-2026-23315, CVE-2026-23317, CVE-2026-23318, CVE-2026-23319, CVE-2026-23321, CVE-2026-23336, CVE-2026-23339, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23352, CVE-2026-23356, CVE-2026-23357, CVE-2026-23359, CVE-2026-23364, CVE-2026-23365, CVE-2026-23367, CVE-2026-23368, CVE-2026-23370, CVE-2026-23372, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23382, CVE-2026-23388, CVE-2026-23389, CVE-2026-23391, CVE-2026-23392, CVE-2026-23395, CVE-2026-23396, CVE-2026-23397, CVE-2026-23398, CVE-2026-23399, CVE-2026-23442, CVE-2026-23444, CVE-2026-31407, CVE-2026-31449, CVE-2026-31451, CVE-2026-31488, CVE-2026-31500, CVE-2026-31532, CVE-2026-31580, CVE-2026-31583, CVE-2026-31586, CVE-2026-31611, CVE-2026-31612, CVE-2026-31613, CVE-2026-31617, CVE-2026-31622, CVE-2026-31624, CVE-2026-31625, CVE-2026-31629, CVE-2026-31630, CVE-2026-31637, CVE-2026-31642, CVE-2026-31673, CVE-2026-31676, CVE-2026-31681, CVE-2026-31685, CVE-2026-31694, CVE-2026-31696, CVE-2026-31697, CVE-2026-31698, CVE-2026-31699, CVE-2026-31700, CVE-2026-31704, CVE-2026-31705, CVE-2026-31708, CVE-2026-31709, CVE-2026-31711, CVE-2026-31712, CVE-2026-43052, CVE-2026-43071, CVE-2026-43074, CVE-2026-43080, CVE-2026-43085, CVE-2026-43089, CVE-2026-43093, CVE-2026-43094, CVE-2026-43099, CVE-2026-43110, CVE-2026-43111, CVE-2026-43112, CVE-2026-43114, CVE-2026-43116, CVE-2026-43117, CVE-2026-43303, CVE-2026-43350, CVE-2026-43421, CVE-2026-43492, CVE-2026-43493, CVE-2026-43496, CVE-2026-43499, CVE-2026-43502, CVE-2026-43503, CVE-2026-45834, CVE-2026-45835, CVE-2026-45836, CVE-2026-45838, CVE-2026-45839, CVE-2026-45840, CVE-2026-45841, CVE-2026-45842, CVE-2026-45843, CVE-2026-45844, CVE-2026-45850, CVE-2026-45991, CVE-2026-45997, CVE-2026-46003, CVE-2026-46015, CVE-2026-46018, CVE-2026-46021, CVE-2026-46022, CVE-2026-46023, CVE-2026-46026, CVE-2026-46033, CVE-2026-46037, CVE-2026-46038, CVE-2026-46040, CVE-2026-46044, CVE-2026-46046, CVE-2026-46047, CVE-2026-46050, CVE-2026-46051, CVE-2026-46056, CVE-2026-46064, CVE-2026-46065, CVE-2026-46069, CVE-2026-46070, CVE-2026-46083, CVE-2026-46086, CVE-2026-46088, CVE-2026-46092, CVE-2026-46099, CVE-2026-46101, CVE-2026-46102, CVE-2026-46107, CVE-2026-46110, CVE-2026-46113, CVE-2026-46116, CVE-2026-46120, CVE-2026-46122, CVE-2026-46124, CVE-2026-46125, CVE-2026-46128, CVE-2026-46136, CVE-2026-46137, CVE-2026-46146, CVE-2026-46149, CVE-2026-46150, CVE-2026-46151, CVE-2026-46159, CVE-2026-46161, CVE-2026-46163, CVE-2026-46165, CVE-2026-46167, CVE-2026-46168, CVE-2026-46172, CVE-2026-46173, CVE-2026-46177, CVE-2026-46180, CVE-2026-46185, CVE-2026-46187, CVE-2026-46190, CVE-2026-46191, CVE-2026-46193, CVE-2026-46195, CVE-2026-46196, CVE-2026-46209, CVE-2026-46214, CVE-2026-46227, CVE-2026-46234, CVE-2026-46243, CVE-2026-46275, CVE-2026-46294, CVE-2026-46303, CVE-2026-46304, CVE-2026-46306, CVE-2026-46307, CVE-2026-46320, CVE-2026-46321, CVE-2026-46322, CVE-2026-46323, CVE-2026-46331, CVE-2026-52909, CVE-2026-52910, CVE-2026-52917, CVE-2026-52918, CVE-2026-52923, CVE-2026-52928, CVE-2026-52929, CVE-2026-52930, CVE-2026-52942, CVE-2026-52943, CVE-2026-52946, CVE-2026-52947, CVE-2026-52948, CVE-2026-53080, CVE-2026-53131, CVE-2026-53146, CVE-2026-53147, CVE-2026-53148, CVE-2026-53149, CVE-2026-53150, CVE-2026-53167, CVE-2026-53168, CVE-2026-53177, CVE-2026-53181, CVE-2026-53183, CVE-2026-53184, CVE-2026-53192, CVE-2026-53198, CVE-2026-53208, CVE-2026-53212, CVE-2026-53218, CVE-2026-53219, CVE-2026-53221, CVE-2026-53225, CVE-2026-53227, CVE-2026-53228, CVE-2026-53236, CVE-2026-53239, CVE-2026-53242, CVE-2026-53245, CVE-2026-53249, CVE-2026-53253, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256, CVE-2026-53263, CVE-2026-53264, CVE-2026-53265, CVE-2026-53268, CVE-2026-53269, CVE-2026-53275, CVE-2026-53325, CVE-2026-53337, CVE-2026-53349, CVE-2026-53350, CVE-2026-53352, CVE-2026-53356, CVE-2026-53358, CVE-2026-53362 et CVE-2026-64560. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1900 Unified Comfort Panel hygienic neutral design (6AV2128-3UB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC BX-59A Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP700, Unified Comfort Panel neutral design (6AV2128-3GB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC3 V4 CPUs toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3QB57-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1000 Unified Comfort Panel hygienic (6AV2128-3KB40-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SK03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Unified Comfort Panel neutral design (6AV2128-3XB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IoT2050 SM IED (6ES7647-0CW00-1AA2) versions antérieures à 1.28.1.2 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3QB27-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Unified Comfort Panel neutral design (6AV2128-3MB36-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3MB27-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC BX-21A versions antérieures à 31.01.13 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3MB57-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC IPC RW-543A versions antérieures à 1.1.4 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3XB57-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SCALANCE | SCALANCE LPE9433 (6GK5998-3GS11-2AC2) toutes versions pour la vulnérabilité CVE-2026-44414 | ||
| Siemens | SIMATIC | SIMATIC IPC847E Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3QB57-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1000 Unified Comfort Panel (6AV2128-3KB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1514SPT F-2 PN (6ES7514-2WN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3MB27-1BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs - Industrial OS toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC IPC BX-39A Industrial Edge Device versions antérieures à 3.2.0.17 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Unified Comfort Hygienic neutral design (6AV2128-3XB70-0AX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3MB57-0BX0) toutes versions pour la vulnérabilité CVE-2026-44415 | ||
| Siemens | SIMATIC | SIMATIC Drive Controller CPU 1504D TF (6ES7615-4DF10-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ01-0AB0) toutes versions pour les vulnérabilités CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357. | ||
| Siemens | SIMATIC | SIMATIC HMI MTP2200 Unified Comfort Panel (6AV2128-3XB06-0AX1) toutes versions pour la vulnérabilité CVE-2026-44415 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SIMATIC ET 200SP CPU 1514SPT-2 PN (6ES7514-2VN03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 PLCs Web Server toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1514SP F-2 PN (6ES7514-2SN03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel hygienic (6AV2128-3UB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3XB27-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 Webserver API versions ant\u00e9rieures \u00e0 3.3.62",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel neutral design (6AV2128-3UB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V8.1 versions ant\u00e9rieures \u00e0 8.1.7",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC127E Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3QB57-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel hygienic (6AV2128-3MB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE LPE9413 (6GK5998-3GS01-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44414",
"product": {
"name": "SCALANCE",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DK03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs - Windows OS toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3MB57-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC427E Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 versions sup\u00e9rieures ou \u00e9gales \u00e03.1.7 pour les vuln\u00e9rabilit\u00e9s CVE-2021-41617, CVE-2023-28531, CVE-2023-51384, CVE-2023-52927, CVE-2023-53292, CVE-2024-26783, CVE-2024-27056, CVE-2024-28956, CVE-2024-36903, CVE-2024-36927, CVE-2024-42079, CVE-2024-46786, CVE-2024-47736, CVE-2024-47809, CVE-2024-49968, CVE-2024-49994, CVE-2024-49998, CVE-2024-50014, CVE-2024-50063, CVE-2024-50164, CVE-2024-50298, CVE-2024-53124, CVE-2024-53170, CVE-2024-54458, CVE-2024-56631, CVE-2024-56703, CVE-2024-56719, CVE-2024-57917, CVE-2024-57924, CVE-2024-57973, CVE-2024-57977, CVE-2024-57979, CVE-2024-58011, CVE-2024-58016, CVE-2024-58020, CVE-2024-58056, CVE-2024-58058, CVE-2024-58061, CVE-2024-58086, CVE-2025-21645, CVE-2025-21648, CVE-2025-21655, CVE-2025-21676, CVE-2025-21682, CVE-2025-21702, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21718, CVE-2025-21731, CVE-2025-21745, CVE-2025-21758, CVE-2025-21760, CVE-2025-21764, CVE-2025-21765, CVE-2025-21780, CVE-2025-21795, CVE-2025-21796, CVE-2025-21802, CVE-2025-21814, CVE-2025-21846, CVE-2025-21853, CVE-2025-21861, CVE-2025-21863, CVE-2025-21864, CVE-2025-21867, CVE-2025-21875, CVE-2025-21887, CVE-2025-21913, CVE-2025-21919, CVE-2025-21925, CVE-2025-21926, CVE-2025-21938, CVE-2025-21959, CVE-2025-21999, CVE-2025-22005, CVE-2025-22015, CVE-2025-22055, CVE-2025-22056, CVE-2025-22060, CVE-2025-22083, CVE-2025-22090, CVE-2025-22095, CVE-2025-22107, CVE-2025-22111, CVE-2025-22121, CVE-2025-23136, CVE-2025-23143, CVE-2025-37785, CVE-2025-37909, CVE-2025-37917, CVE-2025-37945, CVE-2025-37959, CVE-2025-37964, CVE-2025-37972, CVE-2025-37980, CVE-2025-38125, CVE-2025-38162, CVE-2025-38192, CVE-2025-38201, CVE-2025-38232, CVE-2025-38322, CVE-2025-38591, CVE-2025-38614, CVE-2025-38681, CVE-2025-38704, CVE-2025-38721, CVE-2025-38725, CVE-2025-38727, CVE-2025-38732, CVE-2025-38736, CVE-2025-39681, CVE-2025-39691, CVE-2025-39721, CVE-2025-39748, CVE-2025-39756, CVE-2025-39764, CVE-2025-39770, CVE-2025-39773, CVE-2025-39782, CVE-2025-39795, CVE-2025-39826, CVE-2025-39827, CVE-2025-39845, CVE-2025-39866, CVE-2025-39871, CVE-2025-39931, CVE-2025-39953, CVE-2025-39955, CVE-2025-39964, CVE-2025-39977, CVE-2025-39978, CVE-2025-39980, CVE-2025-40022, CVE-2025-40070, CVE-2025-40078, CVE-2025-40080, CVE-2025-40105, CVE-2025-40135, CVE-2025-40149, CVE-2025-40196, CVE-2025-40219, CVE-2025-40261, CVE-2025-40300, CVE-2025-61984, CVE-2025-61985, CVE-2025-68206, CVE-2025-68261, CVE-2025-68264, CVE-2025-68265, CVE-2025-68266, CVE-2025-68291, CVE-2025-68337, CVE-2025-68349, CVE-2025-68363, CVE-2025-68371, CVE-2025-68724, CVE-2025-68725, CVE-2025-68742, CVE-2025-68764, CVE-2025-68773, CVE-2025-68776, CVE-2025-68782, CVE-2025-68787, CVE-2025-68788, CVE-2025-68798, CVE-2025-68803, CVE-2025-68814, CVE-2025-68816, CVE-2025-68818, CVE-2025-68820, CVE-2025-71064, CVE-2025-71075, CVE-2025-71079, CVE-2025-71085, CVE-2025-71086, CVE-2025-71088, CVE-2025-71095, CVE-2025-71097, CVE-2025-71098, CVE-2025-71104, CVE-2025-71112, CVE-2025-71113, CVE-2025-71114, CVE-2025-71120, CVE-2025-71123, CVE-2025-71131, CVE-2025-71161, CVE-2025-71162, CVE-2025-71163, CVE-2025-71185, CVE-2025-71186, CVE-2025-71189, CVE-2025-71190, CVE-2025-71191, CVE-2025-71197, CVE-2025-71221, CVE-2025-71265, CVE-2025-71266, CVE-2025-71267, CVE-2026-3497, CVE-2026-22977, CVE-2026-22979, CVE-2026-22980, CVE-2026-22982, CVE-2026-22992, CVE-2026-22994, CVE-2026-23003, CVE-2026-23005, CVE-2026-23010, CVE-2026-23011, CVE-2026-23019, CVE-2026-23026, CVE-2026-23038, CVE-2026-23054, CVE-2026-23060, CVE-2026-23083, CVE-2026-23084, CVE-2026-23086, CVE-2026-23087, CVE-2026-23095, CVE-2026-23100, CVE-2026-23103, CVE-2026-23110, CVE-2026-23111, CVE-2026-23113, CVE-2026-23154, CVE-2026-23204, CVE-2026-23231, CVE-2026-23242, CVE-2026-23243, CVE-2026-23245, CVE-2026-23255, CVE-2026-23270, CVE-2026-23271, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23284, CVE-2026-23287, CVE-2026-23290, CVE-2026-23293, CVE-2026-23300, CVE-2026-23304, CVE-2026-23319, CVE-2026-23321, CVE-2026-23335, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23359, CVE-2026-23365, CVE-2026-23368, CVE-2026-23370, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23391, CVE-2026-23392, CVE-2026-23397, CVE-2026-23398, CVE-2026-23399, CVE-2026-23414, CVE-2026-23422, CVE-2026-23434, CVE-2026-23438, CVE-2026-23439, CVE-2026-23446, CVE-2026-23449, CVE-2026-23450, CVE-2026-23452, CVE-2026-23454, CVE-2026-23455, CVE-2026-23456, CVE-2026-23457, CVE-2026-23458, CVE-2026-23463, CVE-2026-23474, CVE-2026-23475, CVE-2026-27135, CVE-2026-31389, CVE-2026-31391, CVE-2026-31396, CVE-2026-31402, CVE-2026-31403, CVE-2026-31411, CVE-2026-31414, CVE-2026-31415, CVE-2026-31416, CVE-2026-31417, CVE-2026-31418, CVE-2026-31421, CVE-2026-31422, CVE-2026-31423, CVE-2026-31424, CVE-2026-31427, CVE-2026-31428, CVE-2026-31441, CVE-2026-31446, CVE-2026-31447, CVE-2026-31448, CVE-2026-31449, CVE-2026-31450, CVE-2026-31452, CVE-2026-31466, CVE-2026-31469, CVE-2026-31485, CVE-2026-31494, CVE-2026-31495, CVE-2026-31496, CVE-2026-31503, CVE-2026-31504, CVE-2026-31507, CVE-2026-31508, CVE-2026-31515, CVE-2026-31518, CVE-2026-31521, CVE-2026-31533, CVE-2026-31546, CVE-2026-31555, CVE-2026-31563, CVE-2026-31565, CVE-2026-31628, CVE-2026-31634, CVE-2026-31649, CVE-2026-31651, CVE-2026-31658, CVE-2026-31664, CVE-2026-31665, CVE-2026-31669, CVE-2026-31670, CVE-2026-31671, CVE-2026-31674, CVE-2026-31680, CVE-2026-31681, CVE-2026-31682, CVE-2026-31700, CVE-2026-31737, CVE-2026-31752, CVE-2026-31761, CVE-2026-31768, CVE-2026-40355, CVE-2026-41989, CVE-2026-43011, CVE-2026-43024, CVE-2026-43025, CVE-2026-43026, CVE-2026-43027, CVE-2026-43028, CVE-2026-43030, CVE-2026-43033, CVE-2026-43035, CVE-2026-43038, CVE-2026-43040, CVE-2026-43057, CVE-2026-43071, CVE-2026-43085, CVE-2026-43089, CVE-2026-43116, CVE-2026-43216, CVE-2026-43303, CVE-2026-43492, CVE-2026-43499, CVE-2026-43501, CVE-2026-45841, CVE-2026-46015, CVE-2026-46021, CVE-2026-46033, CVE-2026-46037, CVE-2026-46040, CVE-2026-46046, CVE-2026-46086, CVE-2026-46101, CVE-2026-46116, CVE-2026-46132, CVE-2026-46172, CVE-2026-46173, CVE-2026-46174, CVE-2026-46193, CVE-2026-46303, CVE-2026-46306, CVE-2026-46323, CVE-2026-46333, CVE-2026-52910, CVE-2026-52912, CVE-2026-52930, CVE-2026-52933, CVE-2026-52942, CVE-2026-52943, CVE-2026-52946, CVE-2026-52970, CVE-2026-52986, CVE-2026-52998, CVE-2026-52999, CVE-2026-53001, CVE-2026-53002, CVE-2026-53006, CVE-2026-53012, CVE-2026-53050, CVE-2026-53134, CVE-2026-53218, CVE-2026-53219, CVE-2026-53223, CVE-2026-53236, CVE-2026-53239, CVE-2026-53249, CVE-2026-53268, CVE-2026-53269, CVE-2026-53275, CVE-2026-53295, CVE-2026-53352, CVE-2026-53400, CVE-2026-63810, CVE-2026-64279, CVE-2026-64317, CVE-2026-64370, CVE-2026-64371, CVE-2026-64375, CVE-2026-64411, CVE-2026-64412, CVE-2026-64413, CVE-2026-64422, CVE-2026-64423, CVE-2026-64425, CVE-2026-64538, CVE-2026-64545, CVE-2026-64552 et CVE-2026-64560.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3XB57-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel hygienic (6AV2128-3QB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DM03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK01-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3UB27-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1514SP-2 PN (6ES7514-2DN03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel neutral design (6AV2128-3QB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000, Unified Comfort Panel neutral (6AV2128-3KB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V7.5 toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-59241",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC WinCC V8.0 versions ant\u00e9rieures \u00e0 8.0.0.11",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IoT2050 Advanced IED (6ES7647-0BW00-1YA2) versions ant\u00e9rieures \u00e0 1.28.1.2",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3QB27-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel hygienic neutral design (6AV2128-3QB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC227E Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000 Unified Comfort Panel hygienic neutral design (6AV2128-3KB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3UB57-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Hygienic (6AV2128-3XB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SM03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel hygienic neutral design (6AV2128-3MB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3XB27-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC227G / IPC277G / IPC277G PRO / IPC327G / IPC377G versions ant\u00e9rieures \u00e0 28.01.15",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3UB27-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3UB27-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK01-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC BX-21A Industrial Edge Device versions ant\u00e9rieures \u00e0 1.28.1.2",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700 Unified Comfort Panel (6AV2128-3GB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3QB27-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel (6AV2128-3MB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel (6AV2128-3UB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC227G Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 Webserver API versions ant\u00e9rieures \u00e0 3.3.61",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3UB57-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "Desigo PXC/PXM versions sup\u00e9rieures ou \u00e9gales \u00e02.3. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2026-89208.",
"product": {
"name": "Desigo",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel (6AV2128-3QB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3UB57-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3XB57-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ01-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V2 CPUs - Windows OS toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC (incl. SIPLUS variants) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3XB27-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Drive Controller CPU 1507D TF (6ES7615-7DF10-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3MB27-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 TM MFP toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2023-52927, CVE-2023-53292, CVE-2023-54271, CVE-2024-26982, CVE-2024-36922, CVE-2024-40945, CVE-2024-47809, CVE-2024-49998, CVE-2024-53166, CVE-2024-56647, CVE-2024-56657, CVE-2024-56719, CVE-2024-57977, CVE-2024-57979, CVE-2024-57980, CVE-2024-57981, CVE-2024-57986, CVE-2024-57993, CVE-2024-57996, CVE-2024-58002, CVE-2024-58005, CVE-2024-58009, CVE-2024-58013, CVE-2024-58014, CVE-2024-58017, CVE-2024-58020, CVE-2024-58058, CVE-2024-58061, CVE-2024-58063, CVE-2024-58068, CVE-2024-58071, CVE-2024-58072, CVE-2024-58077, CVE-2024-58079, CVE-2024-58083, CVE-2025-21682, CVE-2025-21700, CVE-2025-21702, CVE-2025-21703, CVE-2025-21704, CVE-2025-21705, CVE-2025-21706, CVE-2025-21707, CVE-2025-21708, CVE-2025-21716, CVE-2025-21719, CVE-2025-21724, CVE-2025-21725, CVE-2025-21726, CVE-2025-21727, CVE-2025-21728, CVE-2025-21731, CVE-2025-21735, CVE-2025-21738, CVE-2025-21744, CVE-2025-21745, CVE-2025-21753, CVE-2025-21756, CVE-2025-21758, CVE-2025-21760, CVE-2025-21761, CVE-2025-21762, CVE-2025-21763, CVE-2025-21764, CVE-2025-21765, CVE-2025-21766, CVE-2025-21767, CVE-2025-21776, CVE-2025-21779, CVE-2025-21787, CVE-2025-21790, CVE-2025-21791, CVE-2025-21795, CVE-2025-21796, CVE-2025-21806, CVE-2025-21814, CVE-2025-21830, CVE-2025-21832, CVE-2025-21835, CVE-2025-21838, CVE-2025-21844, CVE-2025-21846, CVE-2025-21858, CVE-2025-21859, CVE-2025-21862, CVE-2025-21863, CVE-2025-21864, CVE-2025-21865, CVE-2025-22105, CVE-2025-23131, CVE-2025-38105, CVE-2025-38162, CVE-2025-38192, CVE-2025-38250, CVE-2025-38584, CVE-2025-38704, CVE-2025-39748, CVE-2025-39863, CVE-2025-39997, CVE-2025-40135, CVE-2025-68206, CVE-2025-68239, CVE-2025-68265, CVE-2026-23066, CVE-2026-23100, CVE-2026-23113, CVE-2026-23141, CVE-2026-23154, CVE-2026-23157, CVE-2026-23204, CVE-2026-23231, CVE-2026-23245, CVE-2026-23253, CVE-2026-23255, CVE-2026-23270, CVE-2026-23271, CVE-2026-23272, CVE-2026-23273, CVE-2026-23274, CVE-2026-23277, CVE-2026-23278, CVE-2026-23279, CVE-2026-23281, CVE-2026-23290, CVE-2026-23291, CVE-2026-23292, CVE-2026-23296, CVE-2026-23300, CVE-2026-23302, CVE-2026-23303, CVE-2026-23304, CVE-2026-23310, CVE-2026-23312, CVE-2026-23315, CVE-2026-23317, CVE-2026-23318, CVE-2026-23319, CVE-2026-23321, CVE-2026-23336, CVE-2026-23339, CVE-2026-23340, CVE-2026-23343, CVE-2026-23351, CVE-2026-23352, CVE-2026-23356, CVE-2026-23357, CVE-2026-23359, CVE-2026-23364, CVE-2026-23365, CVE-2026-23367, CVE-2026-23368, CVE-2026-23370, CVE-2026-23372, CVE-2026-23378, CVE-2026-23379, CVE-2026-23381, CVE-2026-23382, CVE-2026-23388, CVE-2026-23389, CVE-2026-23391, CVE-2026-23392, CVE-2026-23395, CVE-2026-23396, CVE-2026-23397, CVE-2026-23398, CVE-2026-23399, CVE-2026-23442, CVE-2026-23444, CVE-2026-31407, CVE-2026-31449, CVE-2026-31451, CVE-2026-31488, CVE-2026-31500, CVE-2026-31532, CVE-2026-31580, CVE-2026-31583, CVE-2026-31586, CVE-2026-31611, CVE-2026-31612, CVE-2026-31613, CVE-2026-31617, CVE-2026-31622, CVE-2026-31624, CVE-2026-31625, CVE-2026-31629, CVE-2026-31630, CVE-2026-31637, CVE-2026-31642, CVE-2026-31673, CVE-2026-31676, CVE-2026-31681, CVE-2026-31685, CVE-2026-31694, CVE-2026-31696, CVE-2026-31697, CVE-2026-31698, CVE-2026-31699, CVE-2026-31700, CVE-2026-31704, CVE-2026-31705, CVE-2026-31708, CVE-2026-31709, CVE-2026-31711, CVE-2026-31712, CVE-2026-43052, CVE-2026-43071, CVE-2026-43074, CVE-2026-43080, CVE-2026-43085, CVE-2026-43089, CVE-2026-43093, CVE-2026-43094, CVE-2026-43099, CVE-2026-43110, CVE-2026-43111, CVE-2026-43112, CVE-2026-43114, CVE-2026-43116, CVE-2026-43117, CVE-2026-43303, CVE-2026-43350, CVE-2026-43421, CVE-2026-43492, CVE-2026-43493, CVE-2026-43496, CVE-2026-43499, CVE-2026-43502, CVE-2026-43503, CVE-2026-45834, CVE-2026-45835, CVE-2026-45836, CVE-2026-45838, CVE-2026-45839, CVE-2026-45840, CVE-2026-45841, CVE-2026-45842, CVE-2026-45843, CVE-2026-45844, CVE-2026-45850, CVE-2026-45991, CVE-2026-45997, CVE-2026-46003, CVE-2026-46015, CVE-2026-46018, CVE-2026-46021, CVE-2026-46022, CVE-2026-46023, CVE-2026-46026, CVE-2026-46033, CVE-2026-46037, CVE-2026-46038, CVE-2026-46040, CVE-2026-46044, CVE-2026-46046, CVE-2026-46047, CVE-2026-46050, CVE-2026-46051, CVE-2026-46056, CVE-2026-46064, CVE-2026-46065, CVE-2026-46069, CVE-2026-46070, CVE-2026-46083, CVE-2026-46086, CVE-2026-46088, CVE-2026-46092, CVE-2026-46099, CVE-2026-46101, CVE-2026-46102, CVE-2026-46107, CVE-2026-46110, CVE-2026-46113, CVE-2026-46116, CVE-2026-46120, CVE-2026-46122, CVE-2026-46124, CVE-2026-46125, CVE-2026-46128, CVE-2026-46136, CVE-2026-46137, CVE-2026-46146, CVE-2026-46149, CVE-2026-46150, CVE-2026-46151, CVE-2026-46159, CVE-2026-46161, CVE-2026-46163, CVE-2026-46165, CVE-2026-46167, CVE-2026-46168, CVE-2026-46172, CVE-2026-46173, CVE-2026-46177, CVE-2026-46180, CVE-2026-46185, CVE-2026-46187, CVE-2026-46190, CVE-2026-46191, CVE-2026-46193, CVE-2026-46195, CVE-2026-46196, CVE-2026-46209, CVE-2026-46214, CVE-2026-46227, CVE-2026-46234, CVE-2026-46243, CVE-2026-46275, CVE-2026-46294, CVE-2026-46303, CVE-2026-46304, CVE-2026-46306, CVE-2026-46307, CVE-2026-46320, CVE-2026-46321, CVE-2026-46322, CVE-2026-46323, CVE-2026-46331, CVE-2026-52909, CVE-2026-52910, CVE-2026-52917, CVE-2026-52918, CVE-2026-52923, CVE-2026-52928, CVE-2026-52929, CVE-2026-52930, CVE-2026-52942, CVE-2026-52943, CVE-2026-52946, CVE-2026-52947, CVE-2026-52948, CVE-2026-53080, CVE-2026-53131, CVE-2026-53146, CVE-2026-53147, CVE-2026-53148, CVE-2026-53149, CVE-2026-53150, CVE-2026-53167, CVE-2026-53168, CVE-2026-53177, CVE-2026-53181, CVE-2026-53183, CVE-2026-53184, CVE-2026-53192, CVE-2026-53198, CVE-2026-53208, CVE-2026-53212, CVE-2026-53218, CVE-2026-53219, CVE-2026-53221, CVE-2026-53225, CVE-2026-53227, CVE-2026-53228, CVE-2026-53236, CVE-2026-53239, CVE-2026-53242, CVE-2026-53245, CVE-2026-53249, CVE-2026-53253, CVE-2026-53254, CVE-2026-53255, CVE-2026-53256, CVE-2026-53263, CVE-2026-53264, CVE-2026-53265, CVE-2026-53268, CVE-2026-53269, CVE-2026-53275, CVE-2026-53325, CVE-2026-53337, CVE-2026-53349, CVE-2026-53350, CVE-2026-53352, CVE-2026-53356, CVE-2026-53358, CVE-2026-53362 et CVE-2026-64560.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel hygienic neutral design (6AV2128-3UB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC BX-59A Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700, Unified Comfort Panel neutral design (6AV2128-3GB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC3 V4 CPUs toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3QB57-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000 Unified Comfort Panel hygienic (6AV2128-3KB40-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SK03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Panel neutral design (6AV2128-3XB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IoT2050 SM IED (6ES7647-0CW00-1AA2) versions ant\u00e9rieures \u00e0 1.28.1.2",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3QB27-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel neutral design (6AV2128-3MB36-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3MB27-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC BX-21A versions ant\u00e9rieures \u00e0 31.01.13",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3MB57-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC RW-543A versions ant\u00e9rieures \u00e0 1.1.4",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3XB57-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE LPE9433 (6GK5998-3GS11-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44414",
"product": {
"name": "SCALANCE",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC847E Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3QB57-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000 Unified Comfort Panel (6AV2128-3KB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1514SPT F-2 PN (6ES7514-2WN03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3MB27-1BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs - Industrial OS toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC IPC BX-39A Industrial Edge Device versions ant\u00e9rieures \u00e0 3.2.0.17",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Hygienic neutral design (6AV2128-3XB70-0AX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (expandable, round tube) and extension (6AV2128-3MB57-0BX0) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Drive Controller CPU 1504D TF (6ES7615-4DF10-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ01-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-63350, CVE-2026-63351, CVE-2026-63352, CVE-2026-63353, CVE-2026-63354, CVE-2026-63355, CVE-2026-63356 et CVE-2026-63357.",
"product": {
"name": "SIMATIC",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Panel (6AV2128-3XB06-0AX1) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2026-44415",
"product": {
"name": "SIMATIC",
"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-2024-36903",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36903"
},
{
"name": "CVE-2024-57981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57981"
},
{
"name": "CVE-2026-45842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45842"
},
{
"name": "CVE-2025-71075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71075"
},
{
"name": "CVE-2026-63356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63356"
},
{
"name": "CVE-2026-53192",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53192"
},
{
"name": "CVE-2026-27135",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27135"
},
{
"name": "CVE-2025-71086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71086"
},
{
"name": "CVE-2024-50063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50063"
},
{
"name": "CVE-2026-64552",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64552"
},
{
"name": "CVE-2026-53349",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53349"
},
{
"name": "CVE-2025-39997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39997"
},
{
"name": "CVE-2026-64538",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64538"
},
{
"name": "CVE-2025-22083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22083"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-38201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38201"
},
{
"name": "CVE-2025-22107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22107"
},
{
"name": "CVE-2026-31658",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31658"
},
{
"name": "CVE-2025-21682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21682"
},
{
"name": "CVE-2026-23318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23318"
},
{
"name": "CVE-2024-56703",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56703"
},
{
"name": "CVE-2026-53350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53350"
},
{
"name": "CVE-2026-23368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23368"
},
{
"name": "CVE-2026-46307",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46307"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2026-52929",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52929"
},
{
"name": "CVE-2025-68788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68788"
},
{
"name": "CVE-2023-28531",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28531"
},
{
"name": "CVE-2026-31485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31485"
},
{
"name": "CVE-2026-23475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23475"
},
{
"name": "CVE-2026-53002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
},
{
"name": "CVE-2026-46124",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46124"
},
{
"name": "CVE-2026-64413",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64413"
},
{
"name": "CVE-2026-43421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43421"
},
{
"name": "CVE-2026-23054",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23054"
},
{
"name": "CVE-2025-71064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71064"
},
{
"name": "CVE-2026-31402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31402"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2026-52947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52947"
},
{
"name": "CVE-2026-53218",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53218"
},
{
"name": "CVE-2026-63354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63354"
},
{
"name": "CVE-2025-68725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68725"
},
{
"name": "CVE-2025-71265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71265"
},
{
"name": "CVE-2026-23450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23450"
},
{
"name": "CVE-2026-23281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23281"
},
{
"name": "CVE-2026-31696",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31696"
},
{
"name": "CVE-2025-68349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68349"
},
{
"name": "CVE-2025-21853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21853"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-71221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71221"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2026-31704",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31704"
},
{
"name": "CVE-2026-31685",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31685"
},
{
"name": "CVE-2026-52970",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52970"
},
{
"name": "CVE-2026-31416",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31416"
},
{
"name": "CVE-2026-43492",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43492"
},
{
"name": "CVE-2024-58009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58009"
},
{
"name": "CVE-2026-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52999"
},
{
"name": "CVE-2026-22992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22992"
},
{
"name": "CVE-2026-46065",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46065"
},
{
"name": "CVE-2026-46227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46227"
},
{
"name": "CVE-2026-44415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44415"
},
{
"name": "CVE-2025-39764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39764"
},
{
"name": "CVE-2023-54271",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-54271"
},
{
"name": "CVE-2025-71191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71191"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2026-23438",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23438"
},
{
"name": "CVE-2026-23293",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23293"
},
{
"name": "CVE-2026-23463",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23463"
},
{
"name": "CVE-2026-46185",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46185"
},
{
"name": "CVE-2026-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23454"
},
{
"name": "CVE-2026-53400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53400"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2024-50014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50014"
},
{
"name": "CVE-2026-3497",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-3497"
},
{
"name": "CVE-2026-46064",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46064"
},
{
"name": "CVE-2026-31698",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31698"
},
{
"name": "CVE-2026-31664",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31664"
},
{
"name": "CVE-2026-46196",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46196"
},
{
"name": "CVE-2026-31448",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31448"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-68773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68773"
},
{
"name": "CVE-2026-23290",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23290"
},
{
"name": "CVE-2026-31752",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31752"
},
{
"name": "CVE-2026-40355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40355"
},
{
"name": "CVE-2024-26783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26783"
},
{
"name": "CVE-2025-37917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37917"
},
{
"name": "CVE-2025-21738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21738"
},
{
"name": "CVE-2026-53227",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53227"
},
{
"name": "CVE-2026-23303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23303"
},
{
"name": "CVE-2026-43011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43011"
},
{
"name": "CVE-2023-52927",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52927"
},
{
"name": "CVE-2026-53239",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53239"
},
{
"name": "CVE-2026-31396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31396"
},
{
"name": "CVE-2024-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58061"
},
{
"name": "CVE-2026-31680",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31680"
},
{
"name": "CVE-2026-31586",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31586"
},
{
"name": "CVE-2026-53181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53181"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2025-21864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21864"
},
{
"name": "CVE-2026-23340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23340"
},
{
"name": "CVE-2026-52918",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52918"
},
{
"name": "CVE-2024-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58056"
},
{
"name": "CVE-2025-23131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23131"
},
{
"name": "CVE-2025-21725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21725"
},
{
"name": "CVE-2025-71189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71189"
},
{
"name": "CVE-2025-71088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71088"
},
{
"name": "CVE-2026-59241",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-59241"
},
{
"name": "CVE-2026-46303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46303"
},
{
"name": "CVE-2026-31613",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31613"
},
{
"name": "CVE-2025-21727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21727"
},
{
"name": "CVE-2026-64279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64279"
},
{
"name": "CVE-2026-89208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-89208"
},
{
"name": "CVE-2025-38591",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38591"
},
{
"name": "CVE-2025-71098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71098"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2026-45835",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45835"
},
{
"name": "CVE-2026-23439",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23439"
},
{
"name": "CVE-2025-22095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22095"
},
{
"name": "CVE-2026-23253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23253"
},
{
"name": "CVE-2026-52943",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52943"
},
{
"name": "CVE-2026-43025",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43025"
},
{
"name": "CVE-2026-31617",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31617"
},
{
"name": "CVE-2026-23271",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23271"
},
{
"name": "CVE-2026-43052",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43052"
},
{
"name": "CVE-2026-43496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43496"
},
{
"name": "CVE-2024-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58063"
},
{
"name": "CVE-2024-50164",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50164"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-21779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21779"
},
{
"name": "CVE-2025-68265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68265"
},
{
"name": "CVE-2024-58005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58005"
},
{
"name": "CVE-2026-46173",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46173"
},
{
"name": "CVE-2026-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46195"
},
{
"name": "CVE-2026-46214",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46214"
},
{
"name": "CVE-2026-53146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53146"
},
{
"name": "CVE-2025-71085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71085"
},
{
"name": "CVE-2026-23434",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23434"
},
{
"name": "CVE-2026-31711",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31711"
},
{
"name": "CVE-2026-31611",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31611"
},
{
"name": "CVE-2026-63810",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63810"
},
{
"name": "CVE-2025-21753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21753"
},
{
"name": "CVE-2026-31447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31447"
},
{
"name": "CVE-2026-46320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46320"
},
{
"name": "CVE-2026-46092",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46092"
},
{
"name": "CVE-2026-43028",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43028"
},
{
"name": "CVE-2026-46040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46040"
},
{
"name": "CVE-2026-23422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23422"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-68814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68814"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2026-46113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46113"
},
{
"name": "CVE-2026-23304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23304"
},
{
"name": "CVE-2026-63352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63352"
},
{
"name": "CVE-2026-23357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23357"
},
{
"name": "CVE-2025-39681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39681"
},
{
"name": "CVE-2026-46137",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46137"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2026-45841",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45841"
},
{
"name": "CVE-2026-53150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53150"
},
{
"name": "CVE-2026-23066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23066"
},
{
"name": "CVE-2026-53147",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53147"
},
{
"name": "CVE-2026-46159",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46159"
},
{
"name": "CVE-2026-52942",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52942"
},
{
"name": "CVE-2026-31546",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31546"
},
{
"name": "CVE-2026-46190",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46190"
},
{
"name": "CVE-2026-46331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46331"
},
{
"name": "CVE-2025-22105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22105"
},
{
"name": "CVE-2025-61985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61985"
},
{
"name": "CVE-2026-53183",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53183"
},
{
"name": "CVE-2026-31583",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31583"
},
{
"name": "CVE-2025-22055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22055"
},
{
"name": "CVE-2026-46209",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46209"
},
{
"name": "CVE-2025-22090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22090"
},
{
"name": "CVE-2025-39871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39871"
},
{
"name": "CVE-2024-50298",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50298"
},
{
"name": "CVE-2026-23317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23317"
},
{
"name": "CVE-2025-21728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21728"
},
{
"name": "CVE-2026-63351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63351"
},
{
"name": "CVE-2026-31389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31389"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2026-31681",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31681"
},
{
"name": "CVE-2026-23456",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23456"
},
{
"name": "CVE-2026-43033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43033"
},
{
"name": "CVE-2026-23287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23287"
},
{
"name": "CVE-2026-53006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53006"
},
{
"name": "CVE-2025-68291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68291"
},
{
"name": "CVE-2026-31622",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31622"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2026-23457",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23457"
},
{
"name": "CVE-2026-43503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43503"
},
{
"name": "CVE-2026-46101",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46101"
},
{
"name": "CVE-2025-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21830"
},
{
"name": "CVE-2026-46099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46099"
},
{
"name": "CVE-2026-31496",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31496"
},
{
"name": "CVE-2026-31642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31642"
},
{
"name": "CVE-2026-23399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23399"
},
{
"name": "CVE-2026-43350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43350"
},
{
"name": "CVE-2026-44414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44414"
},
{
"name": "CVE-2025-21655",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21655"
},
{
"name": "CVE-2025-21767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21767"
},
{
"name": "CVE-2025-21764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21764"
},
{
"name": "CVE-2026-53149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53149"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2026-46037",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46037"
},
{
"name": "CVE-2026-46116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46116"
},
{
"name": "CVE-2025-21838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21838"
},
{
"name": "CVE-2025-21938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21938"
},
{
"name": "CVE-2026-43057",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43057"
},
{
"name": "CVE-2025-21867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21867"
},
{
"name": "CVE-2026-43117",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43117"
},
{
"name": "CVE-2024-49994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49994"
},
{
"name": "CVE-2026-46083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46083"
},
{
"name": "CVE-2026-43030",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43030"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2026-43074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43074"
},
{
"name": "CVE-2026-46151",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46151"
},
{
"name": "CVE-2026-22980",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22980"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2026-43493",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
},
{
"name": "CVE-2025-21766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21766"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2026-23391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23391"
},
{
"name": "CVE-2026-31415",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31415"
},
{
"name": "CVE-2024-58017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58017"
},
{
"name": "CVE-2024-47809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47809"
},
{
"name": "CVE-2026-23204",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23204"
},
{
"name": "CVE-2026-31563",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31563"
},
{
"name": "CVE-2026-53050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53050"
},
{
"name": "CVE-2026-23019",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23019"
},
{
"name": "CVE-2026-23273",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23273"
},
{
"name": "CVE-2026-23372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23372"
},
{
"name": "CVE-2026-43080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43080"
},
{
"name": "CVE-2026-46146",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46146"
},
{
"name": "CVE-2026-45836",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45836"
},
{
"name": "CVE-2026-43499",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43499"
},
{
"name": "CVE-2026-46174",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46174"
},
{
"name": "CVE-2026-41989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41989"
},
{
"name": "CVE-2026-23319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23319"
},
{
"name": "CVE-2026-23005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23005"
},
{
"name": "CVE-2024-56719",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56719"
},
{
"name": "CVE-2025-21745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21745"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2026-64375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64375"
},
{
"name": "CVE-2026-31494",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31494"
},
{
"name": "CVE-2026-31565",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31565"
},
{
"name": "CVE-2025-71079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71079"
},
{
"name": "CVE-2026-31697",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31697"
},
{
"name": "CVE-2026-23270",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23270"
},
{
"name": "CVE-2026-63350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63350"
},
{
"name": "CVE-2026-46069",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46069"
},
{
"name": "CVE-2026-64370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64370"
},
{
"name": "CVE-2026-23279",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23279"
},
{
"name": "CVE-2026-43216",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43216"
},
{
"name": "CVE-2025-21795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21795"
},
{
"name": "CVE-2025-39977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39977"
},
{
"name": "CVE-2026-31670",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31670"
},
{
"name": "CVE-2026-46122",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46122"
},
{
"name": "CVE-2025-38732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38732"
},
{
"name": "CVE-2026-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
},
{
"name": "CVE-2025-39773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39773"
},
{
"name": "CVE-2026-46022",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46022"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21645"
},
{
"name": "CVE-2026-31422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31422"
},
{
"name": "CVE-2026-23359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23359"
},
{
"name": "CVE-2026-31533",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31533"
},
{
"name": "CVE-2026-46323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46323"
},
{
"name": "CVE-2026-31469",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31469"
},
{
"name": "CVE-2025-21758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21758"
},
{
"name": "CVE-2026-53219",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53219"
},
{
"name": "CVE-2026-31449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31449"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-21787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21787"
},
{
"name": "CVE-2026-46120",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46120"
},
{
"name": "CVE-2026-53249",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53249"
},
{
"name": "CVE-2026-31418",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31418"
},
{
"name": "CVE-2025-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23136"
},
{
"name": "CVE-2025-37785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37785"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21706"
},
{
"name": "CVE-2025-38727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38727"
},
{
"name": "CVE-2026-23296",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23296"
},
{
"name": "CVE-2025-21999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21999"
},
{
"name": "CVE-2026-46128",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46128"
},
{
"name": "CVE-2026-31427",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31427"
},
{
"name": "CVE-2026-31555",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31555"
},
{
"name": "CVE-2024-57917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57917"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-68724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68724"
},
{
"name": "CVE-2026-23103",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
},
{
"name": "CVE-2026-31580",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31580"
},
{
"name": "CVE-2026-43099",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43099"
},
{
"name": "CVE-2024-42079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42079"
},
{
"name": "CVE-2026-31515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31515"
},
{
"name": "CVE-2026-31737",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31737"
},
{
"name": "CVE-2024-49968",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49968"
},
{
"name": "CVE-2026-64371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64371"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2026-53236",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53236"
},
{
"name": "CVE-2026-53225",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53225"
},
{
"name": "CVE-2025-21913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21913"
},
{
"name": "CVE-2024-58079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58079"
},
{
"name": "CVE-2025-71267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71267"
},
{
"name": "CVE-2026-46243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46243"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2026-22994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22994"
},
{
"name": "CVE-2026-31705",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31705"
},
{
"name": "CVE-2025-22056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22056"
},
{
"name": "CVE-2026-53362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53362"
},
{
"name": "CVE-2025-61984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61984"
},
{
"name": "CVE-2026-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53168"
},
{
"name": "CVE-2026-23396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23396"
},
{
"name": "CVE-2025-37964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37964"
},
{
"name": "CVE-2026-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23083"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2026-31423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31423"
},
{
"name": "CVE-2026-46180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46180"
},
{
"name": "CVE-2026-46038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46038"
},
{
"name": "CVE-2026-31625",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31625"
},
{
"name": "CVE-2026-23370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23370"
},
{
"name": "CVE-2026-23302",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23302"
},
{
"name": "CVE-2024-58086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58086"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2026-23414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23414"
},
{
"name": "CVE-2024-56631",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56631"
},
{
"name": "CVE-2026-23315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23315"
},
{
"name": "CVE-2026-63357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63357"
},
{
"name": "CVE-2025-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38614"
},
{
"name": "CVE-2026-31669",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31669"
},
{
"name": "CVE-2026-31450",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31450"
},
{
"name": "CVE-2026-31671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31671"
},
{
"name": "CVE-2026-46234",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46234"
},
{
"name": "CVE-2026-43024",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43024"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-38322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38322"
},
{
"name": "CVE-2026-53167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53167"
},
{
"name": "CVE-2026-31694",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31694"
},
{
"name": "CVE-2026-23352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23352"
},
{
"name": "CVE-2024-36927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36927"
},
{
"name": "CVE-2026-46321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46321"
},
{
"name": "CVE-2026-31699",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31699"
},
{
"name": "CVE-2024-53166",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53166"
},
{
"name": "CVE-2026-23367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23367"
},
{
"name": "CVE-2026-31628",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31628"
},
{
"name": "CVE-2025-22111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22111"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2024-27056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27056"
},
{
"name": "CVE-2025-71114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71114"
},
{
"name": "CVE-2024-36922",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36922"
},
{
"name": "CVE-2026-31768",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31768"
},
{
"name": "CVE-2026-43026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43026"
},
{
"name": "CVE-2026-45997",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45997"
},
{
"name": "CVE-2026-53177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53177"
},
{
"name": "CVE-2026-53208",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53208"
},
{
"name": "CVE-2026-53255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53255"
},
{
"name": "CVE-2026-46070",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46070"
},
{
"name": "CVE-2026-23038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23038"
},
{
"name": "CVE-2026-102076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-102076"
},
{
"name": "CVE-2026-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46150"
},
{
"name": "CVE-2025-71186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71186"
},
{
"name": "CVE-2026-45840",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45840"
},
{
"name": "CVE-2026-23026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23026"
},
{
"name": "CVE-2026-46044",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46044"
},
{
"name": "CVE-2026-102073",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-102073"
},
{
"name": "CVE-2026-23255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23255"
},
{
"name": "CVE-2026-23446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23446"
},
{
"name": "CVE-2026-53245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53245"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2026-43035",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43035"
},
{
"name": "CVE-2025-71190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71190"
},
{
"name": "CVE-2026-46172",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46172"
},
{
"name": "CVE-2025-39795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39795"
},
{
"name": "CVE-2024-58068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58068"
},
{
"name": "CVE-2024-56657",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56657"
},
{
"name": "CVE-2026-31665",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31665"
},
{
"name": "CVE-2026-46161",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46161"
},
{
"name": "CVE-2026-46026",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46026"
},
{
"name": "CVE-2026-23300",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23300"
},
{
"name": "CVE-2026-23444",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23444"
},
{
"name": "CVE-2025-21862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21862"
},
{
"name": "CVE-2026-31391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31391"
},
{
"name": "CVE-2026-53148",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53148"
},
{
"name": "CVE-2025-71104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71104"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2026-45844",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45844"
},
{
"name": "CVE-2026-46110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46110"
},
{
"name": "CVE-2026-52946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52946"
},
{
"name": "CVE-2026-43501",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43501"
},
{
"name": "CVE-2026-43093",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43093"
},
{
"name": "CVE-2026-23243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23243"
},
{
"name": "CVE-2026-31521",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31521"
},
{
"name": "CVE-2025-21719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21719"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-68820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68820"
},
{
"name": "CVE-2026-53263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53263"
},
{
"name": "CVE-2026-31634",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31634"
},
{
"name": "CVE-2026-46018",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46018"
},
{
"name": "CVE-2025-22060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22060"
},
{
"name": "CVE-2024-47736",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47736"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2024-28956",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28956"
},
{
"name": "CVE-2025-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39978"
},
{
"name": "CVE-2026-53012",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53012"
},
{
"name": "CVE-2025-68742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68742"
},
{
"name": "CVE-2026-45991",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45991"
},
{
"name": "CVE-2025-37972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37972"
},
{
"name": "CVE-2026-23379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23379"
},
{
"name": "CVE-2026-53356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53356"
},
{
"name": "CVE-2024-46786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46786"
},
{
"name": "CVE-2026-31421",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31421"
},
{
"name": "CVE-2025-21806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21806"
},
{
"name": "CVE-2026-53228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
},
{
"name": "CVE-2025-68816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68816"
},
{
"name": "CVE-2024-57977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57977"
},
{
"name": "CVE-2026-23381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23381"
},
{
"name": "CVE-2026-31518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31518"
},
{
"name": "CVE-2026-31712",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31712"
},
{
"name": "CVE-2026-46046",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46046"
},
{
"name": "CVE-2025-21707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21707"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2026-23392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23392"
},
{
"name": "CVE-2026-23245",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23245"
},
{
"name": "CVE-2026-46294",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46294"
},
{
"name": "CVE-2026-46125",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46125"
},
{
"name": "CVE-2024-49998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49998"
},
{
"name": "CVE-2025-39782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39782"
},
{
"name": "CVE-2026-22982",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22982"
},
{
"name": "CVE-2026-31403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31403"
},
{
"name": "CVE-2024-53170",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53170"
},
{
"name": "CVE-2026-43094",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43094"
},
{
"name": "CVE-2026-53242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53242"
},
{
"name": "CVE-2026-64545",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64545"
},
{
"name": "CVE-2025-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38617"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2026-31504",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31504"
},
{
"name": "CVE-2026-52910",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52910"
},
{
"name": "CVE-2026-23364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23364"
},
{
"name": "CVE-2026-46167",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46167"
},
{
"name": "CVE-2025-39721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39721"
},
{
"name": "CVE-2026-23242",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23242"
},
{
"name": "CVE-2026-53212",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53212"
},
{
"name": "CVE-2026-46191",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46191"
},
{
"name": "CVE-2024-54458",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54458"
},
{
"name": "CVE-2026-53337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53337"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2026-43085",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43085"
},
{
"name": "CVE-2026-31637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31637"
},
{
"name": "CVE-2025-39964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39964"
},
{
"name": "CVE-2026-31612",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31612"
},
{
"name": "CVE-2024-57924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57924"
},
{
"name": "CVE-2025-68776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68776"
},
{
"name": "CVE-2026-23274",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23274"
},
{
"name": "CVE-2025-21859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21859"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2026-31417",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31417"
},
{
"name": "CVE-2026-31761",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31761"
},
{
"name": "CVE-2025-71097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71097"
},
{
"name": "CVE-2026-31466",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31466"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2024-58016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58016"
},
{
"name": "CVE-2026-43111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43111"
},
{
"name": "CVE-2026-53268",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53268"
},
{
"name": "CVE-2026-53223",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53223"
},
{
"name": "CVE-2026-23087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23087"
},
{
"name": "CVE-2026-64423",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64423"
},
{
"name": "CVE-2025-21761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21761"
},
{
"name": "CVE-2026-31414",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31414"
},
{
"name": "CVE-2025-71185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71185"
},
{
"name": "CVE-2025-38704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38704"
},
{
"name": "CVE-2025-21844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21844"
},
{
"name": "CVE-2025-68337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68337"
},
{
"name": "CVE-2025-21676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21676"
},
{
"name": "CVE-2026-85115",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-85115"
},
{
"name": "CVE-2026-53080",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53080"
},
{
"name": "CVE-2025-71131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71131"
},
{
"name": "CVE-2026-43040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43040"
},
{
"name": "CVE-2025-21726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21726"
},
{
"name": "CVE-2026-52912",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52912"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2024-58020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58020"
},
{
"name": "CVE-2026-23284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23284"
},
{
"name": "CVE-2026-53221",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53221"
},
{
"name": "CVE-2026-52998",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52998"
},
{
"name": "CVE-2026-31488",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31488"
},
{
"name": "CVE-2026-53275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53275"
},
{
"name": "CVE-2026-23278",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23278"
},
{
"name": "CVE-2026-31532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31532"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2026-53001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53001"
},
{
"name": "CVE-2026-23397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23397"
},
{
"name": "CVE-2025-21705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21705"
},
{
"name": "CVE-2026-23452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23452"
},
{
"name": "CVE-2026-23474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23474"
},
{
"name": "CVE-2025-40300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40300"
},
{
"name": "CVE-2026-53295",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53295"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2026-23343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23343"
},
{
"name": "CVE-2026-53269",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53269"
},
{
"name": "CVE-2026-23336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23336"
},
{
"name": "CVE-2026-45843",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45843"
},
{
"name": "CVE-2025-68803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68803"
},
{
"name": "CVE-2025-38721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38721"
},
{
"name": "CVE-2026-46015",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46015"
},
{
"name": "CVE-2026-46136",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46136"
},
{
"name": "CVE-2026-31682",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31682"
},
{
"name": "CVE-2026-46056",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46056"
},
{
"name": "CVE-2026-23292",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23292"
},
{
"name": "CVE-2026-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23141"
},
{
"name": "CVE-2026-31451",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31451"
},
{
"name": "CVE-2026-23277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23277"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2025-71112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71112"
},
{
"name": "CVE-2026-31709",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31709"
},
{
"name": "CVE-2026-53253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53253"
},
{
"name": "CVE-2026-31441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31441"
},
{
"name": "CVE-2026-23086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23086"
},
{
"name": "CVE-2026-52948",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52948"
},
{
"name": "CVE-2025-68818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68818"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2026-46086",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46086"
},
{
"name": "CVE-2026-64412",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64412"
},
{
"name": "CVE-2026-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
},
{
"name": "CVE-2026-23455",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23455"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2026-63355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63355"
},
{
"name": "CVE-2026-53134",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53134"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2024-40945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40945"
},
{
"name": "CVE-2026-23335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23335"
},
{
"name": "CVE-2026-52986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52986"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-21702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21702"
},
{
"name": "CVE-2026-31495",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31495"
},
{
"name": "CVE-2026-46132",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46132"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2025-21865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21865"
},
{
"name": "CVE-2026-23095",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23095"
},
{
"name": "CVE-2026-46177",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46177"
},
{
"name": "CVE-2026-43110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43110"
},
{
"name": "CVE-2025-71163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71163"
},
{
"name": "CVE-2026-53256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53256"
},
{
"name": "CVE-2024-58002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58002"
},
{
"name": "CVE-2026-31507",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31507"
},
{
"name": "CVE-2026-64411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64411"
},
{
"name": "CVE-2025-39691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39691"
},
{
"name": "CVE-2026-23389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23389"
},
{
"name": "CVE-2025-71095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71095"
},
{
"name": "CVE-2026-46333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46333"
},
{
"name": "CVE-2026-43071",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43071"
},
{
"name": "CVE-2025-68266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68266"
},
{
"name": "CVE-2026-31411",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31411"
},
{
"name": "CVE-2026-31428",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31428"
},
{
"name": "CVE-2025-68363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68363"
},
{
"name": "CVE-2026-43303",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43303"
},
{
"name": "CVE-2026-23388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23388"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2026-23449",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23449"
},
{
"name": "CVE-2026-46306",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46306"
},
{
"name": "CVE-2026-102074",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-102074"
},
{
"name": "CVE-2025-39863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39863"
},
{
"name": "CVE-2025-21648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21648"
},
{
"name": "CVE-2025-71266",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71266"
},
{
"name": "CVE-2026-43089",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43089"
},
{
"name": "CVE-2026-46021",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46021"
},
{
"name": "CVE-2026-31676",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31676"
},
{
"name": "CVE-2025-39931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39931"
},
{
"name": "CVE-2026-22977",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22977"
},
{
"name": "CVE-2026-43112",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43112"
},
{
"name": "CVE-2026-23442",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23442"
},
{
"name": "CVE-2025-21724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21724"
},
{
"name": "CVE-2026-46107",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46107"
},
{
"name": "CVE-2026-46047",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46047"
},
{
"name": "CVE-2026-23458",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23458"
},
{
"name": "CVE-2026-23003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23003"
},
{
"name": "CVE-2026-43502",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43502"
},
{
"name": "CVE-2026-31649",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31649"
},
{
"name": "CVE-2026-31674",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31674"
},
{
"name": "CVE-2026-23310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23310"
},
{
"name": "CVE-2026-53198",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53198"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2025-37780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37780"
},
{
"name": "CVE-2026-43027",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43027"
},
{
"name": "CVE-2026-52909",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52909"
},
{
"name": "CVE-2025-71123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71123"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2026-46163",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46163"
},
{
"name": "CVE-2026-45838",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45838"
},
{
"name": "CVE-2026-53264",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53264"
},
{
"name": "CVE-2026-23339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23339"
},
{
"name": "CVE-2026-23010",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23010"
},
{
"name": "CVE-2026-23272",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23272"
},
{
"name": "CVE-2024-58077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58077"
},
{
"name": "CVE-2026-53184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53184"
},
{
"name": "CVE-2026-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23084"
},
{
"name": "CVE-2026-22979",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22979"
},
{
"name": "CVE-2026-23321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23321"
},
{
"name": "CVE-2026-43114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43114"
},
{
"name": "CVE-2026-46187",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46187"
},
{
"name": "CVE-2026-23011",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23011"
},
{
"name": "CVE-2025-71161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71161"
},
{
"name": "CVE-2026-46168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46168"
},
{
"name": "CVE-2026-53325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53325"
},
{
"name": "CVE-2026-23395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23395"
},
{
"name": "CVE-2026-31708",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31708"
},
{
"name": "CVE-2026-31651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31651"
},
{
"name": "CVE-2026-23110",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23110"
},
{
"name": "CVE-2026-64560",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64560"
},
{
"name": "CVE-2026-85114",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-85114"
},
{
"name": "CVE-2026-23100",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23100"
},
{
"name": "CVE-2026-31503",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31503"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2025-71120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71120"
},
{
"name": "CVE-2026-63353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-63353"
},
{
"name": "CVE-2026-23060",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23060"
},
{
"name": "CVE-2025-68787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68787"
},
{
"name": "CVE-2026-31624",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31624"
},
{
"name": "CVE-2026-46050",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46050"
},
{
"name": "CVE-2026-46003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46003"
},
{
"name": "CVE-2026-53358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53358"
},
{
"name": "CVE-2025-68782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68782"
},
{
"name": "CVE-2025-71197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71197"
},
{
"name": "CVE-2026-23378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23378"
},
{
"name": "CVE-2026-53352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53352"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-71113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71113"
},
{
"name": "CVE-2026-53254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53254"
},
{
"name": "CVE-2025-38736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38736"
},
{
"name": "CVE-2026-52928",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52928"
},
{
"name": "CVE-2026-23291",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23291"
},
{
"name": "CVE-2026-46023",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46023"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2025-37959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37959"
},
{
"name": "CVE-2026-46304",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46304"
},
{
"name": "CVE-2024-26982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26982"
},
{
"name": "CVE-2023-51384",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51384"
},
{
"name": "CVE-2021-41617",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41617"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2025-21919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21919"
},
{
"name": "CVE-2026-23382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23382"
},
{
"name": "CVE-2026-64425",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64425"
},
{
"name": "CVE-2026-23111",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23111"
},
{
"name": "CVE-2026-52930",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52930"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2025-21703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21703"
},
{
"name": "CVE-2026-31446",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31446"
},
{
"name": "CVE-2026-46275",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46275"
},
{
"name": "CVE-2026-23113",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23113"
},
{
"name": "CVE-2026-46193",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46193"
},
{
"name": "CVE-2026-53265",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-53265"
},
{
"name": "CVE-2025-68798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68798"
},
{
"name": "CVE-2026-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23157"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2026-46033",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46033"
},
{
"name": "CVE-2026-52923",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52923"
},
{
"name": "CVE-2026-31500",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31500"
},
{
"name": "CVE-2026-45850",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45850"
},
{
"name": "CVE-2024-57993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57993"
},
{
"name": "CVE-2026-45834",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45834"
},
{
"name": "CVE-2025-21887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21887"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2026-31700",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31700"
},
{
"name": "CVE-2024-56647",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56647"
},
{
"name": "CVE-2026-31630",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31630"
},
{
"name": "CVE-2026-72895",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-72895"
},
{
"name": "CVE-2026-52933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52933"
},
{
"name": "CVE-2026-23231",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23231"
},
{
"name": "CVE-2025-40261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40261"
},
{
"name": "CVE-2026-23312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23312"
},
{
"name": "CVE-2026-31508",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31508"
},
{
"name": "CVE-2026-64422",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64422"
},
{
"name": "CVE-2025-21700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21700"
},
{
"name": "CVE-2026-23365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23365"
},
{
"name": "CVE-2026-43116",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43116"
},
{
"name": "CVE-2025-21875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21875"
},
{
"name": "CVE-2026-31424",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31424"
},
{
"name": "CVE-2026-23356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23356"
},
{
"name": "CVE-2025-37909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37909"
},
{
"name": "CVE-2025-22015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22015"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2025-21832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21832"
},
{
"name": "CVE-2025-68371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68371"
},
{
"name": "CVE-2026-43038",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-43038"
},
{
"name": "CVE-2025-21790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21790"
},
{
"name": "CVE-2025-40022",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40022"
},
{
"name": "CVE-2023-53292",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53292"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2026-46165",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46165"
},
{
"name": "CVE-2026-31452",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31452"
},
{
"name": "CVE-2026-31407",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31407"
},
{
"name": "CVE-2026-23398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23398"
},
{
"name": "CVE-2025-21756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21756"
},
{
"name": "CVE-2025-68261",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68261"
},
{
"name": "CVE-2026-46051",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46051"
},
{
"name": "CVE-2026-52917",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-52917"
},
{
"name": "CVE-2026-46322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46322"
},
{
"name": "CVE-2025-21716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21716"
},
{
"name": "CVE-2026-45839",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45839"
},
{
"name": "CVE-2026-46088",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46088"
},
{
"name": "CVE-2026-102075",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-102075"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2026-31629",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31629"
},
{
"name": "CVE-2024-57986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57986"
},
{
"name": "CVE-2026-46102",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-46102"
},
{
"name": "CVE-2026-64317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-64317"
},
{
"name": "CVE-2026-23351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23351"
},
{
"name": "CVE-2025-21835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21835"
},
{
"name": "CVE-2025-68264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68264"
},
{
"name": "CVE-2026-23154",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23154"
},
{
"name": "CVE-2026-31673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31673"
},
{
"name": "CVE-2025-68764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68764"
}
],
"initial_release_date": "2026-10-13T00:00:00",
"last_revision_date": "2026-10-13T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1298",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-10-13T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Injection de code indirecte \u00e0 distance (XSS)"
},
{
"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": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-832641",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-832641.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens ssb-091449",
"url": "https://cert-portal.siemens.com/productcert/html/ssb-091449.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-591731",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-591731.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-784472",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-784472.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-333035",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-333035.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-550198",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-550198.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-159454",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-159454.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-457936",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-457936.html"
},
{
"published_at": "2026-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-390352",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-390352.html"
}
]
}
FKIE_CVE-2025-38584
Vulnerability from fkie_nvd - Published: 2025-08-19 17:15 - Updated: 2026-10-15 22:187.8 (High) - CVSS:3.1/
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/linux/padata.h",
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "a2048e475e22b13dc3e53d485b7e6e11464ed9a6",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "73f132e60857038416540c3599b1de6033d7575a",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "609e59193fc6d9dd323f1c6ae1fdd721f1c79680",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "a11a12a9880ab37342b73c93cfe1a3ada02ff0db",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "f231d5d001ec75f5886c02d496a4c79edc383d45",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "dbe3e911a59bda6de96e7cae387ff882c2c177fa",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "cdf79bd2e1ecb3cc75631c73d8f4149be6019a52",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
},
{
"lessThan": "71203f68c7749609d7fc8ae6ad054bdedeb24f91",
"status": "affected",
"version": "16295bec6398a3eedc9377e1af6ff4c71b98c300",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/linux/padata.h",
"kernel/padata.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.34"
},
{
"lessThan": "2.6.34",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.258",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.209",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.175",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.140",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.86",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.1",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC S7-1500 TM MFP - GNU/Linux subsystem",
"vendor": "Siemens",
"versions": [
{
"lessThan": "*",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "70708DCC-6F9D-4EFE-AF47-0CA615284AD2",
"versionEndExcluding": "6.15.10",
"versionStartIncluding": "2.6.34",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "58182352-D7DF-4CC9-841E-03C1D852C3FB",
"versionEndExcluding": "6.16.1",
"versionStartIncluding": "6.16",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit. A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly. If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u003eserial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u003eserial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: padata: Arregla pd UAF de una vez por todas Hay una condici\u00f3n de ejecuci\u00f3n/UAF en padata_reorder que se remonta a la confirmaci\u00f3n inicial. Se toma un recuento de referencias al inicio del proceso en padata_do_parallel y se libera al final en padata_serial_worker. Este recuento de referencias es (y solo es) necesario para que padata_replace funcione correctamente. Si nunca se llama a padata_replace, no hay problema. En la funci\u00f3n padata_reorder que sirve como n\u00facleo de padata, tan pronto como padata se agrega a queue-\u0026gt;serial.list y se libera el bloqueo de giro asociado, ese padata puede procesarse y el recuento de referencias en pd desaparecer\u00eda. Arregla esto obteniendo el siguiente padata antes de que se libere el bloqueo squeue-\u0026gt;serial. Para que esto sea posible, simplifica padata_reorder llam\u00e1ndolo solo una vez que llega el siguiente padata."
}
],
"id": "CVE-2025-38584",
"lastModified": "2026-10-15T22:18:46.183",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "HIGH",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.0,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.0,
"impactScore": 5.9,
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"type": "Secondary"
},
{
"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": "nvd@nist.gov",
"type": "Primary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-38584",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T21:51:57.371948Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-08-19T17:15:35.723",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/609e59193fc6d9dd323f1c6ae1fdd721f1c79680"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/71203f68c7749609d7fc8ae6ad054bdedeb24f91"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/73f132e60857038416540c3599b1de6033d7575a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a11a12a9880ab37342b73c93cfe1a3ada02ff0db"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/a2048e475e22b13dc3e53d485b7e6e11464ed9a6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cdf79bd2e1ecb3cc75631c73d8f4149be6019a52"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/dbe3e911a59bda6de96e7cae387ff882c2c177fa"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"url": "https://git.kernel.org/stable/c/f231d5d001ec75f5886c02d496a4c79edc383d45"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-784472.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-416"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-7848-X3WQ-CG7M
Vulnerability from github – Published: 2025-08-19 18:31 – Updated: 2026-10-15 03:34In the Linux kernel, the following vulnerability has been resolved:
padata: Fix pd UAF once and for all
There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker.
This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue.
In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away.
Fix this by getting the next padata before the squeue->serial lock is released.
In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.
{
"affected": [],
"aliases": [
"CVE-2025-38584"
],
"database_specific": {
"cwe_ids": [
"CWE-416"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-19T17:15:35Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit. A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly. If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u003eserial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u003eserial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives.",
"id": "GHSA-7848-x3wq-cg7m",
"modified": "2026-10-15T03:34:52Z",
"published": "2025-08-19T18:31:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38584"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-784472.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/609e59193fc6d9dd323f1c6ae1fdd721f1c79680"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/71203f68c7749609d7fc8ae6ad054bdedeb24f91"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/73f132e60857038416540c3599b1de6033d7575a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a11a12a9880ab37342b73c93cfe1a3ada02ff0db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a2048e475e22b13dc3e53d485b7e6e11464ed9a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cdf79bd2e1ecb3cc75631c73d8f4149be6019a52"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/dbe3e911a59bda6de96e7cae387ff882c2c177fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f231d5d001ec75f5886c02d496a4c79edc383d45"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
ICSA-26-295-16
Vulnerability from csaf_cisa - Published: 2026-10-13 00:00 - Updated: 2026-10-22 06:00In the Linux kernel, the following vulnerability has been resolved: padata: Fix pd UAF once and for all There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker. This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue. In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away. Fix this by getting the next padata before the squeue->serial lock is released. In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.
MSRC_CVE-2025-38584
Vulnerability from csaf_microsoft - Published: 2025-09-04 04:21 - Updated: 2026-10-16 01:45OESA-2025-2268 (CVE-2025-21934)
Vulnerability from osv_openeuler – Published: 2025-09-12 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
rapidio: fix an API misues when rio_add_net() fails
rio_add_net() calls device_register() and fails when device_register() fails. Thus, put_device() should be used rather than kfree(). Add "mport->net = NULL;" to avoid a use after free issue.(CVE-2025-21934)
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix integer overflow while processing closetimeo mount option
User-provided mount parameter closetimeo of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbd_free_work_struct
->interim_entry of ksmbd_work could be deleted after oplock is freed. We don't need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed.(CVE-2025-21967)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in kerberos authentication
Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.(CVE-2025-37924)
In the Linux kernel, the following vulnerability has been resolved:
sch_htb: make htb_qlen_notify() idempotent
htb_qlen_notify() always deactivates the HTB class and in fact could trigger a warning if it is already deactivated. Therefore, it is not idempotent and not friendly to its callers, like fq_codel_dequeue().
Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life.(CVE-2025-37932)
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio as follow:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: <TASK> follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast.(CVE-2025-38102)
In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before.(CVE-2025-38119)
In the Linux kernel, the following vulnerability has been resolved:
sch_hfsc: make hfsc_qlen_notify() idempotent
hfsc_qlen_notify() is not idempotent either and not friendly to its callers, like fq_codel_dequeue(). Let's make it idempotent to ease qdisc_tree_reduce_backlog() callers' life:
-
update_vf() decreases cl->cl_nactive, so we can check whether it is non-zero before calling it.
-
eltree_remove() always removes RB node cl->el_node, but we can use RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.(CVE-2025-38177)
In the Linux kernel's vidtv driver, a slab-use-after-free vulnerability was discovered when the program incorrectly continued accessing the freed memory structure member 'si' after PSI initialization failure. This vulnerability could potentially lead to kernel crashes or information disclosure.(CVE-2025-38227)
In the Linux kernel, a recursive locking issue was identified in the ptp_vclock_in_use() function. When reading ptp->n_vclocks through ptp->n_vclocks_mux, it triggers a recursive lock call chain starting from n_vclocks_store(), leading to a potential deadlock. The root cause is the redundant check for ptp->n_vclocks in ptp_vclock_in_use(), as other functions already ensure ptp->n_vclocks is checked before unregistering vclocks.(CVE-2025-38305)
In the Linux kernel, a vulnerability has been identified in the fbdev core component's fbcvt module. When mode->refresh is set to 0x80000000, in the fb_find_mode_cvt() function, cvt.f_refresh becomes 0 due to overflow. This value is then passed to fb_cvt_hperiod() where it is used as a divisor, leading to a division by zero error and potential kernel crash. This vulnerability was discovered by the Linux Verification Center using the Svace static analysis tool.(CVE-2025-38312)
In the Linux kernel's x86/sgx component, a vulnerability exists that allows attempts to reclaim SGX pages marked as poisoned. The SGX page reclamation process accesses page contents to copy them to secondary storage, but SGX instructions cannot gracefully handle Machine Check Exceptions (MCE). Existing code fails to check the epc_page->poison flag, potentially causing reclamation operations on known poisoned pages, which may lead to core shutdowns or kernel panics. This vulnerability is triggered through the memory error notification path and requires prevention of poisoned pages being added to reclamation candidate lists.(CVE-2025-38334)
A NULL pointer dereference vulnerability exists in the Linux kernel's target subsystem. The function core_scsi3_decode_spec_i_port() unconditionally calls core_scsi3_lunacl_undepend_item() passing a potentially NULL dest_se_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: do not bypass hid_hw_raw_request
hid_hw_raw_request() is actually useful to ensure the provided buffer and length are valid. Directly calling in the low level transport driver function bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix oob access in cgroup local storage
Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context:
ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype];
if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);
For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access.
To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.(CVE-2025-38502)
In the Linux kernel, the following vulnerability has been resolved:
pptp: ensure minimal skb length in pptp_xmit()
Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on ppp_sync_txmung") fixed ppp_sync_txmunge()
We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot.
BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix pd UAF once and for all
There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker.
This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue.
In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away.
Fix this by getting the next padata before the squeue->serial lock is released.
In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.(CVE-2025-38584)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Remove skb secpath if xfrm state is not found
Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup.
Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0.
Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer.
This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath.
BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 </IRQ>(CVE-2025-38590)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'
Function 'hci_discovery_filter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race:
'hci_cmd_sync_work()'
'update_passive_scan_sync()'
'hci_update_passive_scan_sync()'
'hci_discovery_filter_clear()'
kfree(uuids);
<-------------------------preempted-------------------------------->
'start_service_discovery()'
'hci_discovery_filter_clear()'
kfree(uuids); // DOUBLE FREE
<-------------------------preempted-------------------------------->
uuids = NULL;
To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires:
[ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]---(CVE-2025-38593)
In the Linux kernel, the following vulnerability has been resolved:
md: make rdev_addable usable for rcu mode
Our testcase trigger panic:
BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: <TASK> md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0
md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive.(CVE-2025-38621)
In the Linux kernel, the following vulnerability has been resolved:
clk: davinci: Add NULL check in davinci_lpsc_clk_register()
devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated.(CVE-2025-38635)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Check device memory pointer before usage
Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5_init_once() fails.(CVE-2025-38645)
In the Linux kernel, the following vulnerability has been resolved:
comedi: fix race between polling and detaching
syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed. We need
to check there are no tasks queued on any of the subdevices' wait queues
before allowing the device to be detached by the COMEDI_DEVCONFIG
ioctl.
Tasks will read-lock dev->attach_lock before adding themselves to the
subdevice wait queue, so fix the problem in the COMEDI_DEVCONFIG ioctl
handler by write-locking dev->attach_lock before checking that all of
the subdevices are safe to be deleted. This includes testing for any
sleepers on the subdevices' wait queues. It remains locked until the
device has been detached. This requires the comedi_device_detach()
function to be refactored slightly, moving the bulk of it into new
function comedi_device_detach_locked().
Note that the refactor of comedi_device_detach() results in
comedi_device_cancel_all() now being called while dev->attach_lock
is write-locked, which wasn't the case previously, but that does not
matter.
Thanks to Jens Axboe for diagnosing the problem and co-developing this patch.(CVE-2025-38687)
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Also allocate and copy hash for reading of filter files
Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs.
Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers.(CVE-2025-39689)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"kernel-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"kernel-source-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"perf-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"python3-perf-6.6.0-109.0.0.101.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-109.0.0.101.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-109.0.0.101.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"kernel-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"kernel-source-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"perf-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"python3-perf-6.6.0-109.0.0.101.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-109.0.0.101.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-109.0.0.101.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrapidio: fix an API misues when rio_add_net() fails\n\nrio_add_net() calls device_register() and fails when device_register()\nfails. Thus, put_device() should be used rather than kfree(). Add\n\u0026quot;mport-\u0026gt;net = NULL;\u0026quot; to avoid a use after free issue.(CVE-2025-21934)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix integer overflow while processing closetimeo mount option\n\nUser-provided mount parameter closetimeo of type u32 is intended to have\nan upper limit, but before it is validated, the value is converted from\nseconds to jiffies which can lead to an integer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_free_work_struct\n\n-\u0026gt;interim_entry of ksmbd_work could be deleted after oplock is freed.\nWe don\u0026apos;t need to manage it with linked list. The interim request could be\nimmediately sent whenever a oplock break wait is needed.(CVE-2025-21967)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in kerberos authentication\n\nSetting sess-\u0026gt;user = NULL was introduced to fix the dangling pointer\ncreated by ksmbd_free_user. However, it is possible another thread could\nbe operating on the session and make use of sess-\u0026gt;user after it has been\npassed to ksmbd_free_user but before sess-\u0026gt;user is set to NULL.(CVE-2025-37924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_htb: make htb_qlen_notify() idempotent\n\nhtb_qlen_notify() always deactivates the HTB class and in fact could\ntrigger a warning if it is already deactivated. Therefore, it is not\nidempotent and not friendly to its callers, like fq_codel_dequeue().\n\nLet\u0026apos;s make it idempotent to ease qdisc_tree_reduce_backlog() callers\u0026apos;\nlife.(CVE-2025-37932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n Modules linked in:\n CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n RIP: 0010:try_grab_folio+0x106/0x130\n Call Trace:\n \u0026lt;TASK\u0026gt;\n follow_huge_pmd+0x240/0x8e0\n follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n follow_page_mask+0x1c2/0x1f0\n __get_user_pages+0x176/0x950\n __gup_longterm_locked+0x15b/0x1060\n ? gup_fast+0x120/0x1f0\n gup_fast_fallback+0x17e/0x230\n get_user_pages_fast+0x5f/0x80\n vmci_host_unlocked_ioctl+0x21c/0xf80\n RIP: 0033:0x54d2cd\n ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context-\u0026gt;notify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, \u0026amp;context-\u0026gt;notify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd // update \u0026amp;context-\u0026gt;notify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context-\u0026gt;notify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.(CVE-2025-38102)\n\nIn the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before.(CVE-2025-38119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: make hfsc_qlen_notify() idempotent\n\nhfsc_qlen_notify() is not idempotent either and not friendly\nto its callers, like fq_codel_dequeue(). Let\u0026apos;s make it idempotent\nto ease qdisc_tree_reduce_backlog() callers\u0026apos; life:\n\n1. update_vf() decreases cl-\u0026gt;cl_nactive, so we can check whether it is\nnon-zero before calling it.\n\n2. eltree_remove() always removes RB node cl-\u0026gt;el_node, but we can use\n RB_EMPTY_NODE() + RB_CLEAR_NODE() to make it safe.(CVE-2025-38177)\n\nIn the Linux kernel\u0026apos;s vidtv driver, a slab-use-after-free vulnerability was discovered when the program incorrectly continued accessing the freed memory structure member \u0026apos;si\u0026apos; after PSI initialization failure. This vulnerability could potentially lead to kernel crashes or information disclosure.(CVE-2025-38227)\n\nIn the Linux kernel, a recursive locking issue was identified in the ptp_vclock_in_use() function. When reading ptp-\u0026gt;n_vclocks through ptp-\u0026gt;n_vclocks_mux, it triggers a recursive lock call chain starting from n_vclocks_store(), leading to a potential deadlock. The root cause is the redundant check for ptp-\u0026gt;n_vclocks in ptp_vclock_in_use(), as other functions already ensure ptp-\u0026gt;n_vclocks is checked before unregistering vclocks.(CVE-2025-38305)\n\nIn the Linux kernel, a vulnerability has been identified in the fbdev core component\u0026apos;s fbcvt module. When mode-\u0026gt;refresh is set to 0x80000000, in the fb_find_mode_cvt() function, cvt.f_refresh becomes 0 due to overflow. This value is then passed to fb_cvt_hperiod() where it is used as a divisor, leading to a division by zero error and potential kernel crash. This vulnerability was discovered by the Linux Verification Center using the Svace static analysis tool.(CVE-2025-38312)\n\nIn the Linux kernel\u0026apos;s x86/sgx component, a vulnerability exists that allows attempts to reclaim SGX pages marked as poisoned. The SGX page reclamation process accesses page contents to copy them to secondary storage, but SGX instructions cannot gracefully handle Machine Check Exceptions (MCE). Existing code fails to check the epc_page-\u0026gt;poison flag, potentially causing reclamation operations on known poisoned pages, which may lead to core shutdowns or kernel panics. This vulnerability is triggered through the memory error notification path and requires prevention of poisoned pages being added to reclamation candidate lists.(CVE-2025-38334)\n\nA NULL pointer dereference vulnerability exists in the Linux kernel\u0026apos;s target subsystem. The function core_scsi3_decode_spec_i_port() unconditionally calls core_scsi3_lunacl_undepend_item() passing a potentially NULL dest_se_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: do not bypass hid_hw_raw_request\n\nhid_hw_raw_request() is actually useful to ensure the provided buffer\nand length are valid. Directly calling in the low level transport driver\nfunction bypassed those checks and allowed invalid paramto be used.(CVE-2025-38494)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix oob access in cgroup local storage\n\nLonial reported that an out-of-bounds access in cgroup local storage\ncan be crafted via tail calls. Given two programs each utilizing a\ncgroup local storage with a different value size, and one program\ndoing a tail call into the other. The verifier will validate each of\nthe indivial programs just fine. However, in the runtime context\nthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains the\nBPF program as well as any cgroup local storage flavor the program\nuses. Helpers such as bpf_get_local_storage() pick this up from the\nruntime context:\n\n ctx = container_of(current-\u0026gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);\n storage = ctx-\u0026gt;prog_item-\u0026gt;cgroup_storage[stype];\n\n if (stype == BPF_CGROUP_STORAGE_SHARED)\n ptr = \u0026amp;READ_ONCE(storage-\u0026gt;buf)-\u0026gt;data[0];\n else\n ptr = this_cpu_ptr(storage-\u0026gt;percpu_buf);\n\nFor the second program which was called from the originally attached\none, this means bpf_get_local_storage() will pick up the former\nprogram\u0026apos;s map, not its own. With mismatching sizes, this can result\nin an unintended out-of-bounds access.\n\nTo fix this issue, we need to extend bpf_map_owner with an array of\nstorage_cookie[] to match on i) the exact maps from the original\nprogram if the second program was using bpf_get_local_storage(), or\nii) allow the tail call combination if the second program was not\nusing any of the cgroup local storage maps.(CVE-2025-38502)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npptp: ensure minimal skb length in pptp_xmit()\n\nCommit aabc6596ffb3 (\u0026quot;net: ppp: Add bound checking for skb data\non ppp_sync_txmung\u0026quot;) fixed ppp_sync_txmunge()\n\nWe need a similar fix in pptp_xmit(), otherwise we might\nread uninit data as reported by syzbot.\n\nBUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]\n ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314\n pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379\n sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n __release_sock+0x1d3/0x330 net/core/sock.c:3213\n release_sock+0x6b/0x270 net/core/sock.c:3767\n pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:727\n ____sys_sendmsg+0x893/0xd80 net/socket.c:2566\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620\n __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit. A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly. If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u0026gt;serial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u0026gt;serial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives.(CVE-2025-38584)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Remove skb secpath if xfrm state is not found\n\nHardware returns a unique identifier for a decrypted packet\u0026apos;s xfrm\nstate, this state is looked up in an xarray. However, the state might\nhave been freed by the time of this lookup.\n\nCurrently, if the state is not found, only a counter is incremented.\nThe secpath (sp) extension on the skb is not removed, resulting in\nsp-\u0026gt;len becoming 0.\n\nSubsequently, functions like __xfrm_policy_check() attempt to access\nfields such as xfrm_input_state(skb)-\u0026gt;xso.type (which dereferences\nsp-\u0026gt;xvec[sp-\u0026gt;len - 1]) without first validating sp-\u0026gt;len. This leads to\na crash when dereferencing an invalid state pointer.\n\nThis patch prevents the crash by explicitly removing the secpath\nextension from the skb if the xfrm state is not found after hardware\ndecryption. This ensures downstream functions do not operate on a\nzero-length secpath.\n\n BUG: unable to handle page fault for address: ffffffff000002c8\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 282e067 P4D 282e067 PUD 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__xfrm_policy_check+0x61a/0xa30\n Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 \u0026lt;0f\u0026gt; b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa\n RSP: 0018:ffff88885fb04918 EFLAGS: 00010297\n RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000\n RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000\n RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353\n R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8\n R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00\n FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? try_to_wake_up+0x108/0x4c0\n ? udp4_lib_lookup2+0xbe/0x150\n ? udp_lib_lport_inuse+0x100/0x100\n ? __udp4_lib_lookup+0x2b0/0x410\n __xfrm_policy_check2.constprop.0+0x11e/0x130\n udp_queue_rcv_one_skb+0x1d/0x530\n udp_unicast_rcv_skb+0x76/0x90\n __udp4_lib_rcv+0xa64/0xe90\n ip_protocol_deliver_rcu+0x20/0x130\n ip_local_deliver_finish+0x75/0xa0\n ip_local_deliver+0xc1/0xd0\n ? ip_protocol_deliver_rcu+0x130/0x130\n ip_sublist_rcv+0x1f9/0x240\n ? ip_rcv_finish_core+0x430/0x430\n ip_list_rcv+0xfc/0x130\n __netif_receive_skb_list_core+0x181/0x1e0\n netif_receive_skb_list_internal+0x200/0x360\n ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]\n gro_receive_skb+0xfd/0x210\n mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]\n mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]\n ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]\n mlx5e_napi_poll+0x114/0xab0 [mlx5_core]\n __napi_poll+0x25/0x170\n net_rx_action+0x32d/0x3a0\n ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]\n ? notifier_call_chain+0x33/0xa0\n handle_softirqs+0xda/0x250\n irq_exit_rcu+0x6d/0xc0\n common_interrupt+0x81/0xa0\n \u0026lt;/IRQ\u0026gt;(CVE-2025-38590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix double free in \u0026apos;hci_discovery_filter_clear()\u0026apos;\n\nFunction \u0026apos;hci_discovery_filter_clear()\u0026apos; frees \u0026apos;uuids\u0026apos; array and then\nsets it to NULL. There is a tiny chance of the following race:\n\n\u0026apos;hci_cmd_sync_work()\u0026apos;\n\n \u0026apos;update_passive_scan_sync()\u0026apos;\n\n \u0026apos;hci_update_passive_scan_sync()\u0026apos;\n\n \u0026apos;hci_discovery_filter_clear()\u0026apos;\n kfree(uuids);\n\n \u0026lt;-------------------------preempted--------------------------------\u0026gt;\n \u0026apos;start_service_discovery()\u0026apos;\n\n \u0026apos;hci_discovery_filter_clear()\u0026apos;\n kfree(uuids); // DOUBLE FREE\n\n \u0026lt;-------------------------preempted--------------------------------\u0026gt;\n\n uuids = NULL;\n\nTo fix it let\u0026apos;s add locking around \u0026apos;kfree()\u0026apos; call and NULL pointer\nassignment. Otherwise the following backtrace fires:\n\n[ ] ------------[ cut here ]------------\n[ ] kernel BUG at mm/slub.c:547!\n[ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n[ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1\n[ ] Tainted: [O]=OOT_MODULE\n[ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ ] pc : __slab_free+0xf8/0x348\n[ ] lr : __slab_free+0x48/0x348\n...\n[ ] Call trace:\n[ ] __slab_free+0xf8/0x348\n[ ] kfree+0x164/0x27c\n[ ] start_service_discovery+0x1d0/0x2c0\n[ ] hci_sock_sendmsg+0x518/0x924\n[ ] __sock_sendmsg+0x54/0x60\n[ ] sock_write_iter+0x98/0xf8\n[ ] do_iter_readv_writev+0xe4/0x1c8\n[ ] vfs_writev+0x128/0x2b0\n[ ] do_writev+0xfc/0x118\n[ ] __arm64_sys_writev+0x20/0x2c\n[ ] invoke_syscall+0x68/0xf0\n[ ] el0_svc_common.constprop.0+0x40/0xe0\n[ ] do_el0_svc+0x1c/0x28\n[ ] el0_svc+0x30/0xd0\n[ ] el0t_64_sync_handler+0x100/0x12c\n[ ] el0t_64_sync+0x194/0x198\n[ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)\n[ ] ---[ end trace 0000000000000000 ]---(CVE-2025-38593)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: make rdev_addable usable for rcu mode\n\nOur testcase trigger panic:\n\nBUG: kernel NULL pointer dereference, address: 00000000000000e0\n...\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94\nPREEMPT(none)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nWorkqueue: md_misc md_start_sync\nRIP: 0010:rdev_addable+0x4d/0xf0\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n md_start_sync+0x329/0x480\n process_one_work+0x226/0x6d0\n worker_thread+0x19e/0x340\n kthread+0x10f/0x250\n ret_from_fork+0x14d/0x180\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in: raid10\nCR2: 00000000000000e0\n---[ end trace 0000000000000000 ]---\nRIP: 0010:rdev_addable+0x4d/0xf0\n\nmd_spares_need_change in md_start_sync will call rdev_addable which\nprotected by rcu_read_lock/rcu_read_unlock. This rcu context will help\nprotect rdev won\u0026apos;t be released, but rdev-\u0026gt;mddev will be set to NULL\nbefore we call synchronize_rcu in md_kick_rdev_from_array. Fix this by\nusing READ_ONCE and check does rdev-\u0026gt;mddev still alive.(CVE-2025-38621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: davinci: Add NULL check in davinci_lpsc_clk_register()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\ndavinci_lpsc_clk_register() does not check for this case, which results\nin a NULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue and ensuring\nno resources are left allocated.(CVE-2025-38635)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Check device memory pointer before usage\n\nAdd a NULL check before accessing device memory to prevent a crash if\ndev-\u0026gt;dm allocation in mlx5_init_once() fails.(CVE-2025-38645)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: fix race between polling and detaching\n\nsyzbot reports a use-after-free in comedi in the below link, which is\ndue to comedi gladly removing the allocated async area even though poll\nrequests are still active on the wait_queue_head inside of it. This can\ncause a use-after-free when the poll entries are later triggered or\nremoved, as the memory for the wait_queue_head has been freed. We need\nto check there are no tasks queued on any of the subdevices\u0026apos; wait queues\nbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`\nioctl.\n\nTasks will read-lock `dev-\u0026gt;attach_lock` before adding themselves to the\nsubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl\nhandler by write-locking `dev-\u0026gt;attach_lock` before checking that all of\nthe subdevices are safe to be deleted. This includes testing for any\nsleepers on the subdevices\u0026apos; wait queues. It remains locked until the\ndevice has been detached. This requires the `comedi_device_detach()`\nfunction to be refactored slightly, moving the bulk of it into new\nfunction `comedi_device_detach_locked()`.\n\nNote that the refactor of `comedi_device_detach()` results in\n`comedi_device_cancel_all()` now being called while `dev-\u0026gt;attach_lock`\nis write-locked, which wasn\u0026apos;t the case previously, but that does not\nmatter.\n\nThanks to Jens Axboe for diagnosing the problem and co-developing this\npatch.(CVE-2025-38687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Also allocate and copy hash for reading of filter files\n\nCurrently the reader of set_ftrace_filter and set_ftrace_notrace just adds\nthe pointer to the global tracer hash to its iterator. Unlike the writer\nthat allocates a copy of the hash, the reader keeps the pointer to the\nfilter hashes. This is problematic because this pointer is static across\nfunction calls that release the locks that can update the global tracer\nhashes. This can cause UAF and similar bugs.\n\nAllocate and copy the hash for reading the filter files like it is done\nfor the writers. This not only fixes UAF bugs, but also makes the code a\nbit simpler as it doesn\u0026apos;t have to differentiate when to free the\niterator\u0026apos;s hash between writers and readers.(CVE-2025-39689)",
"id": "OESA-2025-2268",
"modified": "2026-08-06T11:09:20Z",
"published": "2025-09-12T11:09:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2268"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21962"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37932"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38177"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38227"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38334"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38494"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38502"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38574"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38584"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38590"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38593"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38621"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38645"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39689"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21934",
"CVE-2025-21962",
"CVE-2025-21967",
"CVE-2025-37924",
"CVE-2025-37932",
"CVE-2025-38102",
"CVE-2025-38119",
"CVE-2025-38177",
"CVE-2025-38227",
"CVE-2025-38305",
"CVE-2025-38312",
"CVE-2025-38334",
"CVE-2025-38399",
"CVE-2025-38494",
"CVE-2025-38502",
"CVE-2025-38574",
"CVE-2025-38584",
"CVE-2025-38590",
"CVE-2025-38593",
"CVE-2025-38621",
"CVE-2025-38635",
"CVE-2025-38645",
"CVE-2025-38687",
"CVE-2025-39689"
]
}
OESA-2025-2269 (CVE-2025-21934)
Vulnerability from osv_openeuler – Published: 2025-09-12 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
rapidio: fix an API misues when rio_add_net() fails
rio_add_net() calls device_register() and fails when device_register() fails. Thus, put_device() should be used rather than kfree(). Add "mport->net = NULL;" to avoid a use after free issue.(CVE-2025-21934)
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix integer overflow while processing closetimeo mount option
User-provided mount parameter closetimeo of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbd_free_work_struct
->interim_entry of ksmbd_work could be deleted after oplock is freed. We don't need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed.(CVE-2025-21967)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in kerberos authentication
Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.(CVE-2025-37924)
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio as follow:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: <TASK> follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast.(CVE-2025-38102)
In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before.(CVE-2025-38119)
In the Linux kernel's vidtv driver, a slab-use-after-free vulnerability was discovered when the program incorrectly continued accessing the freed memory structure member 'si' after PSI initialization failure. This vulnerability could potentially lead to kernel crashes or information disclosure.(CVE-2025-38227)
In the Linux kernel, a recursive locking issue was identified in the ptp_vclock_in_use() function. When reading ptp->n_vclocks through ptp->n_vclocks_mux, it triggers a recursive lock call chain starting from n_vclocks_store(), leading to a potential deadlock. The root cause is the redundant check for ptp->n_vclocks in ptp_vclock_in_use(), as other functions already ensure ptp->n_vclocks is checked before unregistering vclocks.(CVE-2025-38305)
In the Linux kernel, a vulnerability has been identified in the fbdev core component's fbcvt module. When mode->refresh is set to 0x80000000, in the fb_find_mode_cvt() function, cvt.f_refresh becomes 0 due to overflow. This value is then passed to fb_cvt_hperiod() where it is used as a divisor, leading to a division by zero error and potential kernel crash. This vulnerability was discovered by the Linux Verification Center using the Svace static analysis tool.(CVE-2025-38312)
In the Linux kernel's x86/sgx component, a vulnerability exists that allows attempts to reclaim SGX pages marked as poisoned. The SGX page reclamation process accesses page contents to copy them to secondary storage, but SGX instructions cannot gracefully handle Machine Check Exceptions (MCE). Existing code fails to check the epc_page->poison flag, potentially causing reclamation operations on known poisoned pages, which may lead to core shutdowns or kernel panics. This vulnerability is triggered through the memory error notification path and requires prevention of poisoned pages being added to reclamation candidate lists.(CVE-2025-38334)
A NULL pointer dereference vulnerability exists in the Linux kernel's target subsystem. The function core_scsi3_decode_spec_i_port() unconditionally calls core_scsi3_lunacl_undepend_item() passing a potentially NULL dest_se_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix oob access in cgroup local storage
Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context:
ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype];
if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);
For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access.
To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.(CVE-2025-38502)
In the Linux kernel, the following vulnerability has been resolved:
pptp: ensure minimal skb length in pptp_xmit()
Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on ppp_sync_txmung") fixed ppp_sync_txmunge()
We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot.
BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix pd UAF once and for all
There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker.
This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue.
In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away.
Fix this by getting the next padata before the squeue->serial lock is released.
In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.(CVE-2025-38584)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Remove skb secpath if xfrm state is not found
Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup.
Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0.
Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer.
This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath.
BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 </IRQ>(CVE-2025-38590)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'
Function 'hci_discovery_filter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race:
'hci_cmd_sync_work()'
'update_passive_scan_sync()'
'hci_update_passive_scan_sync()'
'hci_discovery_filter_clear()'
kfree(uuids);
<-------------------------preempted-------------------------------->
'start_service_discovery()'
'hci_discovery_filter_clear()'
kfree(uuids); // DOUBLE FREE
<-------------------------preempted-------------------------------->
uuids = NULL;
To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires:
[ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]---(CVE-2025-38593)
In the Linux kernel, the following vulnerability has been resolved:
md: make rdev_addable usable for rcu mode
Our testcase trigger panic:
BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: <TASK> md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0
md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive.(CVE-2025-38621)
In the Linux kernel, the following vulnerability has been resolved:
clk: davinci: Add NULL check in davinci_lpsc_clk_register()
devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated.(CVE-2025-38635)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Check device memory pointer before usage
Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5_init_once() fails.(CVE-2025-38645)
In the Linux kernel, the following vulnerability has been resolved:
comedi: fix race between polling and detaching
syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed. We need
to check there are no tasks queued on any of the subdevices' wait queues
before allowing the device to be detached by the COMEDI_DEVCONFIG
ioctl.
Tasks will read-lock dev->attach_lock before adding themselves to the
subdevice wait queue, so fix the problem in the COMEDI_DEVCONFIG ioctl
handler by write-locking dev->attach_lock before checking that all of
the subdevices are safe to be deleted. This includes testing for any
sleepers on the subdevices' wait queues. It remains locked until the
device has been detached. This requires the comedi_device_detach()
function to be refactored slightly, moving the bulk of it into new
function comedi_device_detach_locked().
Note that the refactor of comedi_device_detach() results in
comedi_device_cancel_all() now being called while dev->attach_lock
is write-locked, which wasn't the case previously, but that does not
matter.
Thanks to Jens Axboe for diagnosing the problem and co-developing this patch.(CVE-2025-38687)
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Also allocate and copy hash for reading of filter files
Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs.
Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers.(CVE-2025-39689)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"perf-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-109.0.0.112.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-109.0.0.112.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"perf-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-109.0.0.112.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-109.0.0.112.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-109.0.0.112.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\nrapidio: fix an API misues when rio_add_net() fails\n\nrio_add_net() calls device_register() and fails when device_register()\nfails. Thus, put_device() should be used rather than kfree(). Add\n\u0026quot;mport-\u0026gt;net = NULL;\u0026quot; to avoid a use after free issue.(CVE-2025-21934)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix integer overflow while processing closetimeo mount option\n\nUser-provided mount parameter closetimeo of type u32 is intended to have\nan upper limit, but before it is validated, the value is converted from\nseconds to jiffies which can lead to an integer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_free_work_struct\n\n-\u0026gt;interim_entry of ksmbd_work could be deleted after oplock is freed.\nWe don\u0026apos;t need to manage it with linked list. The interim request could be\nimmediately sent whenever a oplock break wait is needed.(CVE-2025-21967)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in kerberos authentication\n\nSetting sess-\u0026gt;user = NULL was introduced to fix the dangling pointer\ncreated by ksmbd_free_user. However, it is possible another thread could\nbe operating on the session and make use of sess-\u0026gt;user after it has been\npassed to ksmbd_free_user but before sess-\u0026gt;user is set to NULL.(CVE-2025-37924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n Modules linked in:\n CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n RIP: 0010:try_grab_folio+0x106/0x130\n Call Trace:\n \u0026lt;TASK\u0026gt;\n follow_huge_pmd+0x240/0x8e0\n follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n follow_page_mask+0x1c2/0x1f0\n __get_user_pages+0x176/0x950\n __gup_longterm_locked+0x15b/0x1060\n ? gup_fast+0x120/0x1f0\n gup_fast_fallback+0x17e/0x230\n get_user_pages_fast+0x5f/0x80\n vmci_host_unlocked_ioctl+0x21c/0xf80\n RIP: 0033:0x54d2cd\n ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context-\u0026gt;notify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, \u0026amp;context-\u0026gt;notify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd // update \u0026amp;context-\u0026gt;notify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context-\u0026gt;notify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.(CVE-2025-38102)\n\nIn the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before.(CVE-2025-38119)\n\nIn the Linux kernel\u0026apos;s vidtv driver, a slab-use-after-free vulnerability was discovered when the program incorrectly continued accessing the freed memory structure member \u0026apos;si\u0026apos; after PSI initialization failure. This vulnerability could potentially lead to kernel crashes or information disclosure.(CVE-2025-38227)\n\nIn the Linux kernel, a recursive locking issue was identified in the ptp_vclock_in_use() function. When reading ptp-\u0026gt;n_vclocks through ptp-\u0026gt;n_vclocks_mux, it triggers a recursive lock call chain starting from n_vclocks_store(), leading to a potential deadlock. The root cause is the redundant check for ptp-\u0026gt;n_vclocks in ptp_vclock_in_use(), as other functions already ensure ptp-\u0026gt;n_vclocks is checked before unregistering vclocks.(CVE-2025-38305)\n\nIn the Linux kernel, a vulnerability has been identified in the fbdev core component\u0026apos;s fbcvt module. When mode-\u0026gt;refresh is set to 0x80000000, in the fb_find_mode_cvt() function, cvt.f_refresh becomes 0 due to overflow. This value is then passed to fb_cvt_hperiod() where it is used as a divisor, leading to a division by zero error and potential kernel crash. This vulnerability was discovered by the Linux Verification Center using the Svace static analysis tool.(CVE-2025-38312)\n\nIn the Linux kernel\u0026apos;s x86/sgx component, a vulnerability exists that allows attempts to reclaim SGX pages marked as poisoned. The SGX page reclamation process accesses page contents to copy them to secondary storage, but SGX instructions cannot gracefully handle Machine Check Exceptions (MCE). Existing code fails to check the epc_page-\u0026gt;poison flag, potentially causing reclamation operations on known poisoned pages, which may lead to core shutdowns or kernel panics. This vulnerability is triggered through the memory error notification path and requires prevention of poisoned pages being added to reclamation candidate lists.(CVE-2025-38334)\n\nA NULL pointer dereference vulnerability exists in the Linux kernel\u0026apos;s target subsystem. The function core_scsi3_decode_spec_i_port() unconditionally calls core_scsi3_lunacl_undepend_item() passing a potentially NULL dest_se_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix oob access in cgroup local storage\n\nLonial reported that an out-of-bounds access in cgroup local storage\ncan be crafted via tail calls. Given two programs each utilizing a\ncgroup local storage with a different value size, and one program\ndoing a tail call into the other. The verifier will validate each of\nthe indivial programs just fine. However, in the runtime context\nthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains the\nBPF program as well as any cgroup local storage flavor the program\nuses. Helpers such as bpf_get_local_storage() pick this up from the\nruntime context:\n\n ctx = container_of(current-\u0026gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);\n storage = ctx-\u0026gt;prog_item-\u0026gt;cgroup_storage[stype];\n\n if (stype == BPF_CGROUP_STORAGE_SHARED)\n ptr = \u0026amp;READ_ONCE(storage-\u0026gt;buf)-\u0026gt;data[0];\n else\n ptr = this_cpu_ptr(storage-\u0026gt;percpu_buf);\n\nFor the second program which was called from the originally attached\none, this means bpf_get_local_storage() will pick up the former\nprogram\u0026apos;s map, not its own. With mismatching sizes, this can result\nin an unintended out-of-bounds access.\n\nTo fix this issue, we need to extend bpf_map_owner with an array of\nstorage_cookie[] to match on i) the exact maps from the original\nprogram if the second program was using bpf_get_local_storage(), or\nii) allow the tail call combination if the second program was not\nusing any of the cgroup local storage maps.(CVE-2025-38502)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npptp: ensure minimal skb length in pptp_xmit()\n\nCommit aabc6596ffb3 (\u0026quot;net: ppp: Add bound checking for skb data\non ppp_sync_txmung\u0026quot;) fixed ppp_sync_txmunge()\n\nWe need a similar fix in pptp_xmit(), otherwise we might\nread uninit data as reported by syzbot.\n\nBUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]\n ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314\n pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379\n sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n __release_sock+0x1d3/0x330 net/core/sock.c:3213\n release_sock+0x6b/0x270 net/core/sock.c:3767\n pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:727\n ____sys_sendmsg+0x893/0xd80 net/socket.c:2566\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620\n __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit. A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly. If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u0026gt;serial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u0026gt;serial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives.(CVE-2025-38584)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Remove skb secpath if xfrm state is not found\n\nHardware returns a unique identifier for a decrypted packet\u0026apos;s xfrm\nstate, this state is looked up in an xarray. However, the state might\nhave been freed by the time of this lookup.\n\nCurrently, if the state is not found, only a counter is incremented.\nThe secpath (sp) extension on the skb is not removed, resulting in\nsp-\u0026gt;len becoming 0.\n\nSubsequently, functions like __xfrm_policy_check() attempt to access\nfields such as xfrm_input_state(skb)-\u0026gt;xso.type (which dereferences\nsp-\u0026gt;xvec[sp-\u0026gt;len - 1]) without first validating sp-\u0026gt;len. This leads to\na crash when dereferencing an invalid state pointer.\n\nThis patch prevents the crash by explicitly removing the secpath\nextension from the skb if the xfrm state is not found after hardware\ndecryption. This ensures downstream functions do not operate on a\nzero-length secpath.\n\n BUG: unable to handle page fault for address: ffffffff000002c8\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 282e067 P4D 282e067 PUD 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__xfrm_policy_check+0x61a/0xa30\n Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 \u0026lt;0f\u0026gt; b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa\n RSP: 0018:ffff88885fb04918 EFLAGS: 00010297\n RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000\n RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000\n RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353\n R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8\n R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00\n FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? try_to_wake_up+0x108/0x4c0\n ? udp4_lib_lookup2+0xbe/0x150\n ? udp_lib_lport_inuse+0x100/0x100\n ? __udp4_lib_lookup+0x2b0/0x410\n __xfrm_policy_check2.constprop.0+0x11e/0x130\n udp_queue_rcv_one_skb+0x1d/0x530\n udp_unicast_rcv_skb+0x76/0x90\n __udp4_lib_rcv+0xa64/0xe90\n ip_protocol_deliver_rcu+0x20/0x130\n ip_local_deliver_finish+0x75/0xa0\n ip_local_deliver+0xc1/0xd0\n ? ip_protocol_deliver_rcu+0x130/0x130\n ip_sublist_rcv+0x1f9/0x240\n ? ip_rcv_finish_core+0x430/0x430\n ip_list_rcv+0xfc/0x130\n __netif_receive_skb_list_core+0x181/0x1e0\n netif_receive_skb_list_internal+0x200/0x360\n ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]\n gro_receive_skb+0xfd/0x210\n mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]\n mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]\n ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]\n mlx5e_napi_poll+0x114/0xab0 [mlx5_core]\n __napi_poll+0x25/0x170\n net_rx_action+0x32d/0x3a0\n ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]\n ? notifier_call_chain+0x33/0xa0\n handle_softirqs+0xda/0x250\n irq_exit_rcu+0x6d/0xc0\n common_interrupt+0x81/0xa0\n \u0026lt;/IRQ\u0026gt;(CVE-2025-38590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix double free in \u0026apos;hci_discovery_filter_clear()\u0026apos;\n\nFunction \u0026apos;hci_discovery_filter_clear()\u0026apos; frees \u0026apos;uuids\u0026apos; array and then\nsets it to NULL. There is a tiny chance of the following race:\n\n\u0026apos;hci_cmd_sync_work()\u0026apos;\n\n \u0026apos;update_passive_scan_sync()\u0026apos;\n\n \u0026apos;hci_update_passive_scan_sync()\u0026apos;\n\n \u0026apos;hci_discovery_filter_clear()\u0026apos;\n kfree(uuids);\n\n \u0026lt;-------------------------preempted--------------------------------\u0026gt;\n \u0026apos;start_service_discovery()\u0026apos;\n\n \u0026apos;hci_discovery_filter_clear()\u0026apos;\n kfree(uuids); // DOUBLE FREE\n\n \u0026lt;-------------------------preempted--------------------------------\u0026gt;\n\n uuids = NULL;\n\nTo fix it let\u0026apos;s add locking around \u0026apos;kfree()\u0026apos; call and NULL pointer\nassignment. Otherwise the following backtrace fires:\n\n[ ] ------------[ cut here ]------------\n[ ] kernel BUG at mm/slub.c:547!\n[ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n[ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1\n[ ] Tainted: [O]=OOT_MODULE\n[ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ ] pc : __slab_free+0xf8/0x348\n[ ] lr : __slab_free+0x48/0x348\n...\n[ ] Call trace:\n[ ] __slab_free+0xf8/0x348\n[ ] kfree+0x164/0x27c\n[ ] start_service_discovery+0x1d0/0x2c0\n[ ] hci_sock_sendmsg+0x518/0x924\n[ ] __sock_sendmsg+0x54/0x60\n[ ] sock_write_iter+0x98/0xf8\n[ ] do_iter_readv_writev+0xe4/0x1c8\n[ ] vfs_writev+0x128/0x2b0\n[ ] do_writev+0xfc/0x118\n[ ] __arm64_sys_writev+0x20/0x2c\n[ ] invoke_syscall+0x68/0xf0\n[ ] el0_svc_common.constprop.0+0x40/0xe0\n[ ] do_el0_svc+0x1c/0x28\n[ ] el0_svc+0x30/0xd0\n[ ] el0t_64_sync_handler+0x100/0x12c\n[ ] el0t_64_sync+0x194/0x198\n[ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)\n[ ] ---[ end trace 0000000000000000 ]---(CVE-2025-38593)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: make rdev_addable usable for rcu mode\n\nOur testcase trigger panic:\n\nBUG: kernel NULL pointer dereference, address: 00000000000000e0\n...\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94\nPREEMPT(none)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nWorkqueue: md_misc md_start_sync\nRIP: 0010:rdev_addable+0x4d/0xf0\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n md_start_sync+0x329/0x480\n process_one_work+0x226/0x6d0\n worker_thread+0x19e/0x340\n kthread+0x10f/0x250\n ret_from_fork+0x14d/0x180\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in: raid10\nCR2: 00000000000000e0\n---[ end trace 0000000000000000 ]---\nRIP: 0010:rdev_addable+0x4d/0xf0\n\nmd_spares_need_change in md_start_sync will call rdev_addable which\nprotected by rcu_read_lock/rcu_read_unlock. This rcu context will help\nprotect rdev won\u0026apos;t be released, but rdev-\u0026gt;mddev will be set to NULL\nbefore we call synchronize_rcu in md_kick_rdev_from_array. Fix this by\nusing READ_ONCE and check does rdev-\u0026gt;mddev still alive.(CVE-2025-38621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: davinci: Add NULL check in davinci_lpsc_clk_register()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\ndavinci_lpsc_clk_register() does not check for this case, which results\nin a NULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue and ensuring\nno resources are left allocated.(CVE-2025-38635)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Check device memory pointer before usage\n\nAdd a NULL check before accessing device memory to prevent a crash if\ndev-\u0026gt;dm allocation in mlx5_init_once() fails.(CVE-2025-38645)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: fix race between polling and detaching\n\nsyzbot reports a use-after-free in comedi in the below link, which is\ndue to comedi gladly removing the allocated async area even though poll\nrequests are still active on the wait_queue_head inside of it. This can\ncause a use-after-free when the poll entries are later triggered or\nremoved, as the memory for the wait_queue_head has been freed. We need\nto check there are no tasks queued on any of the subdevices\u0026apos; wait queues\nbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`\nioctl.\n\nTasks will read-lock `dev-\u0026gt;attach_lock` before adding themselves to the\nsubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl\nhandler by write-locking `dev-\u0026gt;attach_lock` before checking that all of\nthe subdevices are safe to be deleted. This includes testing for any\nsleepers on the subdevices\u0026apos; wait queues. It remains locked until the\ndevice has been detached. This requires the `comedi_device_detach()`\nfunction to be refactored slightly, moving the bulk of it into new\nfunction `comedi_device_detach_locked()`.\n\nNote that the refactor of `comedi_device_detach()` results in\n`comedi_device_cancel_all()` now being called while `dev-\u0026gt;attach_lock`\nis write-locked, which wasn\u0026apos;t the case previously, but that does not\nmatter.\n\nThanks to Jens Axboe for diagnosing the problem and co-developing this\npatch.(CVE-2025-38687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Also allocate and copy hash for reading of filter files\n\nCurrently the reader of set_ftrace_filter and set_ftrace_notrace just adds\nthe pointer to the global tracer hash to its iterator. Unlike the writer\nthat allocates a copy of the hash, the reader keeps the pointer to the\nfilter hashes. This is problematic because this pointer is static across\nfunction calls that release the locks that can update the global tracer\nhashes. This can cause UAF and similar bugs.\n\nAllocate and copy the hash for reading the filter files like it is done\nfor the writers. This not only fixes UAF bugs, but also makes the code a\nbit simpler as it doesn\u0026apos;t have to differentiate when to free the\niterator\u0026apos;s hash between writers and readers.(CVE-2025-39689)",
"id": "OESA-2025-2269",
"modified": "2026-08-06T11:09:20Z",
"published": "2025-09-12T11:09:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21962"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38227"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38334"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38502"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38574"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38584"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38590"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38593"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38621"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38645"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39689"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21934",
"CVE-2025-21962",
"CVE-2025-21967",
"CVE-2025-37924",
"CVE-2025-38102",
"CVE-2025-38119",
"CVE-2025-38227",
"CVE-2025-38305",
"CVE-2025-38312",
"CVE-2025-38334",
"CVE-2025-38399",
"CVE-2025-38502",
"CVE-2025-38574",
"CVE-2025-38584",
"CVE-2025-38590",
"CVE-2025-38593",
"CVE-2025-38621",
"CVE-2025-38635",
"CVE-2025-38645",
"CVE-2025-38687",
"CVE-2025-39689"
]
}
OESA-2025-2270 (CVE-2025-21962)
Vulnerability from osv_openeuler – Published: 2025-09-12 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix integer overflow while processing closetimeo mount option
User-provided mount parameter closetimeo of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in ksmbd_free_work_struct
->interim_entry of ksmbd_work could be deleted after oplock is freed. We don't need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed.(CVE-2025-21967)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in kerberos authentication
Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL.(CVE-2025-37924)
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio as follow:
------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: <TASK> follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast and can be seen in vmci_ctx_unset_notify which will try to put_page. However get_user_pages_fast is not finished here and lead to following try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1 vmci_host_do_set_notify vmci_host_setup_notify get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page); lockless_pages_from_mm gup_pgd_range gup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed __gup_longterm_locked __get_user_pages follow_trans_huge_pmd try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen after finish get_user_pages_fast.(CVE-2025-38102)
In the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before.(CVE-2025-38119)
In the Linux kernel's vidtv driver, a slab-use-after-free vulnerability was discovered when the program incorrectly continued accessing the freed memory structure member 'si' after PSI initialization failure. This vulnerability could potentially lead to kernel crashes or information disclosure.(CVE-2025-38227)
In the Linux kernel, a recursive locking issue was identified in the ptp_vclock_in_use() function. When reading ptp->n_vclocks through ptp->n_vclocks_mux, it triggers a recursive lock call chain starting from n_vclocks_store(), leading to a potential deadlock. The root cause is the redundant check for ptp->n_vclocks in ptp_vclock_in_use(), as other functions already ensure ptp->n_vclocks is checked before unregistering vclocks.(CVE-2025-38305)
In the Linux kernel, a vulnerability has been identified in the fbdev core component's fbcvt module. When mode->refresh is set to 0x80000000, in the fb_find_mode_cvt() function, cvt.f_refresh becomes 0 due to overflow. This value is then passed to fb_cvt_hperiod() where it is used as a divisor, leading to a division by zero error and potential kernel crash. This vulnerability was discovered by the Linux Verification Center using the Svace static analysis tool.(CVE-2025-38312)
In the Linux kernel's x86/sgx component, a vulnerability exists that allows attempts to reclaim SGX pages marked as poisoned. The SGX page reclamation process accesses page contents to copy them to secondary storage, but SGX instructions cannot gracefully handle Machine Check Exceptions (MCE). Existing code fails to check the epc_page->poison flag, potentially causing reclamation operations on known poisoned pages, which may lead to core shutdowns or kernel panics. This vulnerability is triggered through the memory error notification path and requires prevention of poisoned pages being added to reclamation candidate lists.(CVE-2025-38334)
A NULL pointer dereference vulnerability exists in the Linux kernel's target subsystem. The function core_scsi3_decode_spec_i_port() unconditionally calls core_scsi3_lunacl_undepend_item() passing a potentially NULL dest_se_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix oob access in cgroup local storage
Lonial reported that an out-of-bounds access in cgroup local storage can be crafted via tail calls. Given two programs each utilizing a cgroup local storage with a different value size, and one program doing a tail call into the other. The verifier will validate each of the indivial programs just fine. However, in the runtime context the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the BPF program as well as any cgroup local storage flavor the program uses. Helpers such as bpf_get_local_storage() pick this up from the runtime context:
ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype];
if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);
For the second program which was called from the originally attached one, this means bpf_get_local_storage() will pick up the former program's map, not its own. With mismatching sizes, this can result in an unintended out-of-bounds access.
To fix this issue, we need to extend bpf_map_owner with an array of storage_cookie[] to match on i) the exact maps from the original program if the second program was using bpf_get_local_storage(), or ii) allow the tail call combination if the second program was not using any of the cgroup local storage maps.(CVE-2025-38502)
In the Linux kernel, the following vulnerability has been resolved:
pptp: ensure minimal skb length in pptp_xmit()
Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on ppp_sync_txmung") fixed ppp_sync_txmunge()
We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot.
BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix pd UAF once and for all
There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker.
This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue.
In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away.
Fix this by getting the next padata before the squeue->serial lock is released.
In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.(CVE-2025-38584)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Remove skb secpath if xfrm state is not found
Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup.
Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0.
Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer.
This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath.
BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0 </IRQ>(CVE-2025-38590)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'
Function 'hci_discovery_filter_clear()' frees 'uuids' array and then sets it to NULL. There is a tiny chance of the following race:
'hci_cmd_sync_work()'
'update_passive_scan_sync()'
'hci_update_passive_scan_sync()'
'hci_discovery_filter_clear()'
kfree(uuids);
<-------------------------preempted-------------------------------->
'start_service_discovery()'
'hci_discovery_filter_clear()'
kfree(uuids); // DOUBLE FREE
<-------------------------preempted-------------------------------->
uuids = NULL;
To fix it let's add locking around 'kfree()' call and NULL pointer assignment. Otherwise the following backtrace fires:
[ ] ------------[ cut here ]------------ [ ] kernel BUG at mm/slub.c:547! [ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1 [ ] Tainted: [O]=OOT_MODULE [ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : __slab_free+0xf8/0x348 [ ] lr : __slab_free+0x48/0x348 ... [ ] Call trace: [ ] __slab_free+0xf8/0x348 [ ] kfree+0x164/0x27c [ ] start_service_discovery+0x1d0/0x2c0 [ ] hci_sock_sendmsg+0x518/0x924 [ ] __sock_sendmsg+0x54/0x60 [ ] sock_write_iter+0x98/0xf8 [ ] do_iter_readv_writev+0xe4/0x1c8 [ ] vfs_writev+0x128/0x2b0 [ ] do_writev+0xfc/0x118 [ ] __arm64_sys_writev+0x20/0x2c [ ] invoke_syscall+0x68/0xf0 [ ] el0_svc_common.constprop.0+0x40/0xe0 [ ] do_el0_svc+0x1c/0x28 [ ] el0_svc+0x30/0xd0 [ ] el0t_64_sync_handler+0x100/0x12c [ ] el0t_64_sync+0x194/0x198 [ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000) [ ] ---[ end trace 0000000000000000 ]---(CVE-2025-38593)
In the Linux kernel, the following vulnerability has been resolved:
md: make rdev_addable usable for rcu mode
Our testcase trigger panic:
BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... Oops: Oops: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94 PREEMPT(none) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Workqueue: md_misc md_start_sync RIP: 0010:rdev_addable+0x4d/0xf0 ... Call Trace: <TASK> md_start_sync+0x329/0x480 process_one_work+0x226/0x6d0 worker_thread+0x19e/0x340 kthread+0x10f/0x250 ret_from_fork+0x14d/0x180 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: raid10 CR2: 00000000000000e0 ---[ end trace 0000000000000000 ]--- RIP: 0010:rdev_addable+0x4d/0xf0
md_spares_need_change in md_start_sync will call rdev_addable which protected by rcu_read_lock/rcu_read_unlock. This rcu context will help protect rdev won't be released, but rdev->mddev will be set to NULL before we call synchronize_rcu in md_kick_rdev_from_array. Fix this by using READ_ONCE and check does rdev->mddev still alive.(CVE-2025-38621)
In the Linux kernel, the following vulnerability has been resolved:
clk: davinci: Add NULL check in davinci_lpsc_clk_register()
devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated.(CVE-2025-38635)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Check device memory pointer before usage
Add a NULL check before accessing device memory to prevent a crash if dev->dm allocation in mlx5_init_once() fails.(CVE-2025-38645)
In the Linux kernel, the following vulnerability has been resolved:
comedi: fix race between polling and detaching
syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed. We need
to check there are no tasks queued on any of the subdevices' wait queues
before allowing the device to be detached by the COMEDI_DEVCONFIG
ioctl.
Tasks will read-lock dev->attach_lock before adding themselves to the
subdevice wait queue, so fix the problem in the COMEDI_DEVCONFIG ioctl
handler by write-locking dev->attach_lock before checking that all of
the subdevices are safe to be deleted. This includes testing for any
sleepers on the subdevices' wait queues. It remains locked until the
device has been detached. This requires the comedi_device_detach()
function to be refactored slightly, moving the bulk of it into new
function comedi_device_detach_locked().
Note that the refactor of comedi_device_detach() results in
comedi_device_cancel_all() now being called while dev->attach_lock
is write-locked, which wasn't the case previously, but that does not
matter.
Thanks to Jens Axboe for diagnosing the problem and co-developing this patch.(CVE-2025-38687)
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Also allocate and copy hash for reading of filter files
Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds the pointer to the global tracer hash to its iterator. Unlike the writer that allocates a copy of the hash, the reader keeps the pointer to the filter hashes. This is problematic because this pointer is static across function calls that release the locks that can update the global tracer hashes. This can cause UAF and similar bugs.
Allocate and copy the hash for reading the filter files like it is done for the writers. This not only fixes UAF bugs, but also makes the code a bit simpler as it doesn't have to differentiate when to free the iterator's hash between writers and readers.(CVE-2025-39689)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"perf-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-109.0.0.115.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-109.0.0.115.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"perf-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-109.0.0.115.oe2403sp2.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP2",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-109.0.0.115.oe2403sp2"
}
],
"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\ncifs: Fix integer overflow while processing closetimeo mount option\n\nUser-provided mount parameter closetimeo of type u32 is intended to have\nan upper limit, but before it is validated, the value is converted from\nseconds to jiffies which can lead to an integer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-21962)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in ksmbd_free_work_struct\n\n-\u0026gt;interim_entry of ksmbd_work could be deleted after oplock is freed.\nWe don\u0026apos;t need to manage it with linked list. The interim request could be\nimmediately sent whenever a oplock break wait is needed.(CVE-2025-21967)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in kerberos authentication\n\nSetting sess-\u0026gt;user = NULL was introduced to fix the dangling pointer\ncreated by ksmbd_free_user. However, it is possible another thread could\nbe operating on the session and make use of sess-\u0026gt;user after it has been\npassed to ksmbd_free_user but before sess-\u0026gt;user is set to NULL.(CVE-2025-37924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify\n\nDuring our test, it is found that a warning can be trigger in try_grab_folio\nas follow:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130\n Modules linked in:\n CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)\n RIP: 0010:try_grab_folio+0x106/0x130\n Call Trace:\n \u0026lt;TASK\u0026gt;\n follow_huge_pmd+0x240/0x8e0\n follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0\n follow_pud_mask.constprop.0.isra.0+0x14a/0x170\n follow_page_mask+0x1c2/0x1f0\n __get_user_pages+0x176/0x950\n __gup_longterm_locked+0x15b/0x1060\n ? gup_fast+0x120/0x1f0\n gup_fast_fallback+0x17e/0x230\n get_user_pages_fast+0x5f/0x80\n vmci_host_unlocked_ioctl+0x21c/0xf80\n RIP: 0033:0x54d2cd\n ---[ end trace 0000000000000000 ]---\n\nDigging into the source, context-\u0026gt;notify_page may init by get_user_pages_fast\nand can be seen in vmci_ctx_unset_notify which will try to put_page. However\nget_user_pages_fast is not finished here and lead to following\ntry_grab_folio warning. The race condition is shown as follow:\n\ncpu0\t\t\tcpu1\nvmci_host_do_set_notify\nvmci_host_setup_notify\nget_user_pages_fast(uva, 1, FOLL_WRITE, \u0026amp;context-\u0026gt;notify_page);\nlockless_pages_from_mm\ngup_pgd_range\ngup_huge_pmd // update \u0026amp;context-\u0026gt;notify_page\n\t\t\tvmci_host_do_set_notify\n\t\t\tvmci_ctx_unset_notify\n\t\t\tnotify_page = context-\u0026gt;notify_page;\n\t\t\tif (notify_page)\n\t\t\tput_page(notify_page);\t// page is freed\n__gup_longterm_locked\n__get_user_pages\nfollow_trans_huge_pmd\ntry_grab_folio // warn here\n\nTo slove this, use local variable page to make notify_page can be seen\nafter finish get_user_pages_fast.(CVE-2025-38102)\n\nIn the Linux kernel, the following vulnerability has been resolved: scsi: core: ufs: Fix a hang in the error handler. ufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latter function can only succeed if UFSHCD_EH_IN_PROGRESS is not set because resuming involves submitting a SCSI command and ufshcd_queuecommand() returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix this hang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() has been called instead of before.(CVE-2025-38119)\n\nIn the Linux kernel\u0026apos;s vidtv driver, a slab-use-after-free vulnerability was discovered when the program incorrectly continued accessing the freed memory structure member \u0026apos;si\u0026apos; after PSI initialization failure. This vulnerability could potentially lead to kernel crashes or information disclosure.(CVE-2025-38227)\n\nIn the Linux kernel, a recursive locking issue was identified in the ptp_vclock_in_use() function. When reading ptp-\u0026gt;n_vclocks through ptp-\u0026gt;n_vclocks_mux, it triggers a recursive lock call chain starting from n_vclocks_store(), leading to a potential deadlock. The root cause is the redundant check for ptp-\u0026gt;n_vclocks in ptp_vclock_in_use(), as other functions already ensure ptp-\u0026gt;n_vclocks is checked before unregistering vclocks.(CVE-2025-38305)\n\nIn the Linux kernel, a vulnerability has been identified in the fbdev core component\u0026apos;s fbcvt module. When mode-\u0026gt;refresh is set to 0x80000000, in the fb_find_mode_cvt() function, cvt.f_refresh becomes 0 due to overflow. This value is then passed to fb_cvt_hperiod() where it is used as a divisor, leading to a division by zero error and potential kernel crash. This vulnerability was discovered by the Linux Verification Center using the Svace static analysis tool.(CVE-2025-38312)\n\nIn the Linux kernel\u0026apos;s x86/sgx component, a vulnerability exists that allows attempts to reclaim SGX pages marked as poisoned. The SGX page reclamation process accesses page contents to copy them to secondary storage, but SGX instructions cannot gracefully handle Machine Check Exceptions (MCE). Existing code fails to check the epc_page-\u0026gt;poison flag, potentially causing reclamation operations on known poisoned pages, which may lead to core shutdowns or kernel panics. This vulnerability is triggered through the memory error notification path and requires prevention of poisoned pages being added to reclamation candidate lists.(CVE-2025-38334)\n\nA NULL pointer dereference vulnerability exists in the Linux kernel\u0026apos;s target subsystem. The function core_scsi3_decode_spec_i_port() unconditionally calls core_scsi3_lunacl_undepend_item() passing a potentially NULL dest_se_deve pointer in its error handling path, leading to kernel NULL pointer dereference. This vulnerability could be exploited to cause kernel crashes.(CVE-2025-38399)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix oob access in cgroup local storage\n\nLonial reported that an out-of-bounds access in cgroup local storage\ncan be crafted via tail calls. Given two programs each utilizing a\ncgroup local storage with a different value size, and one program\ndoing a tail call into the other. The verifier will validate each of\nthe indivial programs just fine. However, in the runtime context\nthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains the\nBPF program as well as any cgroup local storage flavor the program\nuses. Helpers such as bpf_get_local_storage() pick this up from the\nruntime context:\n\n ctx = container_of(current-\u0026gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);\n storage = ctx-\u0026gt;prog_item-\u0026gt;cgroup_storage[stype];\n\n if (stype == BPF_CGROUP_STORAGE_SHARED)\n ptr = \u0026amp;READ_ONCE(storage-\u0026gt;buf)-\u0026gt;data[0];\n else\n ptr = this_cpu_ptr(storage-\u0026gt;percpu_buf);\n\nFor the second program which was called from the originally attached\none, this means bpf_get_local_storage() will pick up the former\nprogram\u0026apos;s map, not its own. With mismatching sizes, this can result\nin an unintended out-of-bounds access.\n\nTo fix this issue, we need to extend bpf_map_owner with an array of\nstorage_cookie[] to match on i) the exact maps from the original\nprogram if the second program was using bpf_get_local_storage(), or\nii) allow the tail call combination if the second program was not\nusing any of the cgroup local storage maps.(CVE-2025-38502)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npptp: ensure minimal skb length in pptp_xmit()\n\nCommit aabc6596ffb3 (\u0026quot;net: ppp: Add bound checking for skb data\non ppp_sync_txmung\u0026quot;) fixed ppp_sync_txmunge()\n\nWe need a similar fix in pptp_xmit(), otherwise we might\nread uninit data as reported by syzbot.\n\nBUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]\n ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314\n pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379\n sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n __release_sock+0x1d3/0x330 net/core/sock.c:3213\n release_sock+0x6b/0x270 net/core/sock.c:3767\n pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:727\n ____sys_sendmsg+0x893/0xd80 net/socket.c:2566\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620\n __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit. A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly. If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u0026gt;serial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u0026gt;serial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives.(CVE-2025-38584)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Remove skb secpath if xfrm state is not found\n\nHardware returns a unique identifier for a decrypted packet\u0026apos;s xfrm\nstate, this state is looked up in an xarray. However, the state might\nhave been freed by the time of this lookup.\n\nCurrently, if the state is not found, only a counter is incremented.\nThe secpath (sp) extension on the skb is not removed, resulting in\nsp-\u0026gt;len becoming 0.\n\nSubsequently, functions like __xfrm_policy_check() attempt to access\nfields such as xfrm_input_state(skb)-\u0026gt;xso.type (which dereferences\nsp-\u0026gt;xvec[sp-\u0026gt;len - 1]) without first validating sp-\u0026gt;len. This leads to\na crash when dereferencing an invalid state pointer.\n\nThis patch prevents the crash by explicitly removing the secpath\nextension from the skb if the xfrm state is not found after hardware\ndecryption. This ensures downstream functions do not operate on a\nzero-length secpath.\n\n BUG: unable to handle page fault for address: ffffffff000002c8\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 282e067 P4D 282e067 PUD 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__xfrm_policy_check+0x61a/0xa30\n Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 \u0026lt;0f\u0026gt; b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa\n RSP: 0018:ffff88885fb04918 EFLAGS: 00010297\n RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000\n RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000\n RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353\n R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8\n R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00\n FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;IRQ\u0026gt;\n ? try_to_wake_up+0x108/0x4c0\n ? udp4_lib_lookup2+0xbe/0x150\n ? udp_lib_lport_inuse+0x100/0x100\n ? __udp4_lib_lookup+0x2b0/0x410\n __xfrm_policy_check2.constprop.0+0x11e/0x130\n udp_queue_rcv_one_skb+0x1d/0x530\n udp_unicast_rcv_skb+0x76/0x90\n __udp4_lib_rcv+0xa64/0xe90\n ip_protocol_deliver_rcu+0x20/0x130\n ip_local_deliver_finish+0x75/0xa0\n ip_local_deliver+0xc1/0xd0\n ? ip_protocol_deliver_rcu+0x130/0x130\n ip_sublist_rcv+0x1f9/0x240\n ? ip_rcv_finish_core+0x430/0x430\n ip_list_rcv+0xfc/0x130\n __netif_receive_skb_list_core+0x181/0x1e0\n netif_receive_skb_list_internal+0x200/0x360\n ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]\n gro_receive_skb+0xfd/0x210\n mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]\n mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]\n ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]\n mlx5e_napi_poll+0x114/0xab0 [mlx5_core]\n __napi_poll+0x25/0x170\n net_rx_action+0x32d/0x3a0\n ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]\n ? notifier_call_chain+0x33/0xa0\n handle_softirqs+0xda/0x250\n irq_exit_rcu+0x6d/0xc0\n common_interrupt+0x81/0xa0\n \u0026lt;/IRQ\u0026gt;(CVE-2025-38590)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: fix double free in \u0026apos;hci_discovery_filter_clear()\u0026apos;\n\nFunction \u0026apos;hci_discovery_filter_clear()\u0026apos; frees \u0026apos;uuids\u0026apos; array and then\nsets it to NULL. There is a tiny chance of the following race:\n\n\u0026apos;hci_cmd_sync_work()\u0026apos;\n\n \u0026apos;update_passive_scan_sync()\u0026apos;\n\n \u0026apos;hci_update_passive_scan_sync()\u0026apos;\n\n \u0026apos;hci_discovery_filter_clear()\u0026apos;\n kfree(uuids);\n\n \u0026lt;-------------------------preempted--------------------------------\u0026gt;\n \u0026apos;start_service_discovery()\u0026apos;\n\n \u0026apos;hci_discovery_filter_clear()\u0026apos;\n kfree(uuids); // DOUBLE FREE\n\n \u0026lt;-------------------------preempted--------------------------------\u0026gt;\n\n uuids = NULL;\n\nTo fix it let\u0026apos;s add locking around \u0026apos;kfree()\u0026apos; call and NULL pointer\nassignment. Otherwise the following backtrace fires:\n\n[ ] ------------[ cut here ]------------\n[ ] kernel BUG at mm/slub.c:547!\n[ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n[ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1\n[ ] Tainted: [O]=OOT_MODULE\n[ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ ] pc : __slab_free+0xf8/0x348\n[ ] lr : __slab_free+0x48/0x348\n...\n[ ] Call trace:\n[ ] __slab_free+0xf8/0x348\n[ ] kfree+0x164/0x27c\n[ ] start_service_discovery+0x1d0/0x2c0\n[ ] hci_sock_sendmsg+0x518/0x924\n[ ] __sock_sendmsg+0x54/0x60\n[ ] sock_write_iter+0x98/0xf8\n[ ] do_iter_readv_writev+0xe4/0x1c8\n[ ] vfs_writev+0x128/0x2b0\n[ ] do_writev+0xfc/0x118\n[ ] __arm64_sys_writev+0x20/0x2c\n[ ] invoke_syscall+0x68/0xf0\n[ ] el0_svc_common.constprop.0+0x40/0xe0\n[ ] do_el0_svc+0x1c/0x28\n[ ] el0_svc+0x30/0xd0\n[ ] el0t_64_sync_handler+0x100/0x12c\n[ ] el0t_64_sync+0x194/0x198\n[ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)\n[ ] ---[ end trace 0000000000000000 ]---(CVE-2025-38593)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: make rdev_addable usable for rcu mode\n\nOur testcase trigger panic:\n\nBUG: kernel NULL pointer dereference, address: 00000000000000e0\n...\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 2 UID: 0 PID: 85 Comm: kworker/2:1 Not tainted 6.16.0+ #94\nPREEMPT(none)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nWorkqueue: md_misc md_start_sync\nRIP: 0010:rdev_addable+0x4d/0xf0\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n md_start_sync+0x329/0x480\n process_one_work+0x226/0x6d0\n worker_thread+0x19e/0x340\n kthread+0x10f/0x250\n ret_from_fork+0x14d/0x180\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in: raid10\nCR2: 00000000000000e0\n---[ end trace 0000000000000000 ]---\nRIP: 0010:rdev_addable+0x4d/0xf0\n\nmd_spares_need_change in md_start_sync will call rdev_addable which\nprotected by rcu_read_lock/rcu_read_unlock. This rcu context will help\nprotect rdev won\u0026apos;t be released, but rdev-\u0026gt;mddev will be set to NULL\nbefore we call synchronize_rcu in md_kick_rdev_from_array. Fix this by\nusing READ_ONCE and check does rdev-\u0026gt;mddev still alive.(CVE-2025-38621)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: davinci: Add NULL check in davinci_lpsc_clk_register()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\ndavinci_lpsc_clk_register() does not check for this case, which results\nin a NULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue and ensuring\nno resources are left allocated.(CVE-2025-38635)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Check device memory pointer before usage\n\nAdd a NULL check before accessing device memory to prevent a crash if\ndev-\u0026gt;dm allocation in mlx5_init_once() fails.(CVE-2025-38645)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: fix race between polling and detaching\n\nsyzbot reports a use-after-free in comedi in the below link, which is\ndue to comedi gladly removing the allocated async area even though poll\nrequests are still active on the wait_queue_head inside of it. This can\ncause a use-after-free when the poll entries are later triggered or\nremoved, as the memory for the wait_queue_head has been freed. We need\nto check there are no tasks queued on any of the subdevices\u0026apos; wait queues\nbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`\nioctl.\n\nTasks will read-lock `dev-\u0026gt;attach_lock` before adding themselves to the\nsubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl\nhandler by write-locking `dev-\u0026gt;attach_lock` before checking that all of\nthe subdevices are safe to be deleted. This includes testing for any\nsleepers on the subdevices\u0026apos; wait queues. It remains locked until the\ndevice has been detached. This requires the `comedi_device_detach()`\nfunction to be refactored slightly, moving the bulk of it into new\nfunction `comedi_device_detach_locked()`.\n\nNote that the refactor of `comedi_device_detach()` results in\n`comedi_device_cancel_all()` now being called while `dev-\u0026gt;attach_lock`\nis write-locked, which wasn\u0026apos;t the case previously, but that does not\nmatter.\n\nThanks to Jens Axboe for diagnosing the problem and co-developing this\npatch.(CVE-2025-38687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Also allocate and copy hash for reading of filter files\n\nCurrently the reader of set_ftrace_filter and set_ftrace_notrace just adds\nthe pointer to the global tracer hash to its iterator. Unlike the writer\nthat allocates a copy of the hash, the reader keeps the pointer to the\nfilter hashes. This is problematic because this pointer is static across\nfunction calls that release the locks that can update the global tracer\nhashes. This can cause UAF and similar bugs.\n\nAllocate and copy the hash for reading the filter files like it is done\nfor the writers. This not only fixes UAF bugs, but also makes the code a\nbit simpler as it doesn\u0026apos;t have to differentiate when to free the\niterator\u0026apos;s hash between writers and readers.(CVE-2025-39689)",
"id": "OESA-2025-2270",
"modified": "2026-08-06T11:09:20Z",
"published": "2025-09-12T11:09:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2270"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21962"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21967"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38227"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38312"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38334"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38399"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38502"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38574"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38584"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38590"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38593"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38621"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38635"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38645"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39689"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-21962",
"CVE-2025-21967",
"CVE-2025-37924",
"CVE-2025-38102",
"CVE-2025-38119",
"CVE-2025-38227",
"CVE-2025-38305",
"CVE-2025-38312",
"CVE-2025-38334",
"CVE-2025-38399",
"CVE-2025-38502",
"CVE-2025-38574",
"CVE-2025-38584",
"CVE-2025-38590",
"CVE-2025-38593",
"CVE-2025-38621",
"CVE-2025-38635",
"CVE-2025-38645",
"CVE-2025-38687",
"CVE-2025-39689"
]
}
OESA-2025-2886 (CVE-2022-49426)
Vulnerability from osv_openeuler – Published: 2025-12-30 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-v3-sva: Fix mm use-after-free
We currently call arm64_mm_context_put() without holding a reference to the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to ensure the mm only gets freed after we unpinned the ASID.(CVE-2022-49426)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit
Always purge mcu skb queues in mt7915_mcu_exit routine even if mt7915_firmware_state fails.(CVE-2023-53466)
printer_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact.(CVE-2024-25741)
In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ( net: Use nested-BH locking fornapi_alloc_cache. ) was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it s running in NAPI contexteven when it s not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.(CVE-2024-43835)
In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk->sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk->sk_user_data could be NULL.Let s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: <IRQ> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)</IRQ> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---(CVE-2024-46763)
In the Linux kernel, the following vulnerability has been resolved:f2fs: Require FMODE_WRITE for atomic write ioctlsThe F2FS ioctls for starting and committing atomic writes check forinode_owner_or_capable(), but this does not give LSMs like SELinux orLandlock an opportunity to deny the write access - if the caller s FSUIDmatches the inode s UID, inode_owner_or_capable() immediately returns true.There are scenarios where LSMs want to deny a process the ability to writeparticular files, even files that the FSUID of the process owns; but thiscan currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a fileFix it by requiring FMODE_WRITE for these operations, just like forF2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using theseioctls when intending to write into the file, that seems unlikely to breakanything.(CVE-2024-47740)
In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ( nfs: add support for large folios )).(CVE-2024-53138)
In the Linux kernel, the following vulnerability has been resolved:x86/xen: don t do PV iret hypercall through hypercall pageInstead of jumping to the Xen hypercall page for doing the irethypercall, directly code the required sequence in xen-asm.S.This is done in preparation of no longer using hypercall page at all,as it has shown to cause problems with speculation mitigations.This is part of XSA-466 / CVE-2024-53241.(CVE-2024-53241)
In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744)
In the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi s weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi s weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).(CVE-2025-21806)
In the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port->sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port->sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.(CVE-2025-21820)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix kmemleak warning for percpu hashmap
Vlad Poenaru reported the following kmemleak issue:
unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpu_alloc_noprof+0x730/0xeb0 bpf_map_alloc_percpu+0x69/0xc0 prealloc_init+0x9d/0x1b0 htab_map_alloc+0x363/0x510 map_create+0x215/0x3a0 __sys_bpf+0x16b/0x3e0 __x64_sys_bpf+0x18/0x20 do_syscall_64+0x7b/0x150 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr(): *(void __percpu **)(l->key + key_size) = pptr;
Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak.
In htab_map_alloc(), we already have
htab->elem_size = sizeof(struct htab_elem) +
round_up(htab->map.key_size, 8);
if (percpu)
htab->elem_size += sizeof(void *);
else
htab->elem_size += round_up(htab->map.value_size, 8);
So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too.
The issue can be reproduced with bpf selftest as well: 1. Enable CONFIG_DEBUG_KMEMLEAK config 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c. The purpose is to keep map available so kmemleak can be detected. 3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.(CVE-2025-37807)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix Preauh_HashValue race condition
If client send multiple session setup requests to ksmbd, Preauh_HashValue race condition could happen. There is no need to free sess->Preauh_HashValue at session setup phase. It can be freed together with session at connection termination phase.(CVE-2025-38561)
In the Linux kernel, the following vulnerability has been resolved:
padata: Fix pd UAF once and for all
There is a race condition/UAF in padata_reorder that goes back to the initial commit. A reference count is taken at the start of the process in padata_do_parallel, and released at the end in padata_serial_worker.
This reference count is (and only is) required for padata_replace to function correctly. If padata_replace is never called then there is no issue.
In the function padata_reorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away.
Fix this by getting the next padata before the squeue->serial lock is released.
In order to make this possible, simplify padata_reorder by only calling it once the next padata arrives.(CVE-2025-38584)
In the Linux kernel, the following vulnerability has been resolved:
fs: Prevent file descriptor table allocations exceeding INT_MAX
When sysctl_nr_open is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c:
WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288
This happens because kvmalloc_array() and kvmalloc() check if the requested size exceeds INT_MAX and emit a warning when the allocation is not flagged with __GFP_NOWARN.
Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)
Reproducer: 1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open
- Run a program that uses a high file descriptor: #include <unistd.h> #include <sys/resource.h>
int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }
- Observe WARNING in dmesg at mm/slub.c:5027
systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that:
- The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting
- Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations
- The resulting allocations (>8GB) are impractical and will always fail
systemd's algorithm starts with INT_MAX and keeps halving the value until the kernel accepts it. On most systems, this results in nr_open being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors.
While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue.
Fix this by adding a check in alloc_fdtable() to ensure the requested allocation size does not exceed INT_MAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request.(CVE-2025-39756)
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.
On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.
Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)
In the Linux kernel, the following vulnerability has been resolved:
ACPI: video: Fix use-after-free in acpi_video_switch_brightness()
The switch_brightness_work delayed work accesses device->brightness and device->backlight, freed by acpi_video_dev_unregister_backlight() during device removal.
If the work executes after acpi_video_bus_unregister_backlight() frees these resources, it causes a use-after-free when acpi_video_switch_brightness() dereferences device->brightness or device->backlight.
Fix this by calling cancel_delayed_work_sync() for each device's switch_brightness_work in acpi_video_bus_remove_notify_handler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed.
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"perf-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-296.0.0.198.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-296.0.0.198.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"perf-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-296.0.0.198.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-296.0.0.198.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-296.0.0.198.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\niommu/arm-smmu-v3-sva: Fix mm use-after-free\n\nWe currently call arm64_mm_context_put() without holding a reference to\nthe mm, which can result in use-after-free. Call mmgrab()/mmdrop() to\nensure the mm only gets freed after we unpinned the ASID.(CVE-2022-49426)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7915: fix memory leak in mt7915_mcu_exit\n\nAlways purge mcu skb queues in mt7915_mcu_exit routine even if\nmt7915_firmware_state fails.(CVE-2023-53466)\n\nprinter_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact.(CVE-2024-25741)\n\nIn the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ( net: Use nested-BH locking fornapi_alloc_cache. ) was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it s running in NAPI contexteven when it s not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.(CVE-2024-43835)\n\nIn the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk-\u0026gt;sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk-\u0026gt;sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk-\u0026gt;sk_user_data could be NULL.Let s use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 \u0026lt;0f\u0026gt; b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: \u0026lt;IRQ\u0026gt; ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)\u0026lt;/IRQ\u0026gt; do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 \u0026lt;fa\u0026gt; c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---(CVE-2024-46763)\n\nIn the Linux kernel, the following vulnerability has been resolved:f2fs: Require FMODE_WRITE for atomic write ioctlsThe F2FS ioctls for starting and committing atomic writes check forinode_owner_or_capable(), but this does not give LSMs like SELinux orLandlock an opportunity to deny the write access - if the caller s FSUIDmatches the inode s UID, inode_owner_or_capable() immediately returns true.There are scenarios where LSMs want to deny a process the ability to writeparticular files, even files that the FSUID of the process owns; but thiscan currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a fileFix it by requiring FMODE_WRITE for these operations, just like forF2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using theseioctls when intending to write into the file, that seems unlikely to breakanything.(CVE-2024-47740)\n\nIn the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ( nfs: add support for large folios )).(CVE-2024-53138)\n\nIn the Linux kernel, the following vulnerability has been resolved:x86/xen: don t do PV iret hypercall through hypercall pageInstead of jumping to the Xen hypercall page for doing the irethypercall, directly code the required sequence in xen-asm.S.This is done in preparation of no longer using hypercall page at all,as it has shown to cause problems with speculation mitigations.This is part of XSA-466 / CVE-2024-53241.(CVE-2024-53241)\n\nIn the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr-\u0026gt;if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp-\u0026gt;ndev-\u0026gt;stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi s weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi-\u0026gt;state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi s weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).(CVE-2025-21806)\n\nIn the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port-\u0026gt;sysrq) uart_port_lock(port) uart_handle_break() port-\u0026gt;sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port-\u0026gt;sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port-\u0026gt;sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.(CVE-2025-21820)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kmemleak warning for percpu hashmap\n\nVlad Poenaru reported the following kmemleak issue:\n\n unreferenced object 0x606fd7c44ac8 (size 32):\n backtrace (crc 0):\n pcpu_alloc_noprof+0x730/0xeb0\n bpf_map_alloc_percpu+0x69/0xc0\n prealloc_init+0x9d/0x1b0\n htab_map_alloc+0x363/0x510\n map_create+0x215/0x3a0\n __sys_bpf+0x16b/0x3e0\n __x64_sys_bpf+0x18/0x20\n do_syscall_64+0x7b/0x150\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFurther investigation shows the reason is due to not 8-byte aligned\nstore of percpu pointer in htab_elem_set_ptr():\n *(void __percpu **)(l-\u0026gt;key + key_size) = pptr;\n\nNote that the whole htab_elem alignment is 8 (for x86_64). If the key_size\nis 4, that means pptr is stored in a location which is 4 byte aligned but\nnot 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based\non 8 byte stride, so it won\u0026apos;t detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n htab-\u0026gt;elem_size = sizeof(struct htab_elem) +\n round_up(htab-\u0026gt;map.key_size, 8);\n if (percpu)\n htab-\u0026gt;elem_size += sizeof(void *);\n else\n htab-\u0026gt;elem_size += round_up(htab-\u0026gt;map.value_size, 8);\n\nSo storing pptr with 8-byte alignment won\u0026apos;t cause any problem and can fix\nkmemleak too.\n\nThe issue can be reproduced with bpf selftest as well:\n 1. Enable CONFIG_DEBUG_KMEMLEAK config\n 2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.\n The purpose is to keep map available so kmemleak can be detected.\n 3. run \u0026apos;./test_progs -t for_each/hash_map \u0026amp;\u0026apos; and a kmemleak should be reported.(CVE-2025-37807)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix Preauh_HashValue race condition\n\nIf client send multiple session setup requests to ksmbd,\nPreauh_HashValue race condition could happen.\nThere is no need to free sess-\u0026gt;Preauh_HashValue at session setup phase.\nIt can be freed together with session at connection termination phase.(CVE-2025-38561)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npadata: Fix pd UAF once and for all\n\nThere is a race condition/UAF in padata_reorder that goes back\nto the initial commit. A reference count is taken at the start\nof the process in padata_do_parallel, and released at the end in\npadata_serial_worker.\n\nThis reference count is (and only is) required for padata_replace\nto function correctly. If padata_replace is never called then\nthere is no issue.\n\nIn the function padata_reorder which serves as the core of padata,\nas soon as padata is added to queue-\u0026gt;serial.list, and the associated\nspin lock released, that padata may be processed and the reference\ncount on pd would go away.\n\nFix this by getting the next padata before the squeue-\u0026gt;serial lock\nis released.\n\nIn order to make this possible, simplify padata_reorder by only\ncalling it once the next padata arrives.(CVE-2025-38584)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: Prevent file descriptor table allocations exceeding INT_MAX\n\nWhen sysctl_nr_open is set to a very high value (for example, 1073741816\nas set by systemd), processes attempting to use file descriptors near\nthe limit can trigger massive memory allocation attempts that exceed\nINT_MAX, resulting in a WARNING in mm/slub.c:\n\n WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288\n\nThis happens because kvmalloc_array() and kvmalloc() check if the\nrequested size exceeds INT_MAX and emit a warning when the allocation is\nnot flagged with __GFP_NOWARN.\n\nSpecifically, when nr_open is set to 1073741816 (0x3ffffff8) and a\nprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:\n- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes\n- Multiple bitmaps: ~400MB\n- Total allocation size: \u0026gt; 8GB (exceeding INT_MAX = 2,147,483,647)\n\nReproducer:\n1. Set /proc/sys/fs/nr_open to 1073741816:\n # echo 1073741816 \u0026gt; /proc/sys/fs/nr_open\n\n2. Run a program that uses a high file descriptor:\n #include \u0026lt;unistd.h\u0026gt;\n #include \u0026lt;sys/resource.h\u0026gt;\n\n int main() {\n struct rlimit rlim = {1073741824, 1073741824};\n setrlimit(RLIMIT_NOFILE, \u0026amp;rlim);\n dup2(2, 1073741880); // Triggers the warning\n return 0;\n }\n\n3. Observe WARNING in dmesg at mm/slub.c:5027\n\nsystemd commit a8b627a introduced automatic bumping of fs.nr_open to the\nmaximum possible value. The rationale was that systems with memory\ncontrol groups (memcg) no longer need separate file descriptor limits\nsince memory is properly accounted. However, this change overlooked\nthat:\n\n1. The kernel\u0026apos;s allocation functions still enforce INT_MAX as a maximum\n size regardless of memcg accounting\n2. Programs and tests that legitimately test file descriptor limits can\n inadvertently trigger massive allocations\n3. The resulting allocations (\u0026gt;8GB) are impractical and will always fail\n\nsystemd\u0026apos;s algorithm starts with INT_MAX and keeps halving the value\nuntil the kernel accepts it. On most systems, this results in nr_open\nbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of file\ndescriptors.\n\nWhile processes rarely use file descriptors near this limit in normal\noperation, certain selftests (like\ntools/testing/selftests/core/unshare_test.c) and programs that test file\ndescriptor limits can trigger this issue.\n\nFix this by adding a check in alloc_fdtable() to ensure the requested\nallocation size does not exceed INT_MAX. This causes the operation to\nfail with -EMFILE instead of triggering a kernel warning and avoids the\nimpractical \u0026gt;8GB memory allocation request.(CVE-2025-39756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPI: video: Fix use-after-free in acpi_video_switch_brightness()\n\nThe switch_brightness_work delayed work accesses device-\u0026gt;brightness\nand device-\u0026gt;backlight, freed by acpi_video_dev_unregister_backlight()\nduring device removal.\n\nIf the work executes after acpi_video_bus_unregister_backlight()\nfrees these resources, it causes a use-after-free when\nacpi_video_switch_brightness() dereferences device-\u0026gt;brightness or\ndevice-\u0026gt;backlight.\n\nFix this by calling cancel_delayed_work_sync() for each device\u0026apos;s\nswitch_brightness_work in acpi_video_bus_remove_notify_handler()\nafter removing the notify handler that queues the work. This ensures\nthe work completes before the memory is freed.\n\n[ rjw: Changelog edit ](CVE-2025-40211)",
"id": "OESA-2025-2886",
"modified": "2026-08-06T11:10:01Z",
"published": "2025-12-30T11:10:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49426"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53466"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43835"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46763"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47740"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21806"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21820"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37807"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38561"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38584"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40211"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49426",
"CVE-2023-53466",
"CVE-2024-25741",
"CVE-2024-43835",
"CVE-2024-46763",
"CVE-2024-47740",
"CVE-2024-53138",
"CVE-2024-53241",
"CVE-2025-21744",
"CVE-2025-21806",
"CVE-2025-21820",
"CVE-2025-37807",
"CVE-2025-38561",
"CVE-2025-38584",
"CVE-2025-39756",
"CVE-2025-39901",
"CVE-2025-40211"
]
}
OPENSUSE-SU-2025:20081-1
Vulnerability from csaf_opensuse - Published: 2025-11-25 07:35 - Updated: 2026-11-01 10:39Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.