Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-39752 (GCVE-0-2025-39752)
Vulnerability from cvelistv5 – Published: 2025-09-11 16:52 – Updated: 2026-05-12 12:06| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
3ee851e212d0bb6be8c462059fba74ce2e3f6064 , < 3c6bf7a324b8995b9c7d790c8d2abf0668f51551
(git)
Affected: 3ee851e212d0bb6be8c462059fba74ce2e3f6064 , < 888a453c2a239765a7ab4de8a3cedae2e3802528 (git) Affected: 3ee851e212d0bb6be8c462059fba74ce2e3f6064 , < c0726d1e466e2d0da620836e293a59e6427ccdff (git) Affected: 3ee851e212d0bb6be8c462059fba74ce2e3f6064 , < 265583266d93db4ff83d088819b1f63fdf0131db (git) Affected: 3ee851e212d0bb6be8c462059fba74ce2e3f6064 , < d7d6d076ee9532c4668f14696a35688d35dd16f4 (git) Affected: 3ee851e212d0bb6be8c462059fba74ce2e3f6064 , < 0223a3683d502b7e5eb2eb4ad7e97363fa88d531 (git) Affected: 3ee851e212d0bb6be8c462059fba74ce2e3f6064 , < 47769dab9073a73e127aa0bfd0ba4c51eaccdc33 (git) Affected: 3ee851e212d0bb6be8c462059fba74ce2e3f6064 , < 1eb67589a7e091b1e5108aab72fddbf4dc69af2c (git) Affected: 3ee851e212d0bb6be8c462059fba74ce2e3f6064 , < 7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814 (git) |
guessed | |
| Linux | Linux |
Affected:
3.19
Unaffected: 0 , < 3.19 (semver) Unaffected: 5.4.297 , ≤ 5.4.* (semver) Unaffected: 5.10.241 , ≤ 5.10.* (semver) Unaffected: 5.15.190 , ≤ 5.15.* (semver) Unaffected: 6.1.149 , ≤ 6.1.* (semver) Unaffected: 6.6.103 , ≤ 6.6.* (semver) Unaffected: 6.12.43 , ≤ 6.12.* (semver) Unaffected: 6.15.11 , ≤ 6.15.* (semver) Unaffected: 6.16.2 , ≤ 6.16.* (semver) Unaffected: 6.17 , ≤ * (original_commit_for_fix) |
guessed | |
| Siemens | SIMATIC CN 4100 |
Affected:
0 , < V5.0
(custom)
|
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T17:43:03.272Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
}
],
"title": "CVE Program Container"
},
{
"affected": [
{
"defaultStatus": "unknown",
"product": "SIMATIC CN 4100",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V5.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-12T12:06:45.444Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
}
],
"x_adpType": "supplier"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm/mach-rockchip/platsmp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3c6bf7a324b8995b9c7d790c8d2abf0668f51551",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "888a453c2a239765a7ab4de8a3cedae2e3802528",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "c0726d1e466e2d0da620836e293a59e6427ccdff",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "265583266d93db4ff83d088819b1f63fdf0131db",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "d7d6d076ee9532c4668f14696a35688d35dd16f4",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "0223a3683d502b7e5eb2eb4ad7e97363fa88d531",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "47769dab9073a73e127aa0bfd0ba4c51eaccdc33",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "1eb67589a7e091b1e5108aab72fddbf4dc69af2c",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm/mach-rockchip/platsmp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.19"
},
{
"lessThan": "3.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.297",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.241",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.190",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.149",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.103",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.43",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.2",
"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.4.297",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.241",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.190",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.149",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.103",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.43",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15.11",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.2",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"versionStartIncluding": "3.19",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0027t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4"
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:35:34.447Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/3c6bf7a324b8995b9c7d790c8d2abf0668f51551"
},
{
"url": "https://git.kernel.org/stable/c/888a453c2a239765a7ab4de8a3cedae2e3802528"
},
{
"url": "https://git.kernel.org/stable/c/c0726d1e466e2d0da620836e293a59e6427ccdff"
},
{
"url": "https://git.kernel.org/stable/c/265583266d93db4ff83d088819b1f63fdf0131db"
},
{
"url": "https://git.kernel.org/stable/c/d7d6d076ee9532c4668f14696a35688d35dd16f4"
},
{
"url": "https://git.kernel.org/stable/c/0223a3683d502b7e5eb2eb4ad7e97363fa88d531"
},
{
"url": "https://git.kernel.org/stable/c/47769dab9073a73e127aa0bfd0ba4c51eaccdc33"
},
{
"url": "https://git.kernel.org/stable/c/1eb67589a7e091b1e5108aab72fddbf4dc69af2c"
},
{
"url": "https://git.kernel.org/stable/c/7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814"
}
],
"title": "ARM: rockchip: fix kernel hang during smp initialization",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39752",
"datePublished": "2025-09-11T16:52:23.372Z",
"dateReserved": "2025-04-16T07:20:57.125Z",
"dateUpdated": "2026-05-12T12:06:45.444Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-39752",
"date": "2026-09-17",
"epss": "0.0017",
"percentile": "0.06766"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2025-39752\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-09-11T17:15:38.900\",\"lastModified\":\"2026-06-17T09:18:24.537\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nARM: rockchip: fix kernel hang during smp initialization\\n\\nIn order to bring up secondary CPUs main CPU write trampoline\\ncode to SRAM. The trampoline code is written while secondary\\nCPUs are powered on (at least that true for RK3188 CPU).\\nSometimes that leads to kernel hang. Probably because secondary\\nCPU execute trampoline code while kernel doesn\u0027t expect.\\n\\nThe patch moves SRAM initialization step to the point where all\\nsecondary CPUs are powered down.\\n\\nThat fixes rarely hangs on RK3188:\\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"arch/arm/mach-rockchip/platsmp.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"3ee851e212d0bb6be8c462059fba74ce2e3f6064\",\"lessThan\":\"3c6bf7a324b8995b9c7d790c8d2abf0668f51551\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3ee851e212d0bb6be8c462059fba74ce2e3f6064\",\"lessThan\":\"888a453c2a239765a7ab4de8a3cedae2e3802528\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3ee851e212d0bb6be8c462059fba74ce2e3f6064\",\"lessThan\":\"c0726d1e466e2d0da620836e293a59e6427ccdff\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3ee851e212d0bb6be8c462059fba74ce2e3f6064\",\"lessThan\":\"265583266d93db4ff83d088819b1f63fdf0131db\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3ee851e212d0bb6be8c462059fba74ce2e3f6064\",\"lessThan\":\"d7d6d076ee9532c4668f14696a35688d35dd16f4\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3ee851e212d0bb6be8c462059fba74ce2e3f6064\",\"lessThan\":\"0223a3683d502b7e5eb2eb4ad7e97363fa88d531\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3ee851e212d0bb6be8c462059fba74ce2e3f6064\",\"lessThan\":\"47769dab9073a73e127aa0bfd0ba4c51eaccdc33\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3ee851e212d0bb6be8c462059fba74ce2e3f6064\",\"lessThan\":\"1eb67589a7e091b1e5108aab72fddbf4dc69af2c\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"3ee851e212d0bb6be8c462059fba74ce2e3f6064\",\"lessThan\":\"7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"arch/arm/mach-rockchip/platsmp.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"3.19\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"3.19\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.4.297\",\"lessThanOrEqual\":\"5.4.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.10.241\",\"lessThanOrEqual\":\"5.10.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.190\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.149\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.103\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.43\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.15.11\",\"lessThanOrEqual\":\"6.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.16.2\",\"lessThanOrEqual\":\"6.16.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.17\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]},{\"source\":\"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e\",\"affectedData\":[{\"vendor\":\"Siemens\",\"product\":\"SIMATIC CN 4100\",\"defaultStatus\":\"unknown\",\"versions\":[{\"version\":\"0\",\"lessThan\":\"V5.0\",\"versionType\":\"custom\",\"status\":\"affected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H\",\"baseScore\":5.5,\"baseSeverity\":\"MEDIUM\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"NONE\",\"integrityImpact\":\"NONE\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":3.6}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"NVD-CWE-noinfo\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"3.19\",\"versionEndExcluding\":\"5.4.297\",\"matchCriteriaId\":\"26EE76A2-8203-4511-8272-15BCB88FA40C\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.5\",\"versionEndExcluding\":\"5.10.241\",\"matchCriteriaId\":\"D0D21C35-EB8A-488A-BBF9-403E4817E5DD\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.15.190\",\"matchCriteriaId\":\"AD9E597F-3DDE-4D7E-976C-463D0611F13F\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.149\",\"matchCriteriaId\":\"FDBE8280-8983-4D2D-943D-2E6D0104E2D8\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.103\",\"matchCriteriaId\":\"F2293654-7169-49B5-8D0D-EE51EF8B8E48\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.12.43\",\"matchCriteriaId\":\"472C5F87-2BF3-4FAB-9B21-DA7513977363\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.13\",\"versionEndExcluding\":\"6.15.11\",\"matchCriteriaId\":\"BC242347-F722-43AE-B910-BE0B22386977\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.16\",\"versionEndExcluding\":\"6.16.2\",\"matchCriteriaId\":\"BD7C087D-2415-4521-B624-30003352F899\"}]}]},{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"FA6FEEC2-9F11-4643-8827-749718254FED\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/0223a3683d502b7e5eb2eb4ad7e97363fa88d531\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/1eb67589a7e091b1e5108aab72fddbf4dc69af2c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/265583266d93db4ff83d088819b1f63fdf0131db\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/3c6bf7a324b8995b9c7d790c8d2abf0668f51551\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/47769dab9073a73e127aa0bfd0ba4c51eaccdc33\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/888a453c2a239765a7ab4de8a3cedae2e3802528\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/c0726d1e466e2d0da620836e293a59e6427ccdff\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/d7d6d076ee9532c4668f14696a35688d35dd16f4\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Mailing List\",\"Third Party Advisory\"]},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Mailing List\",\"Third Party Advisory\"]},{\"url\":\"https://cert-portal.siemens.com/productcert/html/ssa-032379.html\",\"source\":\"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e\"}]}}",
"redhat_vex": {
"aggregate_severity": "Low",
"current_release_date": "2026-06-30T10:19:10+00:00",
"cve": "CVE-2025-39752",
"id": "CVE-2025-39752",
"initial_release_date": "2025-09-11T00:00:00+00:00",
"product_status:known_affected": "232",
"product_status:known_not_affected": "42",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: ARM: rockchip: fix kernel hang during smp initialization",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-39752.json",
"version": "3"
}
}
}
CERTFR-2026-AVI-0565
Vulnerability from certfr_avis - Published: 2026-05-12 - Updated: 2026-05-12
De multiples vulnérabilités ont été découvertes dans les produits Siemens. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Siemens | N/A | SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE XR524-8C, 2x230V (6GK5524-8GS00-4AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W778-1 M12 (6GK5778-1GY00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AA6) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XR552-12M (2HR2) (6GK5552-0AA00-2HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W788-1 M12 (6GK5788-1GD00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SCALANCE XR524-8C, 1x230V (L3 int.) (6GK5524-8GR00-3AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X208PRO (6GK5208-0HA10-2AA6) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SIMATIC S7-300 CPU 319F-3 PN/DP (6ES7318-3FL01-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AC0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC S7-300 CPU 317F-2 PN/DP (6ES7317-2FK14-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC HMI MTP1000 Unified Comfort Panel (6AV2128-3KB06-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE X224 (6GK5224-0BA00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3XB27-0BX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE SC646-2C (6GK5646-2GS00-2AC2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-4M PoE TS (24V, ports on front) (6GK5324-4QG10-1CR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200S IM 151-8F PN/DP CPU (6ES7151-8FB01-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE X310 (6GK5310-0FA00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE WAB762-1 (6GK5762-1AJ00-6AA0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE WAM763-1 (US) (6GK5763-1AL00-7DB0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (24V, ports on rear) (6GK5324-4GG10-1JR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W1788-2 EEC M12 (6GK5788-2GY01-0TA0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear) (6GK5324-4GG00-3JR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V2 CPUs toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SCALANCE XM408-4C (6GK5408-4GP00-2AM2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X302-7 EEC (2x 24V) (6GK5302-7GD00-2EA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE MUM856-1 (B1) (6GK5856-2EA10-3BA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIMATIC S7-300 CPU 319-3 PN/DP (6ES7318-3EL01-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3QB57-0BX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE X307-2 EEC (24V) (6GK5307-2FD00-1EA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W734-1 RJ45 (6GK5734-1FX00-0AA6) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE W722-1 RJ45 (6GK5722-1FC00-0AC0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE X308-2 (6GK5308-2FL00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR526-8C, 1x230V (6GK5526-8GS00-3AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3XB57-0BX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP700 Unified Comfort Panel (6AV2128-3GB06-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear) (6GK5324-4GG10-3JR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-12M (24V, ports on rear) (6GK5324-0GG10-1HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR528-6M (6GK5528-0AA00-2AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP Open Controller CPU 1515SP PC3 V4 CPUs toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3QB27-1BX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Unified Comfort Panel (6AV2128-3QB06-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE M874-2 (6GK5874-2AA00-2AA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SIMATIC CFU PA (6ES7655-5PX11-0XX0) versions antérieures à 2.0.0 | ||
| Siemens | N/A | SCALANCE X307-2 EEC (230V) (6GK5307-2FD00-3EA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W734-1 RJ45 (6GK5734-1FX00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XR526-8C, 24V (6GK5526-8GS00-2AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W786-2 SFP (6GK5786-2FE00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE MUM856-1 (A1) (6GK5856-2EA10-3AA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Unified Comfort Panel neutral design (6AV2128-3QB36-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC CFU PA (6ES7655-5PX11-1XX0) versions antérieures à 2.0.0 | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Unified Comfort Panel hygienic (6AV2128-3QB40-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE W734-1 RJ45 (USA) (6GK5734-1FX00-0AB6) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE X212-2 (6GK5212-2BB00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIPROTEC 5 versions supérieures ou égales à7.80 pour la vulnérabilité CVE-2024-54017 | ||
| Siemens | N/A | SCALANCE W788-2 M12 (6GK5788-2GD00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XF204-2 (6GK5204-2BC00-2AF2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-12M TS (24V) (6GK5324-0GG00-1CR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7-400 CPU 416F-3 PN/DP V7 (6ES7416-3FS07-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR528-6M (2HR2, L3 int.) (6GK5528-0AR00-2HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7-300 CPU 317T-3 PN/DP (6ES7317-7TK10-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE X302-7 EEC (230V, coated) (6GK5302-7GD00-3GA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W1788-2IA M12 (6GK5788-2HY01-0AA0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE XR324-4M PoE (230V, ports on rear) (6GK5324-4QG10-3HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X310FE (6GK5310-0BA00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIPLUS S7-300 CPU 315F-2 PN/DP (6AG1315-2FJ14-2AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Unified Comfort Panel hygienic neutral design (6AV2128-3QB70-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3MB57-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC ET 200pro IM 154-8F PN/DP CPU (6ES7154-8FB01-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR324-4M PoE (24V, ports on rear) (6GK5324-4QG10-1HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1514SPT-2 PN (6ES7514-2VN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIMATIC HMI MTP1000 Unified Comfort Panel hygienic neutral design (6AV2128-3KB70-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3UB27-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE W721-1 RJ45 (6GK5721-1FC00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3XB27-1BX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC S7 PLCs Web Server versions antérieures à 2.9.9 | ||
| Siemens | N/A | SCALANCE XR324-12M (230V, ports on front) (6GK5324-0GG10-3AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-12M (230V, ports on front) (6GK5324-0GG00-3AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X204-2LD (6GK5204-2BC10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE XR552-12M (2HR2) (6GK5552-0AR00-2HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XF204 (6GK5204-0BA00-2AF2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X308-2M (6GK5308-2GG10-2AA2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7-1500 CPU 1516-3 PN/DP (6ES7516-3AN00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3UB57-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (2x 24V, ports on rear) (6GK5324-4GG10-2JR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W788-1 RJ45 (6GK5788-1FC00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE W778-1 M12 EEC (USA) (6GK5778-1GY00-0TB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC S7-1500 CPU 1516F-3 PN/DP (6ES7516-3FN00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC S7-300 CPU 315F-2 PN/DP (6ES7315-2FJ14-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR552-12M (2HR2, L3 int.) (6GK5552-0AR00-2AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W788-2 RJ45 (6GK5788-2FC00-0AC0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1514SP-2 PN (6ES7514-2DN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIPROTEC 5 versions supérieures ou égales à7.80 et versions antérieures à 11.0 | ||
| Siemens | N/A | SCALANCE MUM853-1 (A1) (6GK5853-2EA10-2AA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE XR524-8C, 2x230V (L3 int.) (6GK5524-8GR00-4AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X307-3 (6GK5307-3BL10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Unified Comfort Panel (6AV2128-3UB06-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE WAM766-1 (6GK5766-1GE00-7DA0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SIMATIC CN 4100 versions antérieures à 5.0 | ||
| Siemens | N/A | SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) versions antérieures à 8.3 | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3QB57-1BX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC S7-400 CPU 414-3 PN/DP V7 (6ES7414-3EM07-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE M874-3 3G-Router (CN) (6GK5874-3AA00-2FA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE MUB852-1 (A1) (6GK5852-1EA10-1AA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE X308-2M (6GK5308-2GG00-2AA2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Unified Comfort Panel (6AV2128-3XB06-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front) (6GK5324-4GG00-4ER2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE MUB852-1 (B1) (6GK5852-1EA10-1BA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE X204-2 (6GK5204-2BB10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X212-2LD (6GK5212-2BC00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE WAM766-1 EEC (ME) (6GK5766-1GE00-7TC0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3QB27-0BX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE W786-2 RJ45 (6GK5786-2FC00-0AC0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3XB57-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK01-0AB0) versions antérieures à 2.9.9 | ||
| Siemens | N/A | SCALANCE XR552-12M (6GK5552-0AA00-2AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR526-8C, 24V (L3 int.) (6GK5526-8GR00-2AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Unified Comfort Panel neutral design (6AV2128-3XB36-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Unified Comfort Panel hygienic (6AV2128-3UB40-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC S7-300 CPU 315T-3 PN/DP (6ES7315-7TJ10-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3QB57-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE W721-1 RJ45 (6GK5721-1FC00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC ET 200pro IM 154-8FX PN/DP CPU (6ES7154-8FX00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE W786-1 RJ45 (6GK5786-1FC00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE WUM766-1 (ME) (6GK5766-1GE00-3DC0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE W786-2IA RJ45 (6GK5786-2HC00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR524-8C, 24V (L3 int.) (6GK5524-8GR00-2AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK01-0AB0) versions antérieures à 2.9.9 | ||
| Siemens | N/A | SIMATIC HMI MTP1000, Unified Comfort Panel neutral (6AV2128-3KB36-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE M876-4 (6GK5876-4AA10-2BA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE XR324-4M PoE TS (24V, ports on front) (6GK5324-4QG00-1CR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE WUM763-1 (6GK5763-1AL00-3AA0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SIMATIC S7-400 H V6 CPU family (incl. SIPLUS variants) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE X308-2LH (6GK5308-2FN10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W774-1 M12 EEC (6GK5774-1FY00-0TA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE WUM766-1 (6GK5766-1GE00-3DA0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Unified Comfort Panel hygienic neutral design (6AV2128-3UB70-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC S7 PLCs Web Server versions antérieures à 3.1.6 | ||
| Siemens | N/A | SCALANCE W738-1 M12 (6GK5738-1GY00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE X307-2 EEC (2x 230V) (6GK5307-2FD00-4EA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X307-2 EEC (24V, coated) (6GK5307-2FD00-1GA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SM03-0AB0) toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SCALANCE X307-3 (6GK5307-3BL00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7-1500 CPU 1513-1 PN (6ES7513-1AL00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ01-0AB0) versions antérieures à 2.9.9 | ||
| Siemens | N/A | SCALANCE XR324-12M (230V, ports on rear) (6GK5324-0GG10-3HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W748-1 RJ45 (6GK5748-1FC00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE X308-2M TS (6GK5308-2GG00-2CA2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W788-2 M12 (6GK5788-2GD00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE W788-2 M12 EEC (6GK5788-2GD00-0TB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE X204-2FM (6GK5204-2BB11-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIPLUS S7-300 CPU 317-2 PN/DP (6AG1317-2EK14-7AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC ET 200SP Open Controller CPU 1515SP PC (incl. SIPLUS variants) toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SCALANCE X304-2FE (6GK5304-2BD00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7-400 CPU 414F-3 PN/DP V7 (6ES7414-3FM07-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC S7-300 CPU 314C-2 PN/DP (6ES7314-6EH04-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE X308-2LH (6GK5308-2FN00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE MUM853-1 (B1) (6GK5853-2EA10-2BA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (24V, ports on rear) (6GK5324-4GG00-1JR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (2x 24V, ports on rear) (6GK5324-4GG00-2JR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7 PLCs Web Server toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIMATIC ET 200pro IM 154-8 PN/DP CPU (6ES7154-8AB01-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Unified Comfort Panel hygienic neutral design (6AV2128-3MB70-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE WAM763-1 (ME) (6GK5763-1AL00-7DC0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE X208 (6GK5208-0BA10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X302-7 EEC (2x 230V, coated) (6GK5302-7GD00-4GA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XM416-4C (6GK5416-4GS00-2AM2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE WUB762-1 (6GK5762-1AJ00-1AA0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE X302-7 EEC (24V, coated) (6GK5302-7GD00-1GA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X302-7 EEC (2x 24V, coated) (6GK5302-7GD00-2GA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W761-1 RJ45 (6GK5761-1FC00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE X308-2M TS (6GK5308-2GG10-2CA2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR528-6M (2HR2) (6GK5528-0AA00-2HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X206-1 (6GK5206-1BB10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3MB27-0BX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE M876-3 (6GK5876-3AA02-2BA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE XM416-4C (L3 int.) (6GK5416-4GR00-2AM2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X308-2LH+ (6GK5308-2FP10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W748-1 M12 (6GK5748-1GD00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC HMI MTP1500 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3QB27-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC S7-410 V8 CPU family (incl. SIPLUS variants) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE W774-1 RJ45 (USA) (6GK5774-1FX00-0AB6) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC Drive Controller CPU 1504D TF (6ES7615-4DF10-0AB0) versions antérieures à 3.1.6 | ||
| Siemens | N/A | SCALANCE X302-7 EEC (230V) (6GK5302-7GD00-3EA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Unified Comfort Hygienic neutral design (6AV2128-3XB70-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE X320-1-2LD FE (6GK5320-3BF00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE SC626-2C (6GK5626-2GS00-2AC2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W788-1 RJ45 (6GK5788-1FC00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Unified Comfort Panel neutral design (6AV2128-3UB36-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB40-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE X310 (6GK5310-0FA10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X307-2 EEC (2x 24V) (6GK5307-2FD00-2EA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (2x 24V, ports on front) (6GK5324-4GG00-2ER2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7-300 CPU 317-2 PN/DP (6ES7317-2EK14-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB70-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE W786-2 RJ45 (6GK5786-2FC00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SCALANCE X307-2 EEC (230V, coated) (6GK5307-2FD00-3GA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3UB27-1BX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE W786-2 RJ45 (6GK5786-2FC00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XR526-8C, 1x230V (L3 int.) (6GK5526-8GR00-3AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE WAM763-1 (6GK5763-1AL00-7DA0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE X408-2 (6GK5408-2FD00-2AA2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIPROTEC 5 versions antérieures à 11.0 | ||
| Siemens | N/A | SCALANCE X308-2LD (6GK5308-2FM00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-12M (24V, ports on front) (6GK5324-0GG10-1AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE WUB762-1 iFeatures (6GK5762-1AJ00-2AA0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE XR528-6M (L3 int.) (6GK5528-0AR00-2AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X310FE (6GK5310-0BA10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3MB27-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP700, Unified Comfort Panel neutral design (6AV2128-3GB36-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (2x 24V, ports on front) (6GK5324-4GG10-2ER2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W748-1 RJ45 (6GK5748-1FC00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XM408-8C (L3 int.) (6GK5408-8GR00-2AM2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front) (6GK5324-4GG10-3ER2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7 PLCs Web Server toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIMATIC S7-400 CPU 412-2 PN V7 (6ES7412-2EK07-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE W786-2IA RJ45 (6GK5786-2HC00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC S7-1500 CPU 1511F-1 PN (6ES7511-1FK00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE X308-2LD (6GK5308-2FM10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X306-1LD FE (6GK5306-1BF00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-4M PoE (24V, ports on front) (6GK5324-4QG10-1AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W778-1 M12 EEC (6GK5778-1GY00-0TA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIPLUS S7-400 CPU 416-3 PN/DP V7 (6AG1416-3ES07-7AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SK03-0AB0) toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIPLUS S7-300 CPU 315-2 PN/DP (6AG1315-2EH14-7AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3MB57-0BX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SIPLUS S7-300 CPU 314C-2 PN/DP (6AG1314-6EH04-7AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE M874-3 (6GK5874-3AA00-2AA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE XR324-12M TS (24V) (6GK5324-0GG10-1CR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE W774-1 M12 EEC (6GK5774-1FY00-0TB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE MUM856-1 (CN) (6GK5856-2EA00-3FA1) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE W738-1 M12 (6GK5738-1GY00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XR324-4M PoE (230V, ports on rear) (6GK5324-4QG00-3HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE WAM766-1 (ME) (6GK5766-1GE00-7DC0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SIMATIC ET 200SP HA IM155-6 PN versions antérieures à 1.3 | ||
| Siemens | N/A | SCALANCE SC642-2C (6GK5642-2GS00-2AC2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W788-2 M12 EEC (6GK5788-2GD00-0TC0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE W788-1 M12 (6GK5788-1GD00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear) (6GK5324-4GG10-4JR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X308-2 RD (inkl. SIPLUS variants) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X307-3LD (6GK5307-3BM10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3XB27-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE XR324-4M PoE (230V, ports on front) (6GK5324-4QG00-3AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3XB57-1BX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE X302-7 EEC (2x 230V) (6GK5302-7GD00-4EA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W786-1 RJ45 (6GK5786-1FC00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC S7-410 V10 CPU family (incl. SIPLUS variants) versions antérieures à 10.2 | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3UB57-1BX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIPLUS S7-300 CPU 317F-2 PN/DP (6AG1317-2FK14-2AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE WUM763-1 (US) (6GK5763-1AL00-3AB0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE XF206-1 (6GK5206-1BC00-2AF2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SCALANCE X308-2M PoE (6GK5308-2QG10-2AA2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC Drive Controller CPU 1507D TF (6ES7615-7DF10-0AB0) versions antérieures à 3.1.6 | ||
| Siemens | N/A | SCALANCE XR524-8C, 1x230V (6GK5524-8GS00-3AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE SC632-2C (6GK5632-2GS00-2AC2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7-1500 CPU 1515-2 PN (6ES7515-2AM00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR526-8C, 2x230V (6GK5526-8GS00-4AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X307-3LD (6GK5307-3BM00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X308-2M PoE (6GK5308-2QG00-2AA2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XM408-4C (L3 int.) (6GK5408-4GQ00-2AM2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7-300 CPU 317TF-3 PN/DP (6ES7317-7UL10-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR324-4M PoE (24V, ports on front) (6GK5324-4QG00-1AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC HMI MTP2200 Unified Comfort Hygienic (6AV2128-3XB40-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC ET 200S IM 151-8 PN/DP CPU (6ES7151-8AB01-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE X320-1 FE (6GK5320-1BD00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X216 (6GK5216-0BA00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1514SP F-2 PN (6ES7514-2SN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIMATIC S7-300 CPU 315-2 PN/DP (6ES7315-2EH14-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front) (6GK5324-4GG10-4ER2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC CFU DIQ (6ES7655-5PX31-1XX0) versions antérieures à 2.0.0 | ||
| Siemens | N/A | SCALANCE W722-1 RJ45 (6GK5722-1FC00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear) (6GK5324-4GG00-4JR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W1748-1 M12 (6GK5748-1GY01-0TA0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Unified Comfort Panel (6AV2128-3MB06-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front) (6GK5324-4GG00-3ER2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Unified Comfort Panel hygienic (6AV2128-3MB40-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE SC636-2C (6GK5636-2GS00-2AC2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ01-0AB0) versions antérieures à 2.9.9 | ||
| Siemens | N/A | SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (24V, ports on front) (6GK5324-4GG10-1ER2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIPLUS S7-400 CPU 414-3 PN/DP V7 (6AG1414-3EM07-7AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE W734-1 RJ45 (6GK5734-1FX00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE W788-2 RJ45 (6GK5788-2FC00-0AB0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XR324-4M PoE (24V, ports on rear) (6GK5324-4QG00-1HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W788-2 M12 EEC (6GK5788-2GD00-0TA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC S7-1500 CPU 1515F-2 PN (6ES7515-2FM00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR324-12M (24V, ports on front) (6GK5324-0GG00-1AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-4M EEC (24V, ports on front) (6GK5324-4GG00-1ER2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W1788-2 M12 (6GK5788-2GY01-0AA0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SIMATIC HMI MTP1000 Unified Comfort Panel hygienic (6AV2128-3KB40-0AX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3MB27-1BX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE X206-1LD (6GK5206-1BC10-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W761-1 RJ45 (6GK5761-1FC00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE X302-7 EEC (24V) (6GK5302-7GD00-1EA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DK03-0AB0) toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SCALANCE X308-2LH+ (6GK5308-2FP00-2AA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-4M PoE (230V, ports on front) (6GK5324-4QG10-3AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W786-2 SFP (6GK5786-2FE00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE W1748-1 M12 (6GK5748-1GY01-0AA0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XR524-8C, 24V (6GK5524-8GS00-2AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1514SPT F-2 PN (6ES7514-2WN03-0AB0) toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SCALANCE WUM763-1 (US) (6GK5763-1AL00-3DB0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE XR526-8C, 2x230V (L3 int.) (6GK5526-8GR00-4AR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W788-2 RJ45 (6GK5788-2FC00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE XR324-12M (24V, ports on rear) (6GK5324-0GG00-1HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE SC622-2C (6GK5622-2GS00-2AC2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC S7-1500 CPU 1511-1 PN (6ES7511-1AK00-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE XF208 (6GK5208-0BA00-2AF2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE XR324-12M (230V, ports on rear) (6GK5324-0GG00-3HR2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE WUM763-1 (6GK5763-1AL00-3DA0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Unified Comfort Panel neutral design (6AV2128-3MB36-0AX1) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE X307-2 EEC (2x 24V, coated) (6GK5307-2FD00-2GA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SIMATIC HMI MTP1200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3MB57-1BX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3UB27-0BX0) versions antérieures à 21 | ||
| Siemens | N/A | SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3UB57-0BX0) versions antérieures à 21 | ||
| Siemens | N/A | SCALANCE XM408-8C (6GK5408-8GS00-2AM2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0) versions antérieures à 3.2.0 | ||
| Siemens | N/A | SCALANCE W722-1 RJ45 (6GK5722-1FC00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE W748-1 M12 (6GK5748-1GD00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DM03-0AB0) toutes versions pour les vulnérabilités CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789. | ||
| Siemens | N/A | SIMATIC S7-400 CPU 416-3 PN/DP V7 (6ES7416-3ES07-0AB0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE X204-2TS (6GK5204-2BB10-2CA2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE W778-1 M12 (6GK5778-1GY00-0AA0) versions antérieures à 6.6.0 | ||
| Siemens | N/A | SCALANCE W1788-1 M12 (6GK5788-1GY01-0AA0) toutes versions. L'éditeur indique que le produit ne bénéficiera pas de correctif de sécurité pour la vulnérabilité CVE-2025-40833. | ||
| Siemens | N/A | SCALANCE M804PB (6GK5804-0AP00-2AA2) versions antérieures à 8.3 | ||
| Siemens | N/A | SCALANCE X204-2LD TS (6GK5204-2BC10-2CA2) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE X307-2 EEC (2x 230V, coated) (6GK5307-2FD00-4GA3) toutes versions pour la vulnérabilité CVE-2025-40833 | ||
| Siemens | N/A | SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) versions antérieures à 8.3 |
| Title | Publication Time | Tags | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR524-8C, 2x230V (6GK5524-8GS00-4AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W778-1 M12 (6GK5778-1GY00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AA6) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR552-12M (2HR2) (6GK5552-0AA00-2HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-1 M12 (6GK5788-1GD00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V3 CPUs toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR524-8C, 1x230V (L3 int.) (6GK5524-8GR00-3AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X208PRO (6GK5208-0HA10-2AA6) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 319F-3 PN/DP (6ES7318-3FL01-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AC0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 317F-2 PN/DP (6ES7317-2FK14-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000 Unified Comfort Panel (6AV2128-3KB06-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X224 (6GK5224-0BA00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3XB27-0BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE SC646-2C (6GK5646-2GS00-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE TS (24V, ports on front) (6GK5324-4QG10-1CR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200S IM 151-8F PN/DP CPU (6ES7151-8FB01-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X310 (6GK5310-0FA00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAB762-1 (6GK5762-1AJ00-6AA0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAM763-1 (US) (6GK5763-1AL00-7DB0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (24V, ports on rear) (6GK5324-4GG10-1JR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W1788-2 EEC M12 (6GK5788-2GY01-0TA0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear) (6GK5324-4GG00-3JR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) V2 CPUs toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XM408-4C (6GK5408-4GP00-2AM2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X302-7 EEC (2x 24V) (6GK5302-7GD00-2EA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUM856-1 (B1) (6GK5856-2EA10-3BA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour les vuln\u00e9rabilit\u00e9s CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 319-3 PN/DP (6ES7318-3EL01-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3QB57-0BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-2 EEC (24V) (6GK5307-2FD00-1EA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W734-1 RJ45 (6GK5734-1FX00-0AA6) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W722-1 RJ45 (6GK5722-1FC00-0AC0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2 (6GK5308-2FL00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR526-8C, 1x230V (6GK5526-8GS00-3AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3XB57-0BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700 Unified Comfort Panel (6AV2128-3GB06-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear) (6GK5324-4GG10-3JR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M (24V, ports on rear) (6GK5324-0GG10-1HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR528-6M (6GK5528-0AA00-2AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"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-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3QB27-1BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel (6AV2128-3QB06-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M874-2 (6GK5874-2AA00-2AA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC CFU PA (6ES7655-5PX11-0XX0) versions ant\u00e9rieures \u00e0 2.0.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-2 EEC (230V) (6GK5307-2FD00-3EA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W734-1 RJ45 (6GK5734-1FX00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR526-8C, 24V (6GK5526-8GS00-2AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W786-2 SFP (6GK5786-2FE00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUM856-1 (A1) (6GK5856-2EA10-3AA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel neutral design (6AV2128-3QB36-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC CFU PA (6ES7655-5PX11-1XX0) versions ant\u00e9rieures \u00e0 2.0.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel hygienic (6AV2128-3QB40-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W734-1 RJ45 (USA) (6GK5734-1FX00-0AB6) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X212-2 (6GK5212-2BB00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPROTEC 5 versions sup\u00e9rieures ou \u00e9gales \u00e07.80 pour la vuln\u00e9rabilit\u00e9 CVE-2024-54017",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-2 M12 (6GK5788-2GD00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XF204-2 (6GK5204-2BC00-2AF2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M TS (24V) (6GK5324-0GG00-1CR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-400 CPU 416F-3 PN/DP V7 (6ES7416-3FS07-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR528-6M (2HR2, L3 int.) (6GK5528-0AR00-2HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 317T-3 PN/DP (6ES7317-7TK10-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X302-7 EEC (230V, coated) (6GK5302-7GD00-3GA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W1788-2IA M12 (6GK5788-2HY01-0AA0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE (230V, ports on rear) (6GK5324-4QG10-3HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X310FE (6GK5310-0BA00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPLUS S7-300 CPU 315F-2 PN/DP (6AG1315-2FJ14-2AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Unified Comfort Panel hygienic neutral design (6AV2128-3QB70-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3MB57-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200pro IM 154-8F PN/DP CPU (6ES7154-8FB01-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE (24V, ports on rear) (6GK5324-4QG10-1HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1514SPT-2 PN (6ES7514-2VN03-0AB0) toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000 Unified Comfort Panel hygienic neutral design (6AV2128-3KB70-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3UB27-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W721-1 RJ45 (6GK5721-1FC00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3XB27-1BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 PLCs Web Server versions ant\u00e9rieures \u00e0 2.9.9",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M (230V, ports on front) (6GK5324-0GG10-3AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M (230V, ports on front) (6GK5324-0GG00-3AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X204-2LD (6GK5204-2BC10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR552-12M (2HR2) (6GK5552-0AR00-2HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XF204 (6GK5204-0BA00-2AF2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2M (6GK5308-2GG10-2AA2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 CPU 1516-3 PN/DP (6ES7516-3AN00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3UB57-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (2x 24V, ports on rear) (6GK5324-4GG10-2JR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-1 RJ45 (6GK5788-1FC00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W778-1 M12 EEC (USA) (6GK5778-1GY00-0TB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 CPU 1516F-3 PN/DP (6ES7516-3FN00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 315F-2 PN/DP (6ES7315-2FJ14-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR552-12M (2HR2, L3 int.) (6GK5552-0AR00-2AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-2 RJ45 (6GK5788-2FC00-0AC0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"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-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPROTEC 5 versions sup\u00e9rieures ou \u00e9gales \u00e07.80 et versions ant\u00e9rieures \u00e0 11.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUM853-1 (A1) (6GK5853-2EA10-2AA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR524-8C, 2x230V (L3 int.) (6GK5524-8GR00-4AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-3 (6GK5307-3BL10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel (6AV2128-3UB06-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAM766-1 (6GK5766-1GE00-7DA0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC CN 4100 versions ant\u00e9rieures \u00e0 5.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3QB57-1BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-400 CPU 414-3 PN/DP V7 (6ES7414-3EM07-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M874-3 3G-Router (CN) (6GK5874-3AA00-2FA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUB852-1 (A1) (6GK5852-1EA10-1AA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2M (6GK5308-2GG00-2AA2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Panel (6AV2128-3XB06-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front) (6GK5324-4GG00-4ER2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUB852-1 (B1) (6GK5852-1EA10-1BA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X204-2 (6GK5204-2BB10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X212-2LD (6GK5212-2BC00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAM766-1 EEC (ME) (6GK5766-1GE00-7TC0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3QB27-0BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W786-2 RJ45 (6GK5786-2FC00-0AC0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3XB57-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK01-0AB0) versions ant\u00e9rieures \u00e0 2.9.9",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR552-12M (6GK5552-0AA00-2AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR526-8C, 24V (L3 int.) (6GK5526-8GR00-2AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Panel neutral design (6AV2128-3XB36-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel hygienic (6AV2128-3UB40-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 315T-3 PN/DP (6ES7315-7TJ10-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3QB57-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W721-1 RJ45 (6GK5721-1FC00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200pro IM 154-8FX PN/DP CPU (6ES7154-8FX00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W786-1 RJ45 (6GK5786-1FC00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WUM766-1 (ME) (6GK5766-1GE00-3DC0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W786-2IA RJ45 (6GK5786-2HC00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR524-8C, 24V (L3 int.) (6GK5524-8GR00-2AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP-1 PN (6ES7512-1DK01-0AB0) versions ant\u00e9rieures \u00e0 2.9.9",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000, Unified Comfort Panel neutral (6AV2128-3KB36-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M876-4 (6GK5876-4AA10-2BA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE TS (24V, ports on front) (6GK5324-4QG00-1CR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WUM763-1 (6GK5763-1AL00-3AA0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-400 H V6 CPU family (incl. SIPLUS variants) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2LH (6GK5308-2FN10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W774-1 M12 EEC (6GK5774-1FY00-0TA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WUM766-1 (6GK5766-1GE00-3DA0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel hygienic neutral design (6AV2128-3UB70-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 PLCs Web Server versions ant\u00e9rieures \u00e0 3.1.6",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W738-1 M12 (6GK5738-1GY00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-2 EEC (2x 230V) (6GK5307-2FD00-4EA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-2 EEC (24V, coated) (6GK5307-2FD00-1GA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"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-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-3 (6GK5307-3BL00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 CPU 1513-1 PN (6ES7513-1AL00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ01-0AB0) versions ant\u00e9rieures \u00e0 2.9.9",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M (230V, ports on rear) (6GK5324-0GG10-3HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W748-1 RJ45 (6GK5748-1FC00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2M TS (6GK5308-2GG00-2CA2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-2 M12 (6GK5788-2GD00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-2 M12 EEC (6GK5788-2GD00-0TB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X204-2FM (6GK5204-2BB11-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPLUS S7-300 CPU 317-2 PN/DP (6AG1317-2EK14-7AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"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-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X304-2FE (6GK5304-2BD00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-400 CPU 414F-3 PN/DP V7 (6ES7414-3FM07-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 314C-2 PN/DP (6ES7314-6EH04-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2LH (6GK5308-2FN00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUM853-1 (B1) (6GK5853-2EA10-2BA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (24V, ports on rear) (6GK5324-4GG00-1JR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (2x 24V, ports on rear) (6GK5324-4GG00-2JR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 PLCs Web Server toutes versions pour les vuln\u00e9rabilit\u00e9s CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200pro IM 154-8 PN/DP CPU (6ES7154-8AB01-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel hygienic neutral design (6AV2128-3MB70-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAM763-1 (ME) (6GK5763-1AL00-7DC0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X208 (6GK5208-0BA10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X302-7 EEC (2x 230V, coated) (6GK5302-7GD00-4GA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XM416-4C (6GK5416-4GS00-2AM2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WUB762-1 (6GK5762-1AJ00-1AA0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X302-7 EEC (24V, coated) (6GK5302-7GD00-1GA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X302-7 EEC (2x 24V, coated) (6GK5302-7GD00-2GA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W761-1 RJ45 (6GK5761-1FC00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2M TS (6GK5308-2GG10-2CA2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR528-6M (2HR2) (6GK5528-0AA00-2HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X206-1 (6GK5206-1BB10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3MB27-0BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M876-3 (6GK5876-3AA02-2BA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XM416-4C (L3 int.) (6GK5416-4GR00-2AM2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2LH+ (6GK5308-2FP10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W748-1 M12 (6GK5748-1GD00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1500 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3QB27-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-410 V8 CPU family (incl. SIPLUS variants) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W774-1 RJ45 (USA) (6GK5774-1FX00-0AB6) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Drive Controller CPU 1504D TF (6ES7615-4DF10-0AB0) versions ant\u00e9rieures \u00e0 3.1.6",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X302-7 EEC (230V) (6GK5302-7GD00-3EA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Hygienic neutral design (6AV2128-3XB70-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X320-1-2LD FE (6GK5320-3BF00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE SC626-2C (6GK5626-2GS00-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-1 RJ45 (6GK5788-1FC00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Unified Comfort Panel neutral design (6AV2128-3UB36-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB40-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X310 (6GK5310-0FA10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-2 EEC (2x 24V) (6GK5307-2FD00-2EA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (2x 24V, ports on front) (6GK5324-4GG00-2ER2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 317-2 PN/DP (6ES7317-2EK14-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB70-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W786-2 RJ45 (6GK5786-2FC00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour les vuln\u00e9rabilit\u00e9s CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-2 EEC (230V, coated) (6GK5307-2FD00-3GA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3UB27-1BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W786-2 RJ45 (6GK5786-2FC00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR526-8C, 1x230V (L3 int.) (6GK5526-8GR00-3AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAM763-1 (6GK5763-1AL00-7DA0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X408-2 (6GK5408-2FD00-2AA2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPROTEC 5 versions ant\u00e9rieures \u00e0 11.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2LD (6GK5308-2FM00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M (24V, ports on front) (6GK5324-0GG10-1AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WUB762-1 iFeatures (6GK5762-1AJ00-2AA0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR528-6M (L3 int.) (6GK5528-0AR00-2AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X310FE (6GK5310-0BA10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3MB27-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP700, Unified Comfort Panel neutral design (6AV2128-3GB36-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (2x 24V, ports on front) (6GK5324-4GG10-2ER2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W748-1 RJ45 (6GK5748-1FC00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XM408-8C (L3 int.) (6GK5408-8GR00-2AM2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front) (6GK5324-4GG10-3ER2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7 PLCs Web Server toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour les vuln\u00e9rabilit\u00e9s CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-400 CPU 412-2 PN V7 (6ES7412-2EK07-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W786-2IA RJ45 (6GK5786-2HC00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 CPU 1511F-1 PN (6ES7511-1FK00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2LD (6GK5308-2FM10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X306-1LD FE (6GK5306-1BF00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE (24V, ports on front) (6GK5324-4QG10-1AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W778-1 M12 EEC (6GK5778-1GY00-0TA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPLUS S7-400 CPU 416-3 PN/DP V7 (6AG1416-3ES07-7AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"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-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPLUS S7-300 CPU 315-2 PN/DP (6AG1315-2EH14-7AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3MB57-0BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPLUS S7-300 CPU 314C-2 PN/DP (6AG1314-6EH04-7AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M874-3 (6GK5874-3AA00-2AA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M TS (24V) (6GK5324-0GG10-1CR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP F-1 PN (6ES7510-1SJ00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W774-1 M12 EEC (6GK5774-1FY00-0TB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE MUM856-1 (CN) (6GK5856-2EA00-3FA1) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W738-1 M12 (6GK5738-1GY00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE (230V, ports on rear) (6GK5324-4QG00-3HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAM766-1 (ME) (6GK5766-1GE00-7DC0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP HA IM155-6 PN versions ant\u00e9rieures \u00e0 1.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE SC642-2C (6GK5642-2GS00-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-2 M12 EEC (6GK5788-2GD00-0TC0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-1 M12 (6GK5788-1GD00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear) (6GK5324-4GG10-4JR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2 RD (inkl. SIPLUS variants) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-3LD (6GK5307-3BM10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3XB27-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE (230V, ports on front) (6GK5324-4QG00-3AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3XB57-1BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X302-7 EEC (2x 230V) (6GK5302-7GD00-4EA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W786-1 RJ45 (6GK5786-1FC00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-410 V10 CPU family (incl. SIPLUS variants) versions ant\u00e9rieures \u00e0 10.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3UB57-1BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour les vuln\u00e9rabilit\u00e9s CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPLUS S7-300 CPU 317F-2 PN/DP (6AG1317-2FK14-2AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WUM763-1 (US) (6GK5763-1AL00-3AB0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XF206-1 (6GK5206-1BC00-2AF2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour les vuln\u00e9rabilit\u00e9s CVE-2026-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2M PoE (6GK5308-2QG10-2AA2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC Drive Controller CPU 1507D TF (6ES7615-7DF10-0AB0) versions ant\u00e9rieures \u00e0 3.1.6",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR524-8C, 1x230V (6GK5524-8GS00-3AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE SC632-2C (6GK5632-2GS00-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 CPU 1515-2 PN (6ES7515-2AM00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR526-8C, 2x230V (6GK5526-8GS00-4AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-3LD (6GK5307-3BM00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2M PoE (6GK5308-2QG00-2AA2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XM408-4C (L3 int.) (6GK5408-4GQ00-2AM2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 317TF-3 PN/DP (6ES7317-7UL10-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE (24V, ports on front) (6GK5324-4QG00-1AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1512SP F-1 PN (6ES7512-1SK00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP2200 Unified Comfort Hygienic (6AV2128-3XB40-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200S IM 151-8 PN/DP CPU (6ES7151-8AB01-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X320-1 FE (6GK5320-1BD00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X216 (6GK5216-0BA00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"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-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-300 CPU 315-2 PN/DP (6ES7315-2EH14-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front) (6GK5324-4GG10-4ER2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC CFU DIQ (6ES7655-5PX31-1XX0) versions ant\u00e9rieures \u00e0 2.0.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W722-1 RJ45 (6GK5722-1FC00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear) (6GK5324-4GG00-4JR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W1748-1 M12 (6GK5748-1GY01-0TA0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel (6AV2128-3MB06-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front) (6GK5324-4GG00-3ER2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel hygienic (6AV2128-3MB40-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE SC636-2C (6GK5636-2GS00-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC ET 200SP CPU 1510SP-1 PN (6ES7510-1DJ01-0AB0) versions ant\u00e9rieures \u00e0 2.9.9",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (24V, ports on front) (6GK5324-4GG10-1ER2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIPLUS S7-400 CPU 414-3 PN/DP V7 (6AG1414-3EM07-7AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W734-1 RJ45 (6GK5734-1FX00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-2 RJ45 (6GK5788-2FC00-0AB0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE (24V, ports on rear) (6GK5324-4QG00-1HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-2 M12 EEC (6GK5788-2GD00-0TA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 CPU 1515F-2 PN (6ES7515-2FM00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M (24V, ports on front) (6GK5324-0GG00-1AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M EEC (24V, ports on front) (6GK5324-4GG00-1ER2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W1788-2 M12 (6GK5788-2GY01-0AA0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1000 Unified Comfort Panel hygienic (6AV2128-3KB40-0AX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3MB27-1BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X206-1LD (6GK5206-1BC10-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W761-1 RJ45 (6GK5761-1FC00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X302-7 EEC (24V) (6GK5302-7GD00-1EA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"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-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X308-2LH+ (6GK5308-2FP00-2AA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-4M PoE (230V, ports on front) (6GK5324-4QG10-3AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W786-2 SFP (6GK5786-2FE00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W1748-1 M12 (6GK5748-1GY01-0AA0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR524-8C, 24V (6GK5524-8GS00-2AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"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-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WUM763-1 (US) (6GK5763-1AL00-3DB0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR526-8C, 2x230V (L3 int.) (6GK5526-8GR00-4AR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W788-2 RJ45 (6GK5788-2FC00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M (24V, ports on rear) (6GK5324-0GG00-1HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE SC622-2C (6GK5622-2GS00-2AC2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-1500 CPU 1511-1 PN (6ES7511-1AK00-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XF208 (6GK5208-0BA00-2AF2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XR324-12M (230V, ports on rear) (6GK5324-0GG00-3HR2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WUM763-1 (6GK5763-1AL00-3DA0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Unified Comfort Panel neutral design (6AV2128-3MB36-0AX1) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-2 EEC (2x 24V, coated) (6GK5307-2FD00-2GA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3MB57-1BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3UB27-0BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3UB57-0BX0) versions ant\u00e9rieures \u00e0 21",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE XM408-8C (6GK5408-8GS00-2AM2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0) versions ant\u00e9rieures \u00e0 3.2.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W722-1 RJ45 (6GK5722-1FC00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W748-1 M12 (6GK5748-1GD00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"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-25786, CVE-2026-25787 et CVE-2026-25789.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SIMATIC S7-400 CPU 416-3 PN/DP V7 (6ES7416-3ES07-0AB0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X204-2TS (6GK5204-2BB10-2CA2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W778-1 M12 (6GK5778-1GY00-0AA0) versions ant\u00e9rieures \u00e0 6.6.0",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE W1788-1 M12 (6GK5788-1GY01-0AA0) toutes versions. L\u0027\u00e9diteur indique que le produit ne b\u00e9n\u00e9ficiera pas de correctif de s\u00e9curit\u00e9 pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833.",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M804PB (6GK5804-0AP00-2AA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X204-2LD TS (6GK5204-2BC10-2CA2) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE X307-2 EEC (2x 230V, coated) (6GK5307-2FD00-4GA3) toutes versions pour la vuln\u00e9rabilit\u00e9 CVE-2025-40833",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
},
{
"description": "SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) versions ant\u00e9rieures \u00e0 8.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Siemens",
"scada": true
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-47219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47219"
},
{
"name": "CVE-2025-39812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39812"
},
{
"name": "CVE-2026-21933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21933"
},
{
"name": "CVE-2026-21932",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21932"
},
{
"name": "CVE-2025-38711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38711"
},
{
"name": "CVE-2025-39808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39808"
},
{
"name": "CVE-2025-9231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9231"
},
{
"name": "CVE-2025-39757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39757"
},
{
"name": "CVE-2025-39772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39772"
},
{
"name": "CVE-2025-39826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39826"
},
{
"name": "CVE-2025-39716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39716"
},
{
"name": "CVE-2025-39702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39702"
},
{
"name": "CVE-2025-39685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39685"
},
{
"name": "CVE-2025-39827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39827"
},
{
"name": "CVE-2025-39828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39828"
},
{
"name": "CVE-2025-6052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6052"
},
{
"name": "CVE-2025-38491",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38491"
},
{
"name": "CVE-2025-38708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38708"
},
{
"name": "CVE-2025-40833",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40833"
},
{
"name": "CVE-2025-39701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39701"
},
{
"name": "CVE-2026-25787",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25787"
},
{
"name": "CVE-2026-22925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22925"
},
{
"name": "CVE-2025-39709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39709"
},
{
"name": "CVE-2025-39689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39689"
},
{
"name": "CVE-2025-39787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39787"
},
{
"name": "CVE-2025-55752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55752"
},
{
"name": "CVE-2025-38695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38695"
},
{
"name": "CVE-2025-39749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39749"
},
{
"name": "CVE-2025-39866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39866"
},
{
"name": "CVE-2025-39843",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39843"
},
{
"name": "CVE-2025-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23160"
},
{
"name": "CVE-2025-9820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9820"
},
{
"name": "CVE-2025-39681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39681"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2025-38706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38706"
},
{
"name": "CVE-2025-38699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38699"
},
{
"name": "CVE-2025-38707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38707"
},
{
"name": "CVE-2025-39692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39692"
},
{
"name": "CVE-2025-38677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38677"
},
{
"name": "CVE-2025-39853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39853"
},
{
"name": "CVE-2025-39857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39857"
},
{
"name": "CVE-2025-39865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39865"
},
{
"name": "CVE-2025-39675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39675"
},
{
"name": "CVE-2025-38693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38693"
},
{
"name": "CVE-2025-38679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38679"
},
{
"name": "CVE-2025-38685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38685"
},
{
"name": "CVE-2025-38502",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38502"
},
{
"name": "CVE-2025-39838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39838"
},
{
"name": "CVE-2025-39823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39823"
},
{
"name": "CVE-2026-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21925"
},
{
"name": "CVE-2025-39864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39864"
},
{
"name": "CVE-2025-39824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39824"
},
{
"name": "CVE-2025-39737",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39737"
},
{
"name": "CVE-2025-38702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38702"
},
{
"name": "CVE-2025-38724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38724"
},
{
"name": "CVE-2025-38698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38698"
},
{
"name": "CVE-2025-39842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39842"
},
{
"name": "CVE-2025-37931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37931"
},
{
"name": "CVE-2025-39849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39849"
},
{
"name": "CVE-2026-28389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28389"
},
{
"name": "CVE-2025-39743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39743"
},
{
"name": "CVE-2025-39718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39718"
},
{
"name": "CVE-2025-38712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38712"
},
{
"name": "CVE-2025-38732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38732"
},
{
"name": "CVE-2025-39773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39773"
},
{
"name": "CVE-2025-38696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38696"
},
{
"name": "CVE-2025-38727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38727"
},
{
"name": "CVE-2025-38670",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38670"
},
{
"name": "CVE-2025-55754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55754"
},
{
"name": "CVE-2025-39845",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39845"
},
{
"name": "CVE-2025-39788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39788"
},
{
"name": "CVE-2025-38735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38735"
},
{
"name": "CVE-2025-7425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7425"
},
{
"name": "CVE-2025-43368",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-43368"
},
{
"name": "CVE-2025-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38614"
},
{
"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-2025-9232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9232"
},
{
"name": "CVE-2025-38694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38694"
},
{
"name": "CVE-2025-61795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61795"
},
{
"name": "CVE-2025-38676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38676"
},
{
"name": "CVE-2025-38729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38729"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2026-28387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28387"
},
{
"name": "CVE-2025-39795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39795"
},
{
"name": "CVE-2026-28388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28388"
},
{
"name": "CVE-2025-38687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38687"
},
{
"name": "CVE-2025-38728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38728"
},
{
"name": "CVE-2025-38715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38715"
},
{
"name": "CVE-2025-39710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39710"
},
{
"name": "CVE-2025-48989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48989"
},
{
"name": "CVE-2025-39683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39683"
},
{
"name": "CVE-2025-39794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39794"
},
{
"name": "CVE-2025-39697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39697"
},
{
"name": "CVE-2026-25786",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25786"
},
{
"name": "CVE-2025-38713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38713"
},
{
"name": "CVE-2025-39782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39782"
},
{
"name": "CVE-2025-38697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38697"
},
{
"name": "CVE-2025-38691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38691"
},
{
"name": "CVE-2025-39759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39759"
},
{
"name": "CVE-2025-39860",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39860"
},
{
"name": "CVE-2025-39760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39760"
},
{
"name": "CVE-2025-39673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39673"
},
{
"name": "CVE-2025-39839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39839"
},
{
"name": "CVE-2025-38723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38723"
},
{
"name": "CVE-2024-57924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57924"
},
{
"name": "CVE-2025-39848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39848"
},
{
"name": "CVE-2025-39800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39800"
},
{
"name": "CVE-2025-39703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39703"
},
{
"name": "CVE-2025-39825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39825"
},
{
"name": "CVE-2025-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38552"
},
{
"name": "CVE-2026-28390",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28390"
},
{
"name": "CVE-2025-39766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39766"
},
{
"name": "CVE-2025-39801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39801"
},
{
"name": "CVE-2025-39724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39724"
},
{
"name": "CVE-2025-39687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39687"
},
{
"name": "CVE-2025-39694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39694"
},
{
"name": "CVE-2025-40300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40300"
},
{
"name": "CVE-2025-39806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39806"
},
{
"name": "CVE-2025-38721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38721"
},
{
"name": "CVE-2025-39684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39684"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2025-38347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38347"
},
{
"name": "CVE-2025-39776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39776"
},
{
"name": "CVE-2025-6021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6021"
},
{
"name": "CVE-2025-37968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37968"
},
{
"name": "CVE-2026-22924",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22924"
},
{
"name": "CVE-2025-38683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38683"
},
{
"name": "CVE-2026-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21945"
},
{
"name": "CVE-2025-39736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39736"
},
{
"name": "CVE-2025-39846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39846"
},
{
"name": "CVE-2026-31789",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31789"
},
{
"name": "CVE-2025-39691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39691"
},
{
"name": "CVE-2025-39844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39844"
},
{
"name": "CVE-2025-39742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39742"
},
{
"name": "CVE-2025-61748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61748"
},
{
"name": "CVE-2025-9230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9230"
},
{
"name": "CVE-2026-21947",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21947"
},
{
"name": "CVE-2025-38701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38701"
},
{
"name": "CVE-2024-58240",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58240"
},
{
"name": "CVE-2025-8916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8916"
},
{
"name": "CVE-2024-54017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54017"
},
{
"name": "CVE-2025-39817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39817"
},
{
"name": "CVE-2024-47704",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47704"
},
{
"name": "CVE-2025-39790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39790"
},
{
"name": "CVE-2026-2673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2673"
},
{
"name": "CVE-2025-38680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38680"
},
{
"name": "CVE-2025-38684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38684"
},
{
"name": "CVE-2025-39686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39686"
},
{
"name": "CVE-2025-39798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39798"
},
{
"name": "CVE-2026-27662",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27662"
},
{
"name": "CVE-2025-39714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39714"
},
{
"name": "CVE-2025-39706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39706"
},
{
"name": "CVE-2026-25789",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25789"
},
{
"name": "CVE-2025-39719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39719"
},
{
"name": "CVE-2025-39738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39738"
},
{
"name": "CVE-2025-39713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39713"
},
{
"name": "CVE-2025-31257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31257"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-38736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38736"
},
{
"name": "CVE-2025-39693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39693"
},
{
"name": "CVE-2025-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53057"
},
{
"name": "CVE-2025-39682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39682"
},
{
"name": "CVE-2025-39676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39676"
},
{
"name": "CVE-2025-39813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39813"
},
{
"name": "CVE-2025-39847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39847"
},
{
"name": "CVE-2025-39819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39819"
},
{
"name": "CVE-2025-39783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39783"
},
{
"name": "CVE-2025-39715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39715"
},
{
"name": "CVE-2025-39835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39835"
},
{
"name": "CVE-2025-38700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38700"
},
{
"name": "CVE-2025-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53066"
},
{
"name": "CVE-2025-39841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39841"
},
{
"name": "CVE-2026-31790",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31790"
},
{
"name": "CVE-2025-14831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14831"
},
{
"name": "CVE-2025-38714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38714"
},
{
"name": "CVE-2025-39752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39752"
}
],
"initial_release_date": "2026-05-12T00:00:00",
"last_revision_date": "2026-05-12T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0565",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-05-12T00: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-05-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-392349",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-392349.html"
},
{
"published_at": "2026-05-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-032379",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"published_at": "2026-05-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-786884",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-786884.html"
},
{
"published_at": "2026-05-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-688146",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-688146.html"
},
{
"published_at": "2026-05-12",
"title": "Bulletin de s\u00e9curit\u00e9 Siemens SSA-387223",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-387223.html"
}
]
}
FKIE_CVE-2025-39752
Vulnerability from fkie_nvd - Published: 2025-09-11 17:15 - Updated: 2026-06-17 09:18| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| debian | debian_linux | 11.0 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/arm/mach-rockchip/platsmp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "3c6bf7a324b8995b9c7d790c8d2abf0668f51551",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "888a453c2a239765a7ab4de8a3cedae2e3802528",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "c0726d1e466e2d0da620836e293a59e6427ccdff",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "265583266d93db4ff83d088819b1f63fdf0131db",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "d7d6d076ee9532c4668f14696a35688d35dd16f4",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "0223a3683d502b7e5eb2eb4ad7e97363fa88d531",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "47769dab9073a73e127aa0bfd0ba4c51eaccdc33",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "1eb67589a7e091b1e5108aab72fddbf4dc69af2c",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
},
{
"lessThan": "7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814",
"status": "affected",
"version": "3ee851e212d0bb6be8c462059fba74ce2e3f6064",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm/mach-rockchip/platsmp.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.19"
},
{
"lessThan": "3.19",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.297",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.241",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.190",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.149",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.103",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.43",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.15.*",
"status": "unaffected",
"version": "6.15.11",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "SIMATIC CN 4100",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V5.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "26EE76A2-8203-4511-8272-15BCB88FA40C",
"versionEndExcluding": "5.4.297",
"versionStartIncluding": "3.19",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "D0D21C35-EB8A-488A-BBF9-403E4817E5DD",
"versionEndExcluding": "5.10.241",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "AD9E597F-3DDE-4D7E-976C-463D0611F13F",
"versionEndExcluding": "5.15.190",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "FDBE8280-8983-4D2D-943D-2E6D0104E2D8",
"versionEndExcluding": "6.1.149",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F2293654-7169-49B5-8D0D-EE51EF8B8E48",
"versionEndExcluding": "6.6.103",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "472C5F87-2BF3-4FAB-9B21-DA7513977363",
"versionEndExcluding": "6.12.43",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BC242347-F722-43AE-B910-BE0B22386977",
"versionEndExcluding": "6.15.11",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BD7C087D-2415-4521-B624-30003352F899",
"versionEndExcluding": "6.16.2",
"versionStartIncluding": "6.16",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*",
"matchCriteriaId": "FA6FEEC2-9F11-4643-8827-749718254FED",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0027t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4"
}
],
"id": "CVE-2025-39752",
"lastModified": "2026-06-17T09:18:24.537",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 5.5,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 3.6,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-09-11T17:15:38.900",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/0223a3683d502b7e5eb2eb4ad7e97363fa88d531"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1eb67589a7e091b1e5108aab72fddbf4dc69af2c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/265583266d93db4ff83d088819b1f63fdf0131db"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3c6bf7a324b8995b9c7d790c8d2abf0668f51551"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/47769dab9073a73e127aa0bfd0ba4c51eaccdc33"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/888a453c2a239765a7ab4de8a3cedae2e3802528"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c0726d1e466e2d0da620836e293a59e6427ccdff"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/d7d6d076ee9532c4668f14696a35688d35dd16f4"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "NVD-CWE-noinfo"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-PR7Q-PHHW-MF48
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2026-05-12 15:31In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4
{
"affected": [],
"aliases": [
"CVE-2025-39752"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:38Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0027t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4",
"id": "GHSA-pr7q-phhw-mf48",
"modified": "2026-05-12T15:31:06Z",
"published": "2025-09-11T18:35:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0223a3683d502b7e5eb2eb4ad7e97363fa88d531"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1eb67589a7e091b1e5108aab72fddbf4dc69af2c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/265583266d93db4ff83d088819b1f63fdf0131db"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3c6bf7a324b8995b9c7d790c8d2abf0668f51551"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47769dab9073a73e127aa0bfd0ba4c51eaccdc33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7cdb433bb44cdc87dc5260cdf15bf03cc1cd1814"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/888a453c2a239765a7ab4de8a3cedae2e3802528"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0726d1e466e2d0da620836e293a59e6427ccdff"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7d6d076ee9532c4668f14696a35688d35dd16f4"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
ICSA-26-134-10
Vulnerability from csaf_cisa - Published: 2026-05-12 00:00 - Updated: 2026-05-14 06:00MSRC_CVE-2025-39752
Vulnerability from csaf_microsoft - Published: 2025-09-02 00:00 - Updated: 2026-02-24 14:38NCSC-2026-0147
Vulnerability from csaf_ncscnl - Published: 2026-05-13 06:33 - Updated: 2026-05-13 06:33A comprehensive Linux kernel update addresses multiple security vulnerabilities including ARM rockchip SMP initialization hangs, CPU cache initialization flaws, AMD processor data leaks, AppArmor LSM privilege escalations, and the VMSCAPE branch predictor isolation issue across various architectures and subsystems.
oesa-2025-2407
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: Avoid cross-chip syncing of VLAN filtering
Changes to VLAN filtering are not applicable to cross-chip notifications.
On a system like this:
.-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-'
Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.
In this scenario:
.---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-'
When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix a race condition between login_work and the login thread
In case a malicious initiator sends some random data immediately after a login PDU; the iscsi_target_sk_data_ready() callback will schedule the login_work and, at the same time, the negotiation may end without clearing the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are required to complete the login).
The login has been completed but the login_work function will find the LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsit_conn structure will be freed, login_work will dereference a released socket structure and the kernel crashes.
BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod] RIP: 0010:_raw_read_lock_bh+0x15/0x30 Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0
Fix this bug by forcing login_work to stop after the login has been completed and the socket callbacks have been restored.
Add a comment to clearify the return values of iscsi_target_do_login()(CVE-2022-50350)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: fbcon: release buffer when fbcon_do_set_font() failed
syzbot is reporting memory leak at fbcon_do_set_font() [1], for commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") missed that the buffer might be newly allocated by fbcon_set_font().(CVE-2022-50404)
In the Linux kernel, the following vulnerability has been resolved:
udf: Fix uninitialized array access for some pathnames
For filenames that begin with . and are between 2 and 5 characters long, UDF charset conversion code would read uninitialized memory in the output buffer. The only practical impact is that the name may be prepended a "unification hash" when it is not actually needed but still it is good to fix this.(CVE-2023-53165)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: call op_release, even when op_func returns an error
For ops with "trivial" replies, nfsd4_encode_operation will shortcut most of the encoding work and skip to just marshalling up the status. One of the things it skips is calling op_release. This could cause a memory leak in the layoutget codepath if there is an error at an inopportune time.
Have the compound processing engine always call op_release, even when op_func sets an error in op->status. With this change, we also need nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL on error to avoid a double free.(CVE-2023-53241)
In the Linux kernel, the following vulnerability has been resolved:
VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF
The call to get_user_pages_fast() in vmci_host_setup_notify() can return NULL context->notify_page causing a GPF. To avoid GPF check if context->notify_page == NULL and return error if so.
general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x0005088000000300- 0x0005088000000307] CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0 Call Trace: <TASK> vmci_host_unlocked_ioctl+0x362/0x1f40 __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-53259)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
The variable codec->regmap is often protected by the lock codec->regmap_lock when is accessed. However, it is accessed without holding the lock when is accessed in snd_hdac_regmap_sync():
if (codec->regmap)
In my opinion, this may be a harmful race, because if codec->regmap is set to NULL right after the condition is checked, a null-pointer dereference can occur in the called function regcache_sync():
map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c
To fix this possible null-pointer dereference caused by data race, the mutex_lock coverage is extended to protect the if statement as well as the function call to regcache_sync().
In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Return the firmware result upon destroying QP/RQ
Previously when destroying a QP/RQ, the result of the firmware destruction function was ignored and upper layers weren't informed about the failure. Which in turn could lead to various problems since when upper layer isn't aware of the failure it continues its operation thinking that the related QP/RQ was successfully destroyed while it actually wasn't, which could lead to the below kernel WARN.
Currently, we return the correct firmware destruction status to upper layers which in case of the RQ would be mlx5_ib_destroy_wq() which was already capable of handling RQ destruction failure or in case of a QP to destroy_qp_common(), which now would actually warn upon qp destruction failure.
WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse CPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 <0f> 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287 RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000 RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0 RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009 R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780 R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000 FS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ib_uverbs_close+0x1a/0x90 [ib_uverbs] __fput+0x82/0x230 task_work_run+0x59/0x90 exit_to_user_mode_prepare+0x138/0x140 syscall_exit_to_user_mode+0x1d/0x50 ? __x64_sys_close+0xe/0x40 do_syscall_64+0x4a/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f8be3ae0abb Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44 RSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb RDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005 RBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8 R13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020 </TASK>(CVE-2023-53286)
In the Linux kernel, the following vulnerability has been resolved:
pstore/ram: Check start of empty przs during init
After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as valid"), initialization would assume a prz was valid after seeing that the buffer_size is zero (regardless of the buffer start position). This unchecked start value means it could be outside the bounds of the buffer, leading to future access panics when written to:
sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78 __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 ...
To avoid this, also check if the prz start is 0 during the initialization phase. If not, the next prz sanity check case will discover it (start > size) and zap the buffer back to a sane state.
kees: update commit log with backtrace and clarifications
In the Linux kernel, the following vulnerability has been resolved:
net: dcb: choose correct policy to parse DCB_ATTR_BCN
The dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN], which is introduced in commit 859ee3c43812 ("DCB: Add support for DCB BCN"). Please see the comment in below code
static int dcbnl_bcn_setcfg(...) { ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_nest for attributes // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) { // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs ... value_int = nla_get_u32(data[i]); ... } ... }
That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nest attributes to parse nlattr defined in dcbnl_pfc_up_attrs. But the following access code fetch each nlattr as dcbnl_bcn_attrs attributes. By looking up the associated nla_policy for dcbnl_bcn_attrs. We can find the beginning part of these two policies are "same".
static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG}, };
static const struct nla_policy dcbnl_bcn_nest[...] = { [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // from here is somewhat different [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG}, };
Therefore, the current code is buggy and this nla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use the adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.
Hence use the correct policy dcbnl_bcn_nest to parse the nested tb[DCB_ATTR_BCN] TLV.(CVE-2023-53369)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mwifiex: avoid possible NULL skb pointer dereference
In 'mwifiex_handle_uap_rx_forward()', always check the value returned by 'skb_copy()' to avoid potential NULL pointer dereference in 'mwifiex_uap_queue_bridged_pkt()', and drop original skb in case of copying failure.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53384)
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer
ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5
According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.
When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.
============================================================= UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]' CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c acpi_power_meter
In the Linux kernel, the following vulnerability has been resolved:
x86/MCE: Always save CS register on AMD Zen IF Poison errors
The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed.
There is no architecturally-defined method to determine this behavior.
The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV].
Add a quirk to save the CS register for poison consumption from the IF unit banks.
This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context.(CVE-2023-53438)
In the Linux kernel, the following vulnerability has been resolved:
net: ravb: Fix missing rtnl lock in suspend/resume path
Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations.
Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)
In the Linux kernel, the following vulnerability has been resolved:
spufs: fix a leak on spufs_new_file() failure
It's called from spufs_fill_dir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped.(CVE-2025-22073)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc: fix double-free on mc_dev
The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable.
In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed.
This commit introduces back the following checkpatch warning which is a false-positive.
WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus);(CVE-2025-38313)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: cancle set bad inode after removing name fails
The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted.
The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles".(CVE-2025-38615)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
tee: fix NULL pointer dereference in tee_shm_put
tee_shm_put have NULL pointer dereference:
__optee_disable_shm_cache --> shm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> tee_shm_put(shm);//crash
Add check in tee_shm_put to fix it.
panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tee_shm_put+0x24/0x188 lr : tee_shm_free+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: tee_shm_put+0x24/0x188 tee_shm_free+0x14/0x28 __optee_disable_shm_cache+0xa8/0x108 optee_shutdown+0x28/0x38 platform_shutdown+0x28/0x40 device_shutdown+0x144/0x2b0 kernel_power_off+0x3c/0x80 hibernate+0x35c/0x388 state_store+0x64/0x80 kobj_attr_store+0x14/0x28 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x128/0x1c0 vfs_write+0x270/0x370 ksys_write+0x6c/0x100 __arm64_sys_write+0x20/0x30 invoke_syscall+0x4c/0x120 el0_svc_common.constprop.0+0x44/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x24/0x88 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x14c/0x15(CVE-2025-39865)
In the Linux kernel, a use-after-free vulnerability exists in the __mark_inode_dirty() function. The issue occurs when __mark_inode_dirty() obtains a bdi_writeback that is in the process of switching. This is a race condition vulnerability between inode_switch_wbs_work_fn() and ___mark_inode_dirty(), causing the old writeback structure to be accessed after it has been released, triggering a use-after-free vulnerability.(CVE-2025-39866)
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory
When I did memory failure tests, below panic occurs:
page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: <TASK> unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 </TASK> Modules linked in: hwpoison_inject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---
The root cause is that unpoison_memory() tries to check the PG_HWPoison flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps:
1.Offline memory block:
echo offline > /sys/devices/system/memory/memory12/state
2.Get offlined memory pfn:
page-types -b n -rlN
3.Write pfn to unpoison-pfn
echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn
This scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail if pfn_to_online_page() == NULL to fix the bug.(CVE-2025-39883)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"perf-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-284.0.0.186.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"perf-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-284.0.0.186.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-284.0.0.186.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-284.0.0.186.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\nnet: dsa: Avoid cross-chip syncing of VLAN filtering\n\nChanges to VLAN filtering are not applicable to cross-chip\nnotifications.\n\nOn a system like this:\n\n.-----. .-----. .-----.\n| sw1 +---+ sw2 +---+ sw3 |\n\u0026apos;-1-2-\u0026apos; \u0026apos;-1-2-\u0026apos; \u0026apos;-1-2-\u0026apos;\n\nBefore this change, upon sw1p1 leaving a bridge, a call to\ndsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.\n\nIn this scenario:\n\n.---------. .-----. .-----.\n| sw1 +---+ sw2 +---+ sw3 |\n\u0026apos;-1-2-3-4-\u0026apos; \u0026apos;-1-2-\u0026apos; \u0026apos;-1-2-\u0026apos;\n\nWhen sw1p4 would leave a bridge, dsa_port_vlan_filtering would be\ncalled for sw2 and sw3 with a non-existing port - leading to array\nout-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix a race condition between login_work and the login thread\n\nIn case a malicious initiator sends some random data immediately after a\nlogin PDU; the iscsi_target_sk_data_ready() callback will schedule the\nlogin_work and, at the same time, the negotiation may end without clearing\nthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are\nrequired to complete the login).\n\nThe login has been completed but the login_work function will find the\nLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling\nitself; at this point, if the initiator drops the connection, the\niscsit_conn structure will be freed, login_work will dereference a released\nsocket structure and the kernel crashes.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000230\nPF: supervisor write access in kernel mode\nPF: error_code(0x0002) - not-present page\nWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]\nRIP: 0010:_raw_read_lock_bh+0x15/0x30\nCall trace:\n iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]\n process_one_work+0x1e8/0x3c0\n\nFix this bug by forcing login_work to stop after the login has been\ncompleted and the socket callbacks have been restored.\n\nAdd a comment to clearify the return values of iscsi_target_do_login()(CVE-2022-50350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: fbcon: release buffer when fbcon_do_set_font() failed\n\nsyzbot is reporting memory leak at fbcon_do_set_font() [1], for\ncommit a5a923038d70 (\u0026quot;fbdev: fbcon: Properly revert changes when\nvc_resize() failed\u0026quot;) missed that the buffer might be newly allocated\nby fbcon_set_font().(CVE-2022-50404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudf: Fix uninitialized array access for some pathnames\n\nFor filenames that begin with . and are between 2 and 5 characters long,\nUDF charset conversion code would read uninitialized memory in the\noutput buffer. The only practical impact is that the name may be prepended a\n\u0026quot;unification hash\u0026quot; when it is not actually needed but still it is good\nto fix this.(CVE-2023-53165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: call op_release, even when op_func returns an error\n\nFor ops with \u0026quot;trivial\u0026quot; replies, nfsd4_encode_operation will shortcut\nmost of the encoding work and skip to just marshalling up the status.\nOne of the things it skips is calling op_release. This could cause a\nmemory leak in the layoutget codepath if there is an error at an\ninopportune time.\n\nHave the compound processing engine always call op_release, even when\nop_func sets an error in op-\u0026gt;status. With this change, we also need\nnfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL\non error to avoid a double free.(CVE-2023-53241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: check context-\u0026gt;notify_page after call to get_user_pages_fast() to avoid GPF\n\nThe call to get_user_pages_fast() in vmci_host_setup_notify() can return\nNULL context-\u0026gt;notify_page causing a GPF. To avoid GPF check if\ncontext-\u0026gt;notify_page == NULL and return error if so.\n\ngeneral protection fault, probably for non-canonical address\n 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: maybe wild-memory-access in range [0x0005088000000300-\n 0x0005088000000307]\nCPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1\nHardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014\nRIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vmci_host_unlocked_ioctl+0x362/0x1f40\n __x64_sys_ioctl+0x1a1/0x230\n do_syscall_64+0x3a/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-53259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()\n\nThe variable codec-\u0026gt;regmap is often protected by the lock\ncodec-\u0026gt;regmap_lock when is accessed. However, it is accessed without\nholding the lock when is accessed in snd_hdac_regmap_sync():\n\n if (codec-\u0026gt;regmap)\n\nIn my opinion, this may be a harmful race, because if codec-\u0026gt;regmap is\nset to NULL right after the condition is checked, a null-pointer\ndereference can occur in the called function regcache_sync():\n\n map-\u0026gt;lock(map-\u0026gt;lock_arg); --\u0026gt; Line 360 in drivers/base/regmap/regcache.c\n\nTo fix this possible null-pointer dereference caused by data race, the\nmutex_lock coverage is extended to protect the if statement as well as the\nfunction call to regcache_sync().\n\n[ Note: the lack of the regmap_lock itself is harmless for the current\n codec driver implementations, as snd_hdac_regmap_sync() is only for\n PM runtime resume that is prohibited during the codec probe.\n But the change makes the whole code more consistent, so it\u0026apos;s merged\n as is -- tiwai ](CVE-2023-53275)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Return the firmware result upon destroying QP/RQ\n\nPreviously when destroying a QP/RQ, the result of the firmware\ndestruction function was ignored and upper layers weren\u0026apos;t informed\nabout the failure.\nWhich in turn could lead to various problems since when upper layer\nisn\u0026apos;t aware of the failure it continues its operation thinking that the\nrelated QP/RQ was successfully destroyed while it actually wasn\u0026apos;t,\nwhich could lead to the below kernel WARN.\n\nCurrently, we return the correct firmware destruction status to upper\nlayers which in case of the RQ would be mlx5_ib_destroy_wq() which\nwas already capable of handling RQ destruction failure or in case of\na QP to destroy_qp_common(), which now would actually warn upon qp\ndestruction failure.\n\nWARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]\nModules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse\nCPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]\nCode: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 \u0026lt;0f\u0026gt; 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f\nRSP: 0018:ffff8881533e3e78 EFLAGS: 00010287\nRAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000\nRDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0\nRBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009\nR10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780\nR13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000\nFS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ib_uverbs_close+0x1a/0x90 [ib_uverbs]\n __fput+0x82/0x230\n task_work_run+0x59/0x90\n exit_to_user_mode_prepare+0x138/0x140\n syscall_exit_to_user_mode+0x1d/0x50\n ? __x64_sys_close+0xe/0x40\n do_syscall_64+0x4a/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f8be3ae0abb\nCode: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44\nRSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003\nRAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb\nRDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005\nRBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8\nR13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020\n \u0026lt;/TASK\u0026gt;(CVE-2023-53286)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npstore/ram: Check start of empty przs during init\n\nAfter commit 30696378f68a (\u0026quot;pstore/ram: Do not treat empty buffers as\nvalid\u0026quot;), initialization would assume a prz was valid after seeing that\nthe buffer_size is zero (regardless of the buffer start position). This\nunchecked start value means it could be outside the bounds of the buffer,\nleading to future access panics when written to:\n\n sysdump_panic_event+0x3b4/0x5b8\n atomic_notifier_call_chain+0x54/0x90\n panic+0x1c8/0x42c\n die+0x29c/0x2a8\n die_kernel_fault+0x68/0x78\n __do_kernel_fault+0x1c4/0x1e0\n do_bad_area+0x40/0x100\n do_translation_fault+0x68/0x80\n do_mem_abort+0x68/0xf8\n el1_da+0x1c/0xc0\n __raw_writeb+0x38/0x174\n __memcpy_toio+0x40/0xac\n persistent_ram_update+0x44/0x12c\n persistent_ram_write+0x1a8/0x1b8\n ramoops_pstore_write+0x198/0x1e8\n pstore_console_write+0x94/0xe0\n ...\n\nTo avoid this, also check if the prz start is 0 during the initialization\nphase. If not, the next prz sanity check case will discover it (start \u0026gt;\nsize) and zap the buffer back to a sane state.\n\n[kees: update commit log with backtrace and clarifications](CVE-2023-53331)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dcb: choose correct policy to parse DCB_ATTR_BCN\n\nThe dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],\nwhich is introduced in commit 859ee3c43812 (\u0026quot;DCB: Add support for DCB\nBCN\u0026quot;). Please see the comment in below code\n\nstatic int dcbnl_bcn_setcfg(...)\n{\n ...\n ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. )\n // !!! dcbnl_pfc_up_nest for attributes\n // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs\n ...\n for (i = DCB_BCN_ATTR_RP_0; i \u0026lt;= DCB_BCN_ATTR_RP_7; i++) {\n // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs\n ...\n value_byte = nla_get_u8(data[i]);\n ...\n }\n ...\n for (i = DCB_BCN_ATTR_BCNA_0; i \u0026lt;= DCB_BCN_ATTR_RI; i++) {\n // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs\n ...\n value_int = nla_get_u32(data[i]);\n ...\n }\n ...\n}\n\nThat is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nest\nattributes to parse nlattr defined in dcbnl_pfc_up_attrs. But the\nfollowing access code fetch each nlattr as dcbnl_bcn_attrs attributes.\nBy looking up the associated nla_policy for dcbnl_bcn_attrs. We can find\nthe beginning part of these two policies are \u0026quot;same\u0026quot;.\n\nstatic const struct nla_policy dcbnl_pfc_up_nest[...] = {\n [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8},\n [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},\n};\n\nstatic const struct nla_policy dcbnl_bcn_nest[...] = {\n [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8},\n [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG},\n // from here is somewhat different\n [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32},\n ...\n [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG},\n};\n\nTherefore, the current code is buggy and this\nnla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and use\nthe adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.\n\nHence use the correct policy dcbnl_bcn_nest to parse the nested\ntb[DCB_ATTR_BCN] TLV.(CVE-2023-53369)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: avoid possible NULL skb pointer dereference\n\nIn \u0026apos;mwifiex_handle_uap_rx_forward()\u0026apos;, always check the value\nreturned by \u0026apos;skb_copy()\u0026apos; to avoid potential NULL pointer\ndereference in \u0026apos;mwifiex_uap_queue_bridged_pkt()\u0026apos;, and drop\noriginal skb in case of copying failure.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53384)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer\n\nACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5\n\nAccording to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.\n\nWhen ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.\n\n=============================================================\nUBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type \u0026apos;union acpi_operand_object *[9]\u0026apos;\nCPU: 37 PID: 1678 Comm: cat Not tainted\n6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k\nHW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:\n dump_backtrace+0xe0/0x130\n show_stack+0x20/0x60\n dump_stack_lvl+0x68/0x84\n dump_stack+0x18/0x34\n ubsan_epilogue+0x10/0x50\n __ubsan_handle_out_of_bounds+0x80/0x90\n acpi_ds_exec_end_op+0x1bc/0x6d8\n acpi_ps_parse_loop+0x57c/0x618\n acpi_ps_parse_aml+0x1e0/0x4b4\n acpi_ps_execute_method+0x24c/0x2b8\n acpi_ns_evaluate+0x3a8/0x4bc\n acpi_evaluate_object+0x15c/0x37c\n acpi_evaluate_integer+0x54/0x15c\n show_power+0x8c/0x12c [acpi_power_meter](CVE-2023-53395)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/MCE: Always save CS register on AMD Zen IF Poison errors\n\nThe Instruction Fetch (IF) units on current AMD Zen-based systems do not\nguarantee a synchronous #MC is delivered for poison consumption errors.\nTherefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the\nmicroarchitecture does guarantee that the exception is delivered within\nthe same context. In other words, the exact rIP is not known, but the\ncontext is known to not have changed.\n\nThere is no architecturally-defined method to determine this behavior.\n\nThe Code Segment (CS) register is always valid on such IF unit poison\nerrors regardless of the value of MCG_STATUS[EIPV|RIPV].\n\nAdd a quirk to save the CS register for poison consumption from the IF\nunit banks.\n\nThis is needed to properly determine the context of the error.\nOtherwise, the severity grading function will assume the context is\nIN_KERNEL due to the m-\u0026gt;cs value being 0 (the initialized value). This\nleads to unnecessary kernel panics on data poison errors due to the\nkernel believing the poison consumption occurred in kernel context.(CVE-2023-53438)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ravb: Fix missing rtnl lock in suspend/resume path\n\nFix the suspend/resume path by ensuring the rtnl lock is held where\nrequired. Calls to ravb_open, ravb_close and wol operations must be\nperformed under the rtnl lock to prevent conflicts with ongoing ndo\noperations.\n\nWithout this fix, the following warning is triggered:\n[ 39.032969] =============================\n[ 39.032983] WARNING: suspicious RCU usage\n[ 39.033019] -----------------------------\n[ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious\nrcu_dereference_protected() usage!\n...\n[ 39.033597] stack backtrace:\n[ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted\n6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7\n[ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on\nr9a08g045s33 (DT)\n[ 39.033628] Call trace:\n[ 39.033633] show_stack+0x14/0x1c (C)\n[ 39.033652] dump_stack_lvl+0xb4/0xc4\n[ 39.033664] dump_stack+0x14/0x1c\n[ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c\n[ 39.033682] phy_detach+0x160/0x190\n[ 39.033694] phy_disconnect+0x40/0x54\n[ 39.033703] ravb_close+0x6c/0x1cc\n[ 39.033714] ravb_suspend+0x48/0x120\n[ 39.033721] dpm_run_callback+0x4c/0x14c\n[ 39.033731] device_suspend+0x11c/0x4dc\n[ 39.033740] dpm_suspend+0xdc/0x214\n[ 39.033748] dpm_suspend_start+0x48/0x60\n[ 39.033758] suspend_devices_and_enter+0x124/0x574\n[ 39.033769] pm_suspend+0x1ac/0x274\n[ 39.033778] state_store+0x88/0x124\n[ 39.033788] kobj_attr_store+0x14/0x24\n[ 39.033798] sysfs_kf_write+0x48/0x6c\n[ 39.033808] kernfs_fop_write_iter+0x118/0x1a8\n[ 39.033817] vfs_write+0x27c/0x378\n[ 39.033825] ksys_write+0x64/0xf4\n[ 39.033833] __arm64_sys_write+0x18/0x20\n[ 39.033841] invoke_syscall+0x44/0x104\n[ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4\n[ 39.033862] do_el0_svc+0x18/0x20\n[ 39.033870] el0_svc+0x3c/0xf0\n[ 39.033880] el0t_64_sync_handler+0xc0/0xc4\n[ 39.033888] el0t_64_sync+0x154/0x158\n[ 39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspufs: fix a leak on spufs_new_file() failure\n\nIt\u0026apos;s called from spufs_fill_dir(), and caller of that will do\nspufs_rmdir() in case of failure. That does remove everything\nwe\u0026apos;d managed to create, but... the problem dentry is still\nnegative. IOW, it needs to be explicitly dropped.(CVE-2025-22073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: fix double-free on mc_dev\n\nThe blamed commit tried to simplify how the deallocations are done but,\nin the process, introduced a double-free on the mc_dev variable.\n\nIn case the MC device is a DPRC, a new mc_bus is allocated and the\nmc_dev variable is just a reference to one of its fields. In this\ncircumstance, on the error path only the mc_bus should be freed.\n\nThis commit introduces back the following checkpatch warning which is a\nfalse-positive.\n\nWARNING: kfree(NULL) is safe and this check is probably not required\n+ if (mc_bus)\n+ kfree(mc_bus);(CVE-2025-38313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: cancle set bad inode after removing name fails\n\nThe reproducer uses a file0 on a ntfs3 file system with a corrupted i_link.\nWhen renaming, the file0\u0026apos;s inode is marked as a bad inode because the file\nname cannot be deleted.\n\nThe underlying bug is that make_bad_inode() is called on a live inode.\nIn some cases it\u0026apos;s \u0026quot;icache lookup finds a normal inode, d_splice_alias()\nis called to attach it to dentry, while another thread decides to call\nmake_bad_inode() on it - that would evict it from icache, but we\u0026apos;d already\nfound it there earlier\u0026quot;.\nIn some it\u0026apos;s outright \u0026quot;we have an inode attached to dentry - that\u0026apos;s how we\ngot it in the first place; let\u0026apos;s call make_bad_inode() on it just for shits\nand giggles\u0026quot;.(CVE-2025-38615)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntee: fix NULL pointer dereference in tee_shm_put\n\ntee_shm_put have NULL pointer dereference:\n\n__optee_disable_shm_cache --\u0026gt;\n\tshm = reg_pair_to_ptr(...);//shm maybe return NULL\n tee_shm_free(shm); --\u0026gt;\n\t\ttee_shm_put(shm);//crash\n\nAdd check in tee_shm_put to fix it.\n\npanic log:\nUnable to handle kernel paging request at virtual address 0000000000100cca\nMem abort info:\nESR = 0x0000000096000004\nEC = 0x25: DABT (current EL), IL = 32 bits\nSET = 0, FnV = 0\nEA = 0, S1PTW = 0\nFSC = 0x04: level 0 translation fault\nData abort info:\nISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\nCM = 0, WnR = 0, TnD = 0, TagAccess = 0\nGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000\n[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] SMP\nCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----\n6.6.0-39-generic #38\nSource Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07\nHardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0\n10/26/2022\npstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : tee_shm_put+0x24/0x188\nlr : tee_shm_free+0x14/0x28\nsp : ffff001f98f9faf0\nx29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000\nx26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048\nx23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88\nx20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff\nx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003\nx14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101\nx11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c\nx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca\nCall trace:\ntee_shm_put+0x24/0x188\ntee_shm_free+0x14/0x28\n__optee_disable_shm_cache+0xa8/0x108\noptee_shutdown+0x28/0x38\nplatform_shutdown+0x28/0x40\ndevice_shutdown+0x144/0x2b0\nkernel_power_off+0x3c/0x80\nhibernate+0x35c/0x388\nstate_store+0x64/0x80\nkobj_attr_store+0x14/0x28\nsysfs_kf_write+0x48/0x60\nkernfs_fop_write_iter+0x128/0x1c0\nvfs_write+0x270/0x370\nksys_write+0x6c/0x100\n__arm64_sys_write+0x20/0x30\ninvoke_syscall+0x4c/0x120\nel0_svc_common.constprop.0+0x44/0xf0\ndo_el0_svc+0x24/0x38\nel0_svc+0x24/0x88\nel0t_64_sync_handler+0x134/0x150\nel0t_64_sync+0x14c/0x15(CVE-2025-39865)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the __mark_inode_dirty() function. The issue occurs when __mark_inode_dirty() obtains a bdi_writeback that is in the process of switching. This is a race condition vulnerability between inode_switch_wbs_work_fn() and ___mark_inode_dirty(), causing the old writeback structure to be accessed after it has been released, triggering a use-after-free vulnerability.(CVE-2025-39866)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory\n\nWhen I did memory failure tests, below panic occurs:\n\npage dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))\nkernel BUG at include/linux/page-flags.h:616!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n unpoison_memory+0x2f3/0x590\n simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110\n debugfs_attr_write+0x42/0x60\n full_proxy_write+0x5b/0x80\n vfs_write+0xd5/0x540\n ksys_write+0x64/0xe0\n do_syscall_64+0xb9/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f08f0314887\nRSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887\nRDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001\nRBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009\nR13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00\n \u0026lt;/TASK\u0026gt;\nModules linked in: hwpoison_inject\n---[ end trace 0000000000000000 ]---\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nThe root cause is that unpoison_memory() tries to check the PG_HWPoison\nflags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is\ntriggered. This can be reproduced by below steps:\n\n1.Offline memory block:\n\n echo offline \u0026gt; /sys/devices/system/memory/memory12/state\n\n2.Get offlined memory pfn:\n\n page-types -b n -rlN\n\n3.Write pfn to unpoison-pfn\n\n echo \u0026lt;pfn\u0026gt; \u0026gt; /sys/kernel/debug/hwpoison/unpoison-pfn\n\nThis scenario can be identified by pfn_to_online_page() returning NULL. \nAnd ZONE_DEVICE pages are never expected, so we can simply fail if\npfn_to_online_page() == NULL to fix the bug.(CVE-2025-39883)",
"id": "OESA-2025-2407",
"modified": "2026-08-06T11:09:29Z",
"published": "2025-10-11T11:09:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2407"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49234"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50404"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53165"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53275"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53286"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53331"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53369"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53384"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53395"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53438"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38615"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39866"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49234",
"CVE-2022-50350",
"CVE-2022-50404",
"CVE-2023-53165",
"CVE-2023-53241",
"CVE-2023-53259",
"CVE-2023-53275",
"CVE-2023-53286",
"CVE-2023-53331",
"CVE-2023-53369",
"CVE-2023-53384",
"CVE-2023-53395",
"CVE-2023-53438",
"CVE-2025-21801",
"CVE-2025-22073",
"CVE-2025-38086",
"CVE-2025-38313",
"CVE-2025-38615",
"CVE-2025-39752",
"CVE-2025-39865",
"CVE-2025-39866",
"CVE-2025-39883"
]
}
oesa-2025-2408
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
net: dsa: Avoid cross-chip syncing of VLAN filtering
Changes to VLAN filtering are not applicable to cross-chip notifications.
On a system like this:
.-----. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-' '-1-2-' '-1-2-'
Before this change, upon sw1p1 leaving a bridge, a call to dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.
In this scenario:
.---------. .-----. .-----. | sw1 +---+ sw2 +---+ sw3 | '-1-2-3-4-' '-1-2-' '-1-2-'
When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be called for sw2 and sw3 with a non-existing port - leading to array out-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)
In the Linux kernel, the following vulnerability has been resolved:
scsi: target: iscsi: Fix a race condition between login_work and the login thread
In case a malicious initiator sends some random data immediately after a login PDU; the iscsi_target_sk_data_ready() callback will schedule the login_work and, at the same time, the negotiation may end without clearing the LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are required to complete the login).
The login has been completed but the login_work function will find the LOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling itself; at this point, if the initiator drops the connection, the iscsit_conn structure will be freed, login_work will dereference a released socket structure and the kernel crashes.
BUG: kernel NULL pointer dereference, address: 0000000000000230 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod] RIP: 0010:_raw_read_lock_bh+0x15/0x30 Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0
Fix this bug by forcing login_work to stop after the login has been completed and the socket callbacks have been restored.
Add a comment to clearify the return values of iscsi_target_do_login()(CVE-2022-50350)
In the Linux kernel, the following vulnerability has been resolved:
fbdev: fbcon: release buffer when fbcon_do_set_font() failed
syzbot is reporting memory leak at fbcon_do_set_font() [1], for commit a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize() failed") missed that the buffer might be newly allocated by fbcon_set_font().(CVE-2022-50404)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: call op_release, even when op_func returns an error
For ops with "trivial" replies, nfsd4_encode_operation will shortcut most of the encoding work and skip to just marshalling up the status. One of the things it skips is calling op_release. This could cause a memory leak in the layoutget codepath if there is an error at an inopportune time.
Have the compound processing engine always call op_release, even when op_func sets an error in op->status. With this change, we also need nfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL on error to avoid a double free.(CVE-2023-53241)
In the Linux kernel, the following vulnerability has been resolved:
VMCI: check context->notify_page after call to get_user_pages_fast() to avoid GPF
The call to get_user_pages_fast() in vmci_host_setup_notify() can return NULL context->notify_page causing a GPF. To avoid GPF check if context->notify_page == NULL and return error if so.
general protection fault, probably for non-canonical address 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0x0005088000000300- 0x0005088000000307] CPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014 RIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0 Call Trace: <TASK> vmci_host_unlocked_ioctl+0x362/0x1f40 __x64_sys_ioctl+0x1a1/0x230 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-53259)
In the Linux kernel, the following vulnerability has been resolved:
x86/MCE: Always save CS register on AMD Zen IF Poison errors
The Instruction Fetch (IF) units on current AMD Zen-based systems do not guarantee a synchronous #MC is delivered for poison consumption errors. Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the microarchitecture does guarantee that the exception is delivered within the same context. In other words, the exact rIP is not known, but the context is known to not have changed.
There is no architecturally-defined method to determine this behavior.
The Code Segment (CS) register is always valid on such IF unit poison errors regardless of the value of MCG_STATUS[EIPV|RIPV].
Add a quirk to save the CS register for poison consumption from the IF unit banks.
This is needed to properly determine the context of the error. Otherwise, the severity grading function will assume the context is IN_KERNEL due to the m->cs value being 0 (the initialized value). This leads to unnecessary kernel panics on data poison errors due to the kernel believing the poison consumption occurred in kernel context.(CVE-2023-53438)
In the Linux kernel, the following vulnerability has been resolved:
net: ravb: Fix missing rtnl lock in suspend/resume path
Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations.
Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] show_stack+0x14/0x1c (C) [ 39.033652] dump_stack_lvl+0xb4/0xc4 [ 39.033664] dump_stack+0x14/0x1c [ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c [ 39.033682] phy_detach+0x160/0x190 [ 39.033694] phy_disconnect+0x40/0x54 [ 39.033703] ravb_close+0x6c/0x1cc [ 39.033714] ravb_suspend+0x48/0x120 [ 39.033721] dpm_run_callback+0x4c/0x14c [ 39.033731] device_suspend+0x11c/0x4dc [ 39.033740] dpm_suspend+0xdc/0x214 [ 39.033748] dpm_suspend_start+0x48/0x60 [ 39.033758] suspend_devices_and_enter+0x124/0x574 [ 39.033769] pm_suspend+0x1ac/0x274 [ 39.033778] state_store+0x88/0x124 [ 39.033788] kobj_attr_store+0x14/0x24 [ 39.033798] sysfs_kf_write+0x48/0x6c [ 39.033808] kernfs_fop_write_iter+0x118/0x1a8 [ 39.033817] vfs_write+0x27c/0x378 [ 39.033825] ksys_write+0x64/0xf4 [ 39.033833] __arm64_sys_write+0x18/0x20 [ 39.033841] invoke_syscall+0x44/0x104 [ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4 [ 39.033862] do_el0_svc+0x18/0x20 [ 39.033870] el0_svc+0x3c/0xf0 [ 39.033880] el0t_64_sync_handler+0xc0/0xc4 [ 39.033888] el0t_64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)
In the Linux kernel, the following vulnerability has been resolved:
spufs: fix a leak on spufs_new_file() failure
It's called from spufs_fill_dir(), and caller of that will do spufs_rmdir() in case of failure. That does remove everything we'd managed to create, but... the problem dentry is still negative. IOW, it needs to be explicitly dropped.(CVE-2025-22073)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
bus: fsl-mc: fix double-free on mc_dev
The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable.
In case the MC device is a DPRC, a new mc_bus is allocated and the mc_dev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed.
This commit introduces back the following checkpatch warning which is a false-positive.
WARNING: kfree(NULL) is safe and this check is probably not required + if (mc_bus) + kfree(mc_bus);(CVE-2025-38313)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: cancle set bad inode after removing name fails
The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted.
The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles".(CVE-2025-38615)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
tee: fix NULL pointer dereference in tee_shm_put
tee_shm_put have NULL pointer dereference:
__optee_disable_shm_cache --> shm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> tee_shm_put(shm);//crash
Add check in tee_shm_put to fix it.
panic log: Unable to handle kernel paging request at virtual address 0000000000100cca Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000 [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ---- 6.6.0-39-generic #38 Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07 Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0 10/26/2022 pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : tee_shm_put+0x24/0x188 lr : tee_shm_free+0x14/0x28 sp : ffff001f98f9faf0 x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000 x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048 x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88 x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003 x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101 x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca Call trace: tee_shm_put+0x24/0x188 tee_shm_free+0x14/0x28 __optee_disable_shm_cache+0xa8/0x108 optee_shutdown+0x28/0x38 platform_shutdown+0x28/0x40 device_shutdown+0x144/0x2b0 kernel_power_off+0x3c/0x80 hibernate+0x35c/0x388 state_store+0x64/0x80 kobj_attr_store+0x14/0x28 sysfs_kf_write+0x48/0x60 kernfs_fop_write_iter+0x128/0x1c0 vfs_write+0x270/0x370 ksys_write+0x6c/0x100 __arm64_sys_write+0x20/0x30 invoke_syscall+0x4c/0x120 el0_svc_common.constprop.0+0x44/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x24/0x88 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x14c/0x15(CVE-2025-39865)
In the Linux kernel, a use-after-free vulnerability exists in the __mark_inode_dirty() function. The issue occurs when __mark_inode_dirty() obtains a bdi_writeback that is in the process of switching. This is a race condition vulnerability between inode_switch_wbs_work_fn() and ___mark_inode_dirty(), causing the old writeback structure to be accessed after it has been released, triggering a use-after-free vulnerability.(CVE-2025-39866)
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory
When I did memory failure tests, below panic occurs:
page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page)) kernel BUG at include/linux/page-flags.h:616! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40 RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Call Trace: <TASK> unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08f0314887 RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887 RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001 RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009 R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 </TASK> Modules linked in: hwpoison_inject ---[ end trace 0000000000000000 ]--- RIP: 0010:unpoison_memory+0x2f3/0x590 RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246 RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8 RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0 RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb R10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000 R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe FS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0 Kernel panic - not syncing: Fatal exception Kernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]---
The root cause is that unpoison_memory() tries to check the PG_HWPoison flags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is triggered. This can be reproduced by below steps:
1.Offline memory block:
echo offline > /sys/devices/system/memory/memory12/state
2.Get offlined memory pfn:
page-types -b n -rlN
3.Write pfn to unpoison-pfn
echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn
This scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail if pfn_to_online_page() == NULL to fix the bug.(CVE-2025-39883)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"perf-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-284.0.0.187.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-284.0.0.187.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"perf-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-284.0.0.187.oe2203sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-284.0.0.187.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: Avoid cross-chip syncing of VLAN filtering\n\nChanges to VLAN filtering are not applicable to cross-chip\nnotifications.\n\nOn a system like this:\n\n.-----. .-----. .-----.\n| sw1 +---+ sw2 +---+ sw3 |\n\u0026apos;-1-2-\u0026apos; \u0026apos;-1-2-\u0026apos; \u0026apos;-1-2-\u0026apos;\n\nBefore this change, upon sw1p1 leaving a bridge, a call to\ndsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.\n\nIn this scenario:\n\n.---------. .-----. .-----.\n| sw1 +---+ sw2 +---+ sw3 |\n\u0026apos;-1-2-3-4-\u0026apos; \u0026apos;-1-2-\u0026apos; \u0026apos;-1-2-\u0026apos;\n\nWhen sw1p4 would leave a bridge, dsa_port_vlan_filtering would be\ncalled for sw2 and sw3 with a non-existing port - leading to array\nout-of-bounds accesses and crashes on mv88e6xxx.(CVE-2022-49234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix a race condition between login_work and the login thread\n\nIn case a malicious initiator sends some random data immediately after a\nlogin PDU; the iscsi_target_sk_data_ready() callback will schedule the\nlogin_work and, at the same time, the negotiation may end without clearing\nthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges are\nrequired to complete the login).\n\nThe login has been completed but the login_work function will find the\nLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from rescheduling\nitself; at this point, if the initiator drops the connection, the\niscsit_conn structure will be freed, login_work will dereference a released\nsocket structure and the kernel crashes.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000230\nPF: supervisor write access in kernel mode\nPF: error_code(0x0002) - not-present page\nWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]\nRIP: 0010:_raw_read_lock_bh+0x15/0x30\nCall trace:\n iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod]\n process_one_work+0x1e8/0x3c0\n\nFix this bug by forcing login_work to stop after the login has been\ncompleted and the socket callbacks have been restored.\n\nAdd a comment to clearify the return values of iscsi_target_do_login()(CVE-2022-50350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: fbcon: release buffer when fbcon_do_set_font() failed\n\nsyzbot is reporting memory leak at fbcon_do_set_font() [1], for\ncommit a5a923038d70 (\u0026quot;fbdev: fbcon: Properly revert changes when\nvc_resize() failed\u0026quot;) missed that the buffer might be newly allocated\nby fbcon_set_font().(CVE-2022-50404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: call op_release, even when op_func returns an error\n\nFor ops with \u0026quot;trivial\u0026quot; replies, nfsd4_encode_operation will shortcut\nmost of the encoding work and skip to just marshalling up the status.\nOne of the things it skips is calling op_release. This could cause a\nmemory leak in the layoutget codepath if there is an error at an\ninopportune time.\n\nHave the compound processing engine always call op_release, even when\nop_func sets an error in op-\u0026gt;status. With this change, we also need\nnfsd4_block_get_device_info_scsi to set the gd_device pointer to NULL\non error to avoid a double free.(CVE-2023-53241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nVMCI: check context-\u0026gt;notify_page after call to get_user_pages_fast() to avoid GPF\n\nThe call to get_user_pages_fast() in vmci_host_setup_notify() can return\nNULL context-\u0026gt;notify_page causing a GPF. To avoid GPF check if\ncontext-\u0026gt;notify_page == NULL and return error if so.\n\ngeneral protection fault, probably for non-canonical address\n 0xe0009d1000000060: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: maybe wild-memory-access in range [0x0005088000000300-\n 0x0005088000000307]\nCPU: 2 PID: 26180 Comm: repro_34802241 Not tainted 6.1.0-rc4 #1\nHardware name: Red Hat KVM, BIOS 1.15.0-2.module+el8.6.0 04/01/2014\nRIP: 0010:vmci_ctx_check_signal_notify+0x91/0xe0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vmci_host_unlocked_ioctl+0x362/0x1f40\n __x64_sys_ioctl+0x1a1/0x230\n do_syscall_64+0x3a/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-53259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/MCE: Always save CS register on AMD Zen IF Poison errors\n\nThe Instruction Fetch (IF) units on current AMD Zen-based systems do not\nguarantee a synchronous #MC is delivered for poison consumption errors.\nTherefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the\nmicroarchitecture does guarantee that the exception is delivered within\nthe same context. In other words, the exact rIP is not known, but the\ncontext is known to not have changed.\n\nThere is no architecturally-defined method to determine this behavior.\n\nThe Code Segment (CS) register is always valid on such IF unit poison\nerrors regardless of the value of MCG_STATUS[EIPV|RIPV].\n\nAdd a quirk to save the CS register for poison consumption from the IF\nunit banks.\n\nThis is needed to properly determine the context of the error.\nOtherwise, the severity grading function will assume the context is\nIN_KERNEL due to the m-\u0026gt;cs value being 0 (the initialized value). This\nleads to unnecessary kernel panics on data poison errors due to the\nkernel believing the poison consumption occurred in kernel context.(CVE-2023-53438)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ravb: Fix missing rtnl lock in suspend/resume path\n\nFix the suspend/resume path by ensuring the rtnl lock is held where\nrequired. Calls to ravb_open, ravb_close and wol operations must be\nperformed under the rtnl lock to prevent conflicts with ongoing ndo\noperations.\n\nWithout this fix, the following warning is triggered:\n[ 39.032969] =============================\n[ 39.032983] WARNING: suspicious RCU usage\n[ 39.033019] -----------------------------\n[ 39.033033] drivers/net/phy/phy_device.c:2004 suspicious\nrcu_dereference_protected() usage!\n...\n[ 39.033597] stack backtrace:\n[ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted\n6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7\n[ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on\nr9a08g045s33 (DT)\n[ 39.033628] Call trace:\n[ 39.033633] show_stack+0x14/0x1c (C)\n[ 39.033652] dump_stack_lvl+0xb4/0xc4\n[ 39.033664] dump_stack+0x14/0x1c\n[ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c\n[ 39.033682] phy_detach+0x160/0x190\n[ 39.033694] phy_disconnect+0x40/0x54\n[ 39.033703] ravb_close+0x6c/0x1cc\n[ 39.033714] ravb_suspend+0x48/0x120\n[ 39.033721] dpm_run_callback+0x4c/0x14c\n[ 39.033731] device_suspend+0x11c/0x4dc\n[ 39.033740] dpm_suspend+0xdc/0x214\n[ 39.033748] dpm_suspend_start+0x48/0x60\n[ 39.033758] suspend_devices_and_enter+0x124/0x574\n[ 39.033769] pm_suspend+0x1ac/0x274\n[ 39.033778] state_store+0x88/0x124\n[ 39.033788] kobj_attr_store+0x14/0x24\n[ 39.033798] sysfs_kf_write+0x48/0x6c\n[ 39.033808] kernfs_fop_write_iter+0x118/0x1a8\n[ 39.033817] vfs_write+0x27c/0x378\n[ 39.033825] ksys_write+0x64/0xf4\n[ 39.033833] __arm64_sys_write+0x18/0x20\n[ 39.033841] invoke_syscall+0x44/0x104\n[ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4\n[ 39.033862] do_el0_svc+0x18/0x20\n[ 39.033870] el0_svc+0x3c/0xf0\n[ 39.033880] el0t_64_sync_handler+0xc0/0xc4\n[ 39.033888] el0t_64_sync+0x154/0x158\n[ 39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspufs: fix a leak on spufs_new_file() failure\n\nIt\u0026apos;s called from spufs_fill_dir(), and caller of that will do\nspufs_rmdir() in case of failure. That does remove everything\nwe\u0026apos;d managed to create, but... the problem dentry is still\nnegative. IOW, it needs to be explicitly dropped.(CVE-2025-22073)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: fix double-free on mc_dev\n\nThe blamed commit tried to simplify how the deallocations are done but,\nin the process, introduced a double-free on the mc_dev variable.\n\nIn case the MC device is a DPRC, a new mc_bus is allocated and the\nmc_dev variable is just a reference to one of its fields. In this\ncircumstance, on the error path only the mc_bus should be freed.\n\nThis commit introduces back the following checkpatch warning which is a\nfalse-positive.\n\nWARNING: kfree(NULL) is safe and this check is probably not required\n+ if (mc_bus)\n+ kfree(mc_bus);(CVE-2025-38313)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: cancle set bad inode after removing name fails\n\nThe reproducer uses a file0 on a ntfs3 file system with a corrupted i_link.\nWhen renaming, the file0\u0026apos;s inode is marked as a bad inode because the file\nname cannot be deleted.\n\nThe underlying bug is that make_bad_inode() is called on a live inode.\nIn some cases it\u0026apos;s \u0026quot;icache lookup finds a normal inode, d_splice_alias()\nis called to attach it to dentry, while another thread decides to call\nmake_bad_inode() on it - that would evict it from icache, but we\u0026apos;d already\nfound it there earlier\u0026quot;.\nIn some it\u0026apos;s outright \u0026quot;we have an inode attached to dentry - that\u0026apos;s how we\ngot it in the first place; let\u0026apos;s call make_bad_inode() on it just for shits\nand giggles\u0026quot;.(CVE-2025-38615)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntee: fix NULL pointer dereference in tee_shm_put\n\ntee_shm_put have NULL pointer dereference:\n\n__optee_disable_shm_cache --\u0026gt;\n\tshm = reg_pair_to_ptr(...);//shm maybe return NULL\n tee_shm_free(shm); --\u0026gt;\n\t\ttee_shm_put(shm);//crash\n\nAdd check in tee_shm_put to fix it.\n\npanic log:\nUnable to handle kernel paging request at virtual address 0000000000100cca\nMem abort info:\nESR = 0x0000000096000004\nEC = 0x25: DABT (current EL), IL = 32 bits\nSET = 0, FnV = 0\nEA = 0, S1PTW = 0\nFSC = 0x04: level 0 translation fault\nData abort info:\nISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\nCM = 0, WnR = 0, TnD = 0, TagAccess = 0\nGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000\n[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] SMP\nCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----\n6.6.0-39-generic #38\nSource Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07\nHardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0\n10/26/2022\npstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : tee_shm_put+0x24/0x188\nlr : tee_shm_free+0x14/0x28\nsp : ffff001f98f9faf0\nx29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000\nx26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048\nx23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88\nx20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff\nx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003\nx14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101\nx11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c\nx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca\nCall trace:\ntee_shm_put+0x24/0x188\ntee_shm_free+0x14/0x28\n__optee_disable_shm_cache+0xa8/0x108\noptee_shutdown+0x28/0x38\nplatform_shutdown+0x28/0x40\ndevice_shutdown+0x144/0x2b0\nkernel_power_off+0x3c/0x80\nhibernate+0x35c/0x388\nstate_store+0x64/0x80\nkobj_attr_store+0x14/0x28\nsysfs_kf_write+0x48/0x60\nkernfs_fop_write_iter+0x128/0x1c0\nvfs_write+0x270/0x370\nksys_write+0x6c/0x100\n__arm64_sys_write+0x20/0x30\ninvoke_syscall+0x4c/0x120\nel0_svc_common.constprop.0+0x44/0xf0\ndo_el0_svc+0x24/0x38\nel0_svc+0x24/0x88\nel0t_64_sync_handler+0x134/0x150\nel0t_64_sync+0x14c/0x15(CVE-2025-39865)\n\nIn the Linux kernel, a use-after-free vulnerability exists in the __mark_inode_dirty() function. The issue occurs when __mark_inode_dirty() obtains a bdi_writeback that is in the process of switching. This is a race condition vulnerability between inode_switch_wbs_work_fn() and ___mark_inode_dirty(), causing the old writeback structure to be accessed after it has been released, triggering a use-after-free vulnerability.(CVE-2025-39866)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory\n\nWhen I did memory failure tests, below panic occurs:\n\npage dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))\nkernel BUG at include/linux/page-flags.h:616!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n unpoison_memory+0x2f3/0x590\n simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110\n debugfs_attr_write+0x42/0x60\n full_proxy_write+0x5b/0x80\n vfs_write+0xd5/0x540\n ksys_write+0x64/0xe0\n do_syscall_64+0xb9/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f08f0314887\nRSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887\nRDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001\nRBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009\nR13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00\n \u0026lt;/TASK\u0026gt;\nModules linked in: hwpoison_inject\n---[ end trace 0000000000000000 ]---\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nThe root cause is that unpoison_memory() tries to check the PG_HWPoison\nflags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) is\ntriggered. This can be reproduced by below steps:\n\n1.Offline memory block:\n\n echo offline \u0026gt; /sys/devices/system/memory/memory12/state\n\n2.Get offlined memory pfn:\n\n page-types -b n -rlN\n\n3.Write pfn to unpoison-pfn\n\n echo \u0026lt;pfn\u0026gt; \u0026gt; /sys/kernel/debug/hwpoison/unpoison-pfn\n\nThis scenario can be identified by pfn_to_online_page() returning NULL. \nAnd ZONE_DEVICE pages are never expected, so we can simply fail if\npfn_to_online_page() == NULL to fix the bug.(CVE-2025-39883)",
"id": "OESA-2025-2408",
"modified": "2026-08-06T11:09:29Z",
"published": "2025-10-11T11:09:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2408"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49234"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50404"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53241"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53259"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53438"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22073"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38313"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38615"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39866"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49234",
"CVE-2022-50350",
"CVE-2022-50404",
"CVE-2023-53241",
"CVE-2023-53259",
"CVE-2023-53438",
"CVE-2025-21801",
"CVE-2025-22073",
"CVE-2025-38086",
"CVE-2025-38313",
"CVE-2025-38615",
"CVE-2025-39752",
"CVE-2025-39865",
"CVE-2025-39866",
"CVE-2025-39883"
]
}
oesa-2025-2465
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Use disable_delayed_work_sync
This makes use of disable_delayed_work_sync instead cancel_delayed_work_sync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.(CVE-2024-56591)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails.
Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.
Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path.
Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.(CVE-2025-22005)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a couple integer overflows on 32bit systems
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---(CVE-2025-37741)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.(CVE-2025-38319)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Limit access to parser->buffer when trace_get_user failed
When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:
BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165
CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0
The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise gateway LWS calls to probe user read access
We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER).
Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.(CVE-2025-39715)
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-qcom: Add SM6115 MDSS compatible
Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot:
arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed)
------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] ERROR could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the fields in the descriptor.(CVE-2025-39760)
In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in smb2_compound_op.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to cfile should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
cfile, except the patched one.
3. Existing callers would not handle refcount update of cfile if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of vars, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
is_replayable_error, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.(CVE-2025-39819)
A use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)
In the Linux kernel, the following vulnerability has been resolved:
mm: move page table sync declarations to linux/pgtable.h
During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:
BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK>
It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks.
And looking at __populate_section_memmap():
if (vmemmap_can_optimize(altmap, pgmap))
// does not sync top level page tables
r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
else
// sync top level page tables in x86
r = vmemmap_populate(start, end, nid, altmap);
In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.
However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.
We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.
It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.
The solution: Make page table sync more code robust and harder to miss
To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.
The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables.
pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t pgd, p4d_t p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); }
It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---(CVE-2025-39844)
In the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).
The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].
Fix by checking that the remote destination exists before dereferencing it.
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo
ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy
ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3
[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77
[4] #!/bin/bash
ip address add 2001:db8:1::1/128 dev lo
ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy
ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix potential invalid access when MAC list is empty
list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.
Fix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)
A NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)
A vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()
Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:
... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ...
The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.
We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.
As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.
Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/(CVE-2025-39886)
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix sched_numa_find_nth_cpu() if mask offline
sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.
The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):
[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[ 1.423635] Mem abort info:
[ 1.423889] ESR = 0x0000000096000006
[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.424715] SET = 0, FnV = 0
[ 1.424995] EA = 0, S1PTW = 0
[ 1.425279] FSC = 0x06: level 2 translation fault
[ 1.425735] Data abort info:
[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP
[ 1.429525] Modules linked in:
[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[ 1.432543] sp : ffffffc084e1b960
[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[ 1.439332] Call trace:
[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[ 1.440016] smp_call_function_any+0xc8/0xd0
[ 1.440416] armv8_pmu_init+0x58/0x27c
[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c
[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8
[ 1.441603] armv8_pmu_device_probe+0x1c/0x28
[ 1.442007] platform_probe+0x5c/0xac
[ 1.442347] really_probe+0xbc/0x298
[ 1.442683] __driver_probe_device+0x78/0x12c
[ 1.443087] driver_probe_device+0xdc/0x160
[ 1.443475] __driver_attach+0x94/0x19c
[ 1.443833] bus_for_each_dev+0x74/0xd4
[ 1.444190] driver_attach+0x24/0x30
[ 1.444525] bus_add_driver+0xe4/0x208
[ 1.444874] driver_register+0x60/0x128
[ 1.445233] __platform_driver_register+0x24/0x30
[ 1.445662] armv8_pmu_driver_init+0x28/0x4c
[ 1.446059] do_one_initcall+0x44/0x25c
[ 1.446416] kernel_init_freeable+0x1dc/0x3bc
[ 1.446820] kernel_init+0x20/0x1d8
[ 1.447151] ret_from_fork+0x10/0x20
[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[ 1.448040] ---[ end trace 0000000000000000 ]---
[ 1.448483] note: swapper/0[1] exited with preempt_count 1
[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.449741] SMP: stopping secondary CPUs
[ 1.450105] Kernel Offset: disabled
[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[
---truncated---(CVE-2025-39895)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Silence warning when chunk allocation fails in trace_pid_write
Syzkaller trigger a fault injection warning:
WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning.
The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.(CVE-2025-39914)
In the Linux kernel, the following vulnerability has been resolved:
cgroup: split cgroup_destroy_wq into 3 workqueues
A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.
Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20
Root Cause:
CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die
Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)
Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation
This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.
[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-source-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"perf-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"python3-perf-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-112.0.0.104.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-source-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"perf-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"python3-perf-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.104.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-112.0.0.104.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\nBluetooth: hci_conn: Use disable_delayed_work_sync\n\nThis makes use of disable_delayed_work_sync instead\ncancel_delayed_work_sync as it not only cancel the ongoing work but also\ndisables new submit which is disarable since the object holding the work\nis about to be freed.(CVE-2024-56591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().\n\nfib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything\nwhen it fails.\n\nCommit 7dd73168e273 (\u0026quot;ipv6: Always allocate pcpu memory in a fib6_nh\u0026quot;)\nmoved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()\nbut forgot to add cleanup for fib6_nh-\u0026gt;nh_common.nhc_pcpu_rth_output in\ncase it fails to allocate fib6_nh-\u0026gt;rt6i_pcpu, resulting in memleak.\n\nLet\u0026apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the\nerror path.\n\nNote that we can remove the fib6_nh_release() call in nh_create_ipv6()\nlater in net-next.git.(CVE-2025-22005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix a couple integer overflows on 32bit systems\n\nOn 32bit systems the \u0026quot;off + sizeof(struct NTFS_DE)\u0026quot; addition can\nhave an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling \u0026quot;ioctl$LOOP_SET_STATUS64\u0026quot;, the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---(CVE-2025-37741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table\n\nThe function atomctrl_initialize_mc_reg_table() and\natomctrl_initialize_mc_reg_table_v2_2() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()\nfails to retrieve vram_info, it returns NULL which is later\ndereferenced.(CVE-2025-38319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser-\u0026gt;buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser-\u0026gt;buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release-\u0026gt;\nftrace_process_regex-\u0026gt;strsep-\u0026gt;strpbrk. We can solve this problem by\nlimiting access to parser-\u0026gt;buffer when trace_get_user failed.(CVE-2025-39683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise gateway LWS calls to probe user read access\n\nWe use load and stbys,e instructions to trigger memory reference\ninterruptions without writing to memory. Because of the way read\naccess support is implemented, read access interruptions are only\ntriggered at privilege levels 2 and 3. The kernel and gateway\npage execute at privilege level 0, so this code never triggers\na read access interruption. Thus, it is currently possible for\nuser code to execute a LWS compare and swap operation at an\naddress that is read protected at privilege level 3 (PRIV_USER).\n\nFix this by probing read access rights at privilege level 3 and\nbranching to lws_fault if access isn\u0026apos;t allowed.(CVE-2025-39715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-qcom: Add SM6115 MDSS compatible\n\nAdd the SM6115 MDSS compatible to clients compatible list, as it also\nneeds that workaround.\nWithout this workaround, for example, QRB4210 RB2 which is based on\nSM4250/SM6115 generates a lot of smmu unhandled context faults during\nboot:\n\narm_smmu_context_fault: 116854 callbacks suppressed\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\narm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\n\nand also failed initialisation of lontium lt9611uxc, gpu and dpu is\nobserved:\n(binding MDSS components triggered by lt9611uxc have failed)\n\n ------------[ cut here ]------------\n !aspace\n WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]\n Modules linked in: ... (long list of modules)\n CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT\n Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : msm_gem_vma_init+0x150/0x18c [msm]\n lr : msm_gem_vma_init+0x150/0x18c [msm]\n sp : ffff80008144b280\n \t\t...\n Call trace:\n msm_gem_vma_init+0x150/0x18c [msm] (P)\n get_vma_locked+0xc0/0x194 [msm]\n msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]\n msm_gem_kernel_new+0x48/0x160 [msm]\n msm_gpu_init+0x34c/0x53c [msm]\n adreno_gpu_init+0x1b0/0x2d8 [msm]\n a6xx_gpu_init+0x1e8/0x9e0 [msm]\n adreno_bind+0x2b8/0x348 [msm]\n component_bind_all+0x100/0x230\n msm_drm_bind+0x13c/0x3d0 [msm]\n try_to_bring_up_aggregate_device+0x164/0x1d0\n __component_add+0xa4/0x174\n component_add+0x14/0x20\n dsi_dev_attach+0x20/0x34 [msm]\n dsi_host_attach+0x58/0x98 [msm]\n devm_mipi_dsi_attach+0x34/0x90\n lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]\n lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]\n i2c_device_probe+0x148/0x2a8\n really_probe+0xbc/0x2c0\n __driver_probe_device+0x78/0x120\n driver_probe_device+0x3c/0x154\n __driver_attach+0x90/0x1a0\n bus_for_each_dev+0x68/0xb8\n driver_attach+0x24/0x30\n bus_add_driver+0xe4/0x208\n driver_register+0x68/0x124\n i2c_register_driver+0x48/0xcc\n lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]\n do_one_initcall+0x60/0x1d4\n do_init_module+0x54/0x1fc\n load_module+0x1748/0x1c8c\n init_module_from_file+0x74/0xa0\n __arm64_sys_finit_module+0x130/0x2f8\n invoke_syscall+0x48/0x104\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x2c/0x80\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n ---[ end trace 0000000000000000 ]---\n msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22\n msm_dpu 5e01000.display-controller: failed to load adreno gpu\n platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19\n msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22\n msm_dpu 5e01000.display-controller: adev bind failed: -22\n lt9611uxc 0-002b: failed to attach dsi to host\n lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: config: Prevent OOB read in SS endpoint companion parsing\n\nusb_parse_ss_endpoint_companion() checks descriptor type before length,\nenabling a potentially odd read outside of the buffer size.\n\nFix this up by checking the size first before looking at any of the\nfields in the descriptor.(CVE-2025-39760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb: Fix inconsistent refcnt update\n\nA possible inconsistent update of refcount was identified in `smb2_compound_op`.\nSuch inconsistent update could lead to possible resource leaks.\n\nWhy it is a possible bug:\n1. In the comment section of the function, it clearly states that the\nreference to `cfile` should be dropped after calling this function.\n2. Every control flow path would check and drop the reference to\n`cfile`, except the patched one.\n3. Existing callers would not handle refcount update of `cfile` if\n-ENOMEM is returned.\n\nTo fix the bug, an extra goto label \u0026quot;out\u0026quot; is added, to make sure that the\ncleanup logic would always be respected. As the problem is caused by the\nallocation failure of `vars`, the cleanup logic between label \u0026quot;finished\u0026quot;\nand \u0026quot;out\u0026quot; can be safely ignored. According to the definition of function\n`is_replayable_error`, the error code of \u0026quot;-ENOMEM\u0026quot; is not recoverable.\nTherefore, the replay logic also gets ignored.(CVE-2025-39819)\n\nA use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: move page table sync declarations to linux/pgtable.h\n\nDuring our internal testing, we started observing intermittent boot\nfailures when the machine uses 4-level paging and has a large amount of\npersistent memory:\n\n BUG: unable to handle page fault for address: ffffe70000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0 \n Oops: 0002 [#1] SMP NOPTI\n RIP: 0010:__init_single_page+0x9/0x6d\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __init_zone_device_page+0x17/0x5d\n memmap_init_zone_device+0x154/0x1bb\n pagemap_range+0x2e0/0x40f\n memremap_pages+0x10b/0x2f0\n devm_memremap_pages+0x1e/0x60\n dev_dax_probe+0xce/0x2ec [device_dax]\n dax_bus_probe+0x6d/0xc9\n [... snip ...]\n \u0026lt;/TASK\u0026gt;\n\nIt turns out that the kernel panics while initializing vmemmap (struct\npage array) when the vmemmap region spans two PGD entries, because the new\nPGD entry is only installed in init_mm.pgd, but not in the page tables of\nother tasks.\n\nAnd looking at __populate_section_memmap():\n if (vmemmap_can_optimize(altmap, pgmap)) \n // does not sync top level page tables\n r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);\n else \n // sync top level page tables in x86\n r = vmemmap_populate(start, end, nid, altmap);\n\nIn the normal path, vmemmap_populate() in arch/x86/mm/init_64.c\nsynchronizes the top level page table (See commit 9b861528a801 (\u0026quot;x86-64,\nmem: Update all PGDs for direct mapping and vmemmap mapping changes\u0026quot;)) so\nthat all tasks in the system can see the new vmemmap area.\n\nHowever, when vmemmap_can_optimize() returns true, the optimized path\nskips synchronization of top-level page tables. This is because\nvmemmap_populate_compound_pages() is implemented in core MM code, which\ndoes not handle synchronization of the top-level page tables. Instead,\nthe core MM has historically relied on each architecture to perform this\nsynchronization manually.\n\nWe\u0026apos;re not the first party to encounter a crash caused by not-sync\u0026apos;d top\nlevel page tables: earlier this year, Gwan-gyeong Mun attempted to address\nthe issue [1] [2] after hitting a kernel panic when x86 code accessed the\nvmemmap area before the corresponding top-level entries were synced. At\nthat time, the issue was believed to be triggered only when struct page\nwas enlarged for debugging purposes, and the patch did not get further\nupdates.\n\nIt turns out that current approach of relying on each arch to handle the\npage table sync manually is fragile because 1) it\u0026apos;s easy to forget to sync\nthe top level page table, and 2) it\u0026apos;s also easy to overlook that the\nkernel should not access the vmemmap and direct mapping areas before the\nsync.\n\n# The solution: Make page table sync more code robust and harder to miss\n\nTo address this, Dave Hansen suggested [3] [4] introducing\n{pgd,p4d}_populate_kernel() for updating kernel portion of the page tables\nand allow each architecture to explicitly perform synchronization when\ninstalling top-level entries. With this approach, we no longer need to\nworry about missing the sync step, reducing the risk of future\nregressions.\n\nThe new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,\nPGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by\nvmalloc and ioremap to synchronize page tables.\n\npgd_populate_kernel() looks like this:\nstatic inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,\n p4d_t *p4d)\n{\n pgd_populate(\u0026amp;init_mm, pgd, p4d);\n if (ARCH_PAGE_TABLE_SYNC_MASK \u0026amp; PGTBL_PGD_MODIFIED)\n arch_sync_kernel_mappings(addr, addr);\n}\n\nIt is worth noting that vmalloc() and apply_to_range() carefully\nsynchronizes page tables by calling p*d_alloc_track() and\narch_sync_kernel_mappings(), and thus they are not affected by\n---truncated---(CVE-2025-39844)\n\nIn the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the \u0026quot;proxy\u0026quot; option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the \u0026quot;any\u0026quot; remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor\u0026apos;s MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)\n\nA NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)\n\nA vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()\n\nCurrently, calling bpf_map_kmalloc_node() from __bpf_async_init() can\ncause various locking issues; see the following stack trace (edited for\nstyle) as one example:\n\n...\n [10.011566] do_raw_spin_lock.cold\n [10.011570] try_to_wake_up (5) double-acquiring the same\n [10.011575] kick_pool rq_lock, causing a hardlockup\n [10.011579] __queue_work\n [10.011582] queue_work_on\n [10.011585] kernfs_notify\n [10.011589] cgroup_file_notify\n [10.011593] try_charge_memcg (4) memcg accounting raises an\n [10.011597] obj_cgroup_charge_pages MEMCG_MAX event\n [10.011599] obj_cgroup_charge_account\n [10.011600] __memcg_slab_post_alloc_hook\n [10.011603] __kmalloc_node_noprof\n...\n [10.011611] bpf_map_kmalloc_node\n [10.011612] __bpf_async_init\n [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()\n [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable\n [10.011619] bpf__sched_ext_ops_runnable\n [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held\n [10.011622] enqueue_task\n [10.011626] ttwu_do_activate\n [10.011629] sched_ttwu_pending (1) grabs rq_lock\n...\n\nThe above was reproduced on bpf-next (b338cf849ec8) by modifying\n./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during\nops.runnable(), and hacking the memcg accounting code a bit to make\na bpf_timer_init() call more likely to raise an MEMCG_MAX event.\n\nWe have also run into other similar variants (both internally and on\nbpf-next), including double-acquiring cgroup_file_kn_lock, the same\nworker_pool::lock, etc.\n\nAs suggested by Shakeel, fix this by using __GFP_HIGH instead of\nGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()\nraises an MEMCG_MAX event, we call __memcg_memory_event() with\n@allow_spinning=false and avoid calling cgroup_file_notify() there.\n\nDepends on mm patch\n\u0026quot;memcg: skip cgroup_file_notify if spinning is not allowed\u0026quot;:\nhttps://lore.kernel.org/bpf/(CVE-2025-39886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix sched_numa_find_nth_cpu() if mask offline\n\nsched_numa_find_nth_cpu() uses a bsearch to look for the \u0026apos;closest\u0026apos;\nCPU in sched_domains_numa_masks and given cpus mask. However they\nmight not intersect if all CPUs in the cpus mask are offline. bsearch\nwill return NULL in that case, bail out instead of dereferencing a\nbogus pointer.\n\nThe previous behaviour lead to this bug when using maxcpus=4 on an\nrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):\n\n[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000\n[ 1.423635] Mem abort info:\n[ 1.423889] ESR = 0x0000000096000006\n[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 1.424715] SET = 0, FnV = 0\n[ 1.424995] EA = 0, S1PTW = 0\n[ 1.425279] FSC = 0x06: level 2 translation fault\n[ 1.425735] Data abort info:\n[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000\n[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000\n[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP\n[ 1.429525] Modules linked in:\n[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT\n[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)\n[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488\n[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488\n[ 1.432543] sp : ffffffc084e1b960\n[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0\n[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378\n[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff\n[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7\n[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372\n[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860\n[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000\n[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000\n[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68\n[ 1.439332] Call trace:\n[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)\n[ 1.440016] smp_call_function_any+0xc8/0xd0\n[ 1.440416] armv8_pmu_init+0x58/0x27c\n[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c\n[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8\n[ 1.441603] armv8_pmu_device_probe+0x1c/0x28\n[ 1.442007] platform_probe+0x5c/0xac\n[ 1.442347] really_probe+0xbc/0x298\n[ 1.442683] __driver_probe_device+0x78/0x12c\n[ 1.443087] driver_probe_device+0xdc/0x160\n[ 1.443475] __driver_attach+0x94/0x19c\n[ 1.443833] bus_for_each_dev+0x74/0xd4\n[ 1.444190] driver_attach+0x24/0x30\n[ 1.444525] bus_add_driver+0xe4/0x208\n[ 1.444874] driver_register+0x60/0x128\n[ 1.445233] __platform_driver_register+0x24/0x30\n[ 1.445662] armv8_pmu_driver_init+0x28/0x4c\n[ 1.446059] do_one_initcall+0x44/0x25c\n[ 1.446416] kernel_init_freeable+0x1dc/0x3bc\n[ 1.446820] kernel_init+0x20/0x1d8\n[ 1.447151] ret_from_fork+0x10/0x20\n[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)\n[ 1.448040] ---[ end trace 0000000000000000 ]---\n[ 1.448483] note: swapper/0[1] exited with preempt_count 1\n[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n[ 1.449741] SMP: stopping secondary CPUs\n[ 1.450105] Kernel Offset: disabled\n[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b\n[ \n---truncated---(CVE-2025-39895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Silence warning when chunk allocation fails in trace_pid_write\n\nSyzkaller trigger a fault injection warning:\n\nWARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0\nModules linked in:\nCPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0\nTainted: [U]=USER\nHardware name: Google Compute Engine/Google Compute Engine\nRIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294\nCode: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff\nRSP: 0018:ffffc9000414fb48 EFLAGS: 00010283\nRAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000\nRDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0\nFS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464\n register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]\n register_pid_events kernel/trace/trace_events.c:2354 [inline]\n event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425\n vfs_write+0x24c/0x1150 fs/read_write.c:677\n ksys_write+0x12b/0x250 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe can reproduce the warning by following the steps below:\n1. echo 8 \u0026gt;\u0026gt; set_event_notrace_pid. Let tr-\u0026gt;filtered_pids owns one pid\n and register sched_switch tracepoint.\n2. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid, and perform fault injection during chunk\n allocation of trace_pid_list_alloc. Let pid_list with no pid and\nassign to tr-\u0026gt;filtered_pids.\n3. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid. Let pid_list is NULL and assign to\n tr-\u0026gt;filtered_pids.\n4. echo 9 \u0026gt;\u0026gt; set_event_pid, will trigger the double register\n sched_switch tracepoint warning.\n\nThe reason is that syzkaller injects a fault into the chunk allocation\nin trace_pid_list_alloc, causing a failure in trace_pid_list_set, which\nmay trigger double register of the same tracepoint. This only occurs\nwhen the system is about to crash, but to suppress this warning, let\u0026apos;s\nadd failure handling logic to trace_pid_list_set.(CVE-2025-39914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0 CPU1\nmount perf_event umount net_prio\ncgroup1_get_tree cgroup_kill_sb\nrebind_subsystems // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n // one perf_event css A is dying\n // css A offline enqueues cgroup_destroy_wq\n // root destruction will be executed first\n css_free_rwork_fn\n cgroup_destroy_root\n cgroup_lock_and_drain_offline\n // some perf descendants are dying\n // cgroup_destroy_wq max_active = 1\n // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq \u2013 Handles CSS offline operations\ncgroup_release_wq \u2013 Manages resource release\ncgroup_free_wq \u2013 Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)",
"id": "OESA-2025-2465",
"modified": "2026-08-06T11:09:33Z",
"published": "2025-10-17T11:09:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2465"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39953"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56591",
"CVE-2025-22005",
"CVE-2025-22081",
"CVE-2025-37741",
"CVE-2025-38086",
"CVE-2025-38319",
"CVE-2025-39683",
"CVE-2025-39715",
"CVE-2025-39739",
"CVE-2025-39752",
"CVE-2025-39760",
"CVE-2025-39819",
"CVE-2025-39824",
"CVE-2025-39844",
"CVE-2025-39845",
"CVE-2025-39850",
"CVE-2025-39851",
"CVE-2025-39853",
"CVE-2025-39865",
"CVE-2025-39883",
"CVE-2025-39886",
"CVE-2025-39895",
"CVE-2025-39914",
"CVE-2025-39953"
]
}
oesa-2025-2466
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Use disable_delayed_work_sync
This makes use of disable_delayed_work_sync instead cancel_delayed_work_sync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.(CVE-2024-56591)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails.
Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.
Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path.
Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.(CVE-2025-22005)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a couple integer overflows on 32bit systems
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---(CVE-2025-37741)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.(CVE-2025-38319)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Limit access to parser->buffer when trace_get_user failed
When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:
BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165
CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0
The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise gateway LWS calls to probe user read access
We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER).
Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.(CVE-2025-39715)
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-qcom: Add SM6115 MDSS compatible
Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot:
arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed)
------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] ERROR could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the fields in the descriptor.(CVE-2025-39760)
In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in smb2_compound_op.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to cfile should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
cfile, except the patched one.
3. Existing callers would not handle refcount update of cfile if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of vars, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
is_replayable_error, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.(CVE-2025-39819)
A use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)
In the Linux kernel, the following vulnerability has been resolved:
mm: move page table sync declarations to linux/pgtable.h
During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:
BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK>
It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks.
And looking at __populate_section_memmap():
if (vmemmap_can_optimize(altmap, pgmap))
// does not sync top level page tables
r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
else
// sync top level page tables in x86
r = vmemmap_populate(start, end, nid, altmap);
In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.
However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.
We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.
It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.
The solution: Make page table sync more code robust and harder to miss
To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.
The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables.
pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t pgd, p4d_t p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); }
It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---(CVE-2025-39844)
In the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).
The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].
Fix by checking that the remote destination exists before dereferencing it.
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo
ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy
ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3
[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77
[4] #!/bin/bash
ip address add 2001:db8:1::1/128 dev lo
ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy
ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix potential invalid access when MAC list is empty
list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.
Fix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)
A NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)
A vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()
Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:
... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ...
The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.
We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.
As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.
Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/(CVE-2025-39886)
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix sched_numa_find_nth_cpu() if mask offline
sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.
The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):
[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[ 1.423635] Mem abort info:
[ 1.423889] ESR = 0x0000000096000006
[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.424715] SET = 0, FnV = 0
[ 1.424995] EA = 0, S1PTW = 0
[ 1.425279] FSC = 0x06: level 2 translation fault
[ 1.425735] Data abort info:
[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP
[ 1.429525] Modules linked in:
[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[ 1.432543] sp : ffffffc084e1b960
[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[ 1.439332] Call trace:
[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[ 1.440016] smp_call_function_any+0xc8/0xd0
[ 1.440416] armv8_pmu_init+0x58/0x27c
[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c
[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8
[ 1.441603] armv8_pmu_device_probe+0x1c/0x28
[ 1.442007] platform_probe+0x5c/0xac
[ 1.442347] really_probe+0xbc/0x298
[ 1.442683] __driver_probe_device+0x78/0x12c
[ 1.443087] driver_probe_device+0xdc/0x160
[ 1.443475] __driver_attach+0x94/0x19c
[ 1.443833] bus_for_each_dev+0x74/0xd4
[ 1.444190] driver_attach+0x24/0x30
[ 1.444525] bus_add_driver+0xe4/0x208
[ 1.444874] driver_register+0x60/0x128
[ 1.445233] __platform_driver_register+0x24/0x30
[ 1.445662] armv8_pmu_driver_init+0x28/0x4c
[ 1.446059] do_one_initcall+0x44/0x25c
[ 1.446416] kernel_init_freeable+0x1dc/0x3bc
[ 1.446820] kernel_init+0x20/0x1d8
[ 1.447151] ret_from_fork+0x10/0x20
[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[ 1.448040] ---[ end trace 0000000000000000 ]---
[ 1.448483] note: swapper/0[1] exited with preempt_count 1
[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.449741] SMP: stopping secondary CPUs
[ 1.450105] Kernel Offset: disabled
[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[
---truncated---(CVE-2025-39895)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Silence warning when chunk allocation fails in trace_pid_write
Syzkaller trigger a fault injection warning:
WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning.
The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.(CVE-2025-39914)
In the Linux kernel, the following vulnerability has been resolved:
cgroup: split cgroup_destroy_wq into 3 workqueues
A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.
Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20
Root Cause:
CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die
Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)
Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation
This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.
[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"perf-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-112.0.0.115.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"perf-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.115.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-112.0.0.115.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\nBluetooth: hci_conn: Use disable_delayed_work_sync\n\nThis makes use of disable_delayed_work_sync instead\ncancel_delayed_work_sync as it not only cancel the ongoing work but also\ndisables new submit which is disarable since the object holding the work\nis about to be freed.(CVE-2024-56591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().\n\nfib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything\nwhen it fails.\n\nCommit 7dd73168e273 (\u0026quot;ipv6: Always allocate pcpu memory in a fib6_nh\u0026quot;)\nmoved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()\nbut forgot to add cleanup for fib6_nh-\u0026gt;nh_common.nhc_pcpu_rth_output in\ncase it fails to allocate fib6_nh-\u0026gt;rt6i_pcpu, resulting in memleak.\n\nLet\u0026apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the\nerror path.\n\nNote that we can remove the fib6_nh_release() call in nh_create_ipv6()\nlater in net-next.git.(CVE-2025-22005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix a couple integer overflows on 32bit systems\n\nOn 32bit systems the \u0026quot;off + sizeof(struct NTFS_DE)\u0026quot; addition can\nhave an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling \u0026quot;ioctl$LOOP_SET_STATUS64\u0026quot;, the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---(CVE-2025-37741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table\n\nThe function atomctrl_initialize_mc_reg_table() and\natomctrl_initialize_mc_reg_table_v2_2() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()\nfails to retrieve vram_info, it returns NULL which is later\ndereferenced.(CVE-2025-38319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser-\u0026gt;buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser-\u0026gt;buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release-\u0026gt;\nftrace_process_regex-\u0026gt;strsep-\u0026gt;strpbrk. We can solve this problem by\nlimiting access to parser-\u0026gt;buffer when trace_get_user failed.(CVE-2025-39683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise gateway LWS calls to probe user read access\n\nWe use load and stbys,e instructions to trigger memory reference\ninterruptions without writing to memory. Because of the way read\naccess support is implemented, read access interruptions are only\ntriggered at privilege levels 2 and 3. The kernel and gateway\npage execute at privilege level 0, so this code never triggers\na read access interruption. Thus, it is currently possible for\nuser code to execute a LWS compare and swap operation at an\naddress that is read protected at privilege level 3 (PRIV_USER).\n\nFix this by probing read access rights at privilege level 3 and\nbranching to lws_fault if access isn\u0026apos;t allowed.(CVE-2025-39715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-qcom: Add SM6115 MDSS compatible\n\nAdd the SM6115 MDSS compatible to clients compatible list, as it also\nneeds that workaround.\nWithout this workaround, for example, QRB4210 RB2 which is based on\nSM4250/SM6115 generates a lot of smmu unhandled context faults during\nboot:\n\narm_smmu_context_fault: 116854 callbacks suppressed\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\narm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\n\nand also failed initialisation of lontium lt9611uxc, gpu and dpu is\nobserved:\n(binding MDSS components triggered by lt9611uxc have failed)\n\n ------------[ cut here ]------------\n !aspace\n WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]\n Modules linked in: ... (long list of modules)\n CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT\n Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : msm_gem_vma_init+0x150/0x18c [msm]\n lr : msm_gem_vma_init+0x150/0x18c [msm]\n sp : ffff80008144b280\n \t\t...\n Call trace:\n msm_gem_vma_init+0x150/0x18c [msm] (P)\n get_vma_locked+0xc0/0x194 [msm]\n msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]\n msm_gem_kernel_new+0x48/0x160 [msm]\n msm_gpu_init+0x34c/0x53c [msm]\n adreno_gpu_init+0x1b0/0x2d8 [msm]\n a6xx_gpu_init+0x1e8/0x9e0 [msm]\n adreno_bind+0x2b8/0x348 [msm]\n component_bind_all+0x100/0x230\n msm_drm_bind+0x13c/0x3d0 [msm]\n try_to_bring_up_aggregate_device+0x164/0x1d0\n __component_add+0xa4/0x174\n component_add+0x14/0x20\n dsi_dev_attach+0x20/0x34 [msm]\n dsi_host_attach+0x58/0x98 [msm]\n devm_mipi_dsi_attach+0x34/0x90\n lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]\n lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]\n i2c_device_probe+0x148/0x2a8\n really_probe+0xbc/0x2c0\n __driver_probe_device+0x78/0x120\n driver_probe_device+0x3c/0x154\n __driver_attach+0x90/0x1a0\n bus_for_each_dev+0x68/0xb8\n driver_attach+0x24/0x30\n bus_add_driver+0xe4/0x208\n driver_register+0x68/0x124\n i2c_register_driver+0x48/0xcc\n lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]\n do_one_initcall+0x60/0x1d4\n do_init_module+0x54/0x1fc\n load_module+0x1748/0x1c8c\n init_module_from_file+0x74/0xa0\n __arm64_sys_finit_module+0x130/0x2f8\n invoke_syscall+0x48/0x104\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x2c/0x80\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n ---[ end trace 0000000000000000 ]---\n msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22\n msm_dpu 5e01000.display-controller: failed to load adreno gpu\n platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19\n msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22\n msm_dpu 5e01000.display-controller: adev bind failed: -22\n lt9611uxc 0-002b: failed to attach dsi to host\n lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: config: Prevent OOB read in SS endpoint companion parsing\n\nusb_parse_ss_endpoint_companion() checks descriptor type before length,\nenabling a potentially odd read outside of the buffer size.\n\nFix this up by checking the size first before looking at any of the\nfields in the descriptor.(CVE-2025-39760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb: Fix inconsistent refcnt update\n\nA possible inconsistent update of refcount was identified in `smb2_compound_op`.\nSuch inconsistent update could lead to possible resource leaks.\n\nWhy it is a possible bug:\n1. In the comment section of the function, it clearly states that the\nreference to `cfile` should be dropped after calling this function.\n2. Every control flow path would check and drop the reference to\n`cfile`, except the patched one.\n3. Existing callers would not handle refcount update of `cfile` if\n-ENOMEM is returned.\n\nTo fix the bug, an extra goto label \u0026quot;out\u0026quot; is added, to make sure that the\ncleanup logic would always be respected. As the problem is caused by the\nallocation failure of `vars`, the cleanup logic between label \u0026quot;finished\u0026quot;\nand \u0026quot;out\u0026quot; can be safely ignored. According to the definition of function\n`is_replayable_error`, the error code of \u0026quot;-ENOMEM\u0026quot; is not recoverable.\nTherefore, the replay logic also gets ignored.(CVE-2025-39819)\n\nA use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: move page table sync declarations to linux/pgtable.h\n\nDuring our internal testing, we started observing intermittent boot\nfailures when the machine uses 4-level paging and has a large amount of\npersistent memory:\n\n BUG: unable to handle page fault for address: ffffe70000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0 \n Oops: 0002 [#1] SMP NOPTI\n RIP: 0010:__init_single_page+0x9/0x6d\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __init_zone_device_page+0x17/0x5d\n memmap_init_zone_device+0x154/0x1bb\n pagemap_range+0x2e0/0x40f\n memremap_pages+0x10b/0x2f0\n devm_memremap_pages+0x1e/0x60\n dev_dax_probe+0xce/0x2ec [device_dax]\n dax_bus_probe+0x6d/0xc9\n [... snip ...]\n \u0026lt;/TASK\u0026gt;\n\nIt turns out that the kernel panics while initializing vmemmap (struct\npage array) when the vmemmap region spans two PGD entries, because the new\nPGD entry is only installed in init_mm.pgd, but not in the page tables of\nother tasks.\n\nAnd looking at __populate_section_memmap():\n if (vmemmap_can_optimize(altmap, pgmap)) \n // does not sync top level page tables\n r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);\n else \n // sync top level page tables in x86\n r = vmemmap_populate(start, end, nid, altmap);\n\nIn the normal path, vmemmap_populate() in arch/x86/mm/init_64.c\nsynchronizes the top level page table (See commit 9b861528a801 (\u0026quot;x86-64,\nmem: Update all PGDs for direct mapping and vmemmap mapping changes\u0026quot;)) so\nthat all tasks in the system can see the new vmemmap area.\n\nHowever, when vmemmap_can_optimize() returns true, the optimized path\nskips synchronization of top-level page tables. This is because\nvmemmap_populate_compound_pages() is implemented in core MM code, which\ndoes not handle synchronization of the top-level page tables. Instead,\nthe core MM has historically relied on each architecture to perform this\nsynchronization manually.\n\nWe\u0026apos;re not the first party to encounter a crash caused by not-sync\u0026apos;d top\nlevel page tables: earlier this year, Gwan-gyeong Mun attempted to address\nthe issue [1] [2] after hitting a kernel panic when x86 code accessed the\nvmemmap area before the corresponding top-level entries were synced. At\nthat time, the issue was believed to be triggered only when struct page\nwas enlarged for debugging purposes, and the patch did not get further\nupdates.\n\nIt turns out that current approach of relying on each arch to handle the\npage table sync manually is fragile because 1) it\u0026apos;s easy to forget to sync\nthe top level page table, and 2) it\u0026apos;s also easy to overlook that the\nkernel should not access the vmemmap and direct mapping areas before the\nsync.\n\n# The solution: Make page table sync more code robust and harder to miss\n\nTo address this, Dave Hansen suggested [3] [4] introducing\n{pgd,p4d}_populate_kernel() for updating kernel portion of the page tables\nand allow each architecture to explicitly perform synchronization when\ninstalling top-level entries. With this approach, we no longer need to\nworry about missing the sync step, reducing the risk of future\nregressions.\n\nThe new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,\nPGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by\nvmalloc and ioremap to synchronize page tables.\n\npgd_populate_kernel() looks like this:\nstatic inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,\n p4d_t *p4d)\n{\n pgd_populate(\u0026amp;init_mm, pgd, p4d);\n if (ARCH_PAGE_TABLE_SYNC_MASK \u0026amp; PGTBL_PGD_MODIFIED)\n arch_sync_kernel_mappings(addr, addr);\n}\n\nIt is worth noting that vmalloc() and apply_to_range() carefully\nsynchronizes page tables by calling p*d_alloc_track() and\narch_sync_kernel_mappings(), and thus they are not affected by\n---truncated---(CVE-2025-39844)\n\nIn the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the \u0026quot;proxy\u0026quot; option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the \u0026quot;any\u0026quot; remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor\u0026apos;s MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)\n\nA NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)\n\nA vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()\n\nCurrently, calling bpf_map_kmalloc_node() from __bpf_async_init() can\ncause various locking issues; see the following stack trace (edited for\nstyle) as one example:\n\n...\n [10.011566] do_raw_spin_lock.cold\n [10.011570] try_to_wake_up (5) double-acquiring the same\n [10.011575] kick_pool rq_lock, causing a hardlockup\n [10.011579] __queue_work\n [10.011582] queue_work_on\n [10.011585] kernfs_notify\n [10.011589] cgroup_file_notify\n [10.011593] try_charge_memcg (4) memcg accounting raises an\n [10.011597] obj_cgroup_charge_pages MEMCG_MAX event\n [10.011599] obj_cgroup_charge_account\n [10.011600] __memcg_slab_post_alloc_hook\n [10.011603] __kmalloc_node_noprof\n...\n [10.011611] bpf_map_kmalloc_node\n [10.011612] __bpf_async_init\n [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()\n [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable\n [10.011619] bpf__sched_ext_ops_runnable\n [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held\n [10.011622] enqueue_task\n [10.011626] ttwu_do_activate\n [10.011629] sched_ttwu_pending (1) grabs rq_lock\n...\n\nThe above was reproduced on bpf-next (b338cf849ec8) by modifying\n./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during\nops.runnable(), and hacking the memcg accounting code a bit to make\na bpf_timer_init() call more likely to raise an MEMCG_MAX event.\n\nWe have also run into other similar variants (both internally and on\nbpf-next), including double-acquiring cgroup_file_kn_lock, the same\nworker_pool::lock, etc.\n\nAs suggested by Shakeel, fix this by using __GFP_HIGH instead of\nGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()\nraises an MEMCG_MAX event, we call __memcg_memory_event() with\n@allow_spinning=false and avoid calling cgroup_file_notify() there.\n\nDepends on mm patch\n\u0026quot;memcg: skip cgroup_file_notify if spinning is not allowed\u0026quot;:\nhttps://lore.kernel.org/bpf/(CVE-2025-39886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix sched_numa_find_nth_cpu() if mask offline\n\nsched_numa_find_nth_cpu() uses a bsearch to look for the \u0026apos;closest\u0026apos;\nCPU in sched_domains_numa_masks and given cpus mask. However they\nmight not intersect if all CPUs in the cpus mask are offline. bsearch\nwill return NULL in that case, bail out instead of dereferencing a\nbogus pointer.\n\nThe previous behaviour lead to this bug when using maxcpus=4 on an\nrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):\n\n[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000\n[ 1.423635] Mem abort info:\n[ 1.423889] ESR = 0x0000000096000006\n[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 1.424715] SET = 0, FnV = 0\n[ 1.424995] EA = 0, S1PTW = 0\n[ 1.425279] FSC = 0x06: level 2 translation fault\n[ 1.425735] Data abort info:\n[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000\n[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000\n[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP\n[ 1.429525] Modules linked in:\n[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT\n[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)\n[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488\n[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488\n[ 1.432543] sp : ffffffc084e1b960\n[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0\n[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378\n[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff\n[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7\n[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372\n[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860\n[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000\n[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000\n[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68\n[ 1.439332] Call trace:\n[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)\n[ 1.440016] smp_call_function_any+0xc8/0xd0\n[ 1.440416] armv8_pmu_init+0x58/0x27c\n[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c\n[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8\n[ 1.441603] armv8_pmu_device_probe+0x1c/0x28\n[ 1.442007] platform_probe+0x5c/0xac\n[ 1.442347] really_probe+0xbc/0x298\n[ 1.442683] __driver_probe_device+0x78/0x12c\n[ 1.443087] driver_probe_device+0xdc/0x160\n[ 1.443475] __driver_attach+0x94/0x19c\n[ 1.443833] bus_for_each_dev+0x74/0xd4\n[ 1.444190] driver_attach+0x24/0x30\n[ 1.444525] bus_add_driver+0xe4/0x208\n[ 1.444874] driver_register+0x60/0x128\n[ 1.445233] __platform_driver_register+0x24/0x30\n[ 1.445662] armv8_pmu_driver_init+0x28/0x4c\n[ 1.446059] do_one_initcall+0x44/0x25c\n[ 1.446416] kernel_init_freeable+0x1dc/0x3bc\n[ 1.446820] kernel_init+0x20/0x1d8\n[ 1.447151] ret_from_fork+0x10/0x20\n[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)\n[ 1.448040] ---[ end trace 0000000000000000 ]---\n[ 1.448483] note: swapper/0[1] exited with preempt_count 1\n[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n[ 1.449741] SMP: stopping secondary CPUs\n[ 1.450105] Kernel Offset: disabled\n[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b\n[ \n---truncated---(CVE-2025-39895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Silence warning when chunk allocation fails in trace_pid_write\n\nSyzkaller trigger a fault injection warning:\n\nWARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0\nModules linked in:\nCPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0\nTainted: [U]=USER\nHardware name: Google Compute Engine/Google Compute Engine\nRIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294\nCode: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff\nRSP: 0018:ffffc9000414fb48 EFLAGS: 00010283\nRAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000\nRDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0\nFS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464\n register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]\n register_pid_events kernel/trace/trace_events.c:2354 [inline]\n event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425\n vfs_write+0x24c/0x1150 fs/read_write.c:677\n ksys_write+0x12b/0x250 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe can reproduce the warning by following the steps below:\n1. echo 8 \u0026gt;\u0026gt; set_event_notrace_pid. Let tr-\u0026gt;filtered_pids owns one pid\n and register sched_switch tracepoint.\n2. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid, and perform fault injection during chunk\n allocation of trace_pid_list_alloc. Let pid_list with no pid and\nassign to tr-\u0026gt;filtered_pids.\n3. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid. Let pid_list is NULL and assign to\n tr-\u0026gt;filtered_pids.\n4. echo 9 \u0026gt;\u0026gt; set_event_pid, will trigger the double register\n sched_switch tracepoint warning.\n\nThe reason is that syzkaller injects a fault into the chunk allocation\nin trace_pid_list_alloc, causing a failure in trace_pid_list_set, which\nmay trigger double register of the same tracepoint. This only occurs\nwhen the system is about to crash, but to suppress this warning, let\u0026apos;s\nadd failure handling logic to trace_pid_list_set.(CVE-2025-39914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0 CPU1\nmount perf_event umount net_prio\ncgroup1_get_tree cgroup_kill_sb\nrebind_subsystems // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n // one perf_event css A is dying\n // css A offline enqueues cgroup_destroy_wq\n // root destruction will be executed first\n css_free_rwork_fn\n cgroup_destroy_root\n cgroup_lock_and_drain_offline\n // some perf descendants are dying\n // cgroup_destroy_wq max_active = 1\n // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq \u2013 Handles CSS offline operations\ncgroup_release_wq \u2013 Manages resource release\ncgroup_free_wq \u2013 Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)",
"id": "OESA-2025-2466",
"modified": "2026-08-06T11:09:33Z",
"published": "2025-10-17T11:09:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2466"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39953"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56591",
"CVE-2025-22005",
"CVE-2025-22081",
"CVE-2025-37741",
"CVE-2025-38086",
"CVE-2025-38319",
"CVE-2025-39683",
"CVE-2025-39715",
"CVE-2025-39739",
"CVE-2025-39752",
"CVE-2025-39760",
"CVE-2025-39819",
"CVE-2025-39824",
"CVE-2025-39844",
"CVE-2025-39845",
"CVE-2025-39850",
"CVE-2025-39851",
"CVE-2025-39853",
"CVE-2025-39865",
"CVE-2025-39883",
"CVE-2025-39886",
"CVE-2025-39895",
"CVE-2025-39914",
"CVE-2025-39953"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.