Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-39794 (GCVE-0-2025-39794)
Vulnerability from cvelistv5 – Published: 2025-09-12 15:59 – Updated: 2026-05-12 12:07| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
b36ab9754efbd7429d214b3b03dc9843882571bd , < b28c1a14accc79ead1e87bbdae53309da60be1e7
(git)
Affected: b36ab9754efbd7429d214b3b03dc9843882571bd , < 75a3bdfeed2f129a2c7d9fd7779382b78e35b014 (git) Affected: b36ab9754efbd7429d214b3b03dc9843882571bd , < 2499b0ac908eefbb8a217aae609b7a5b5174f330 (git) Affected: b36ab9754efbd7429d214b3b03dc9843882571bd , < 387435f4833f97aabfd74434ee526e31e8a626ea (git) Affected: b36ab9754efbd7429d214b3b03dc9843882571bd , < 46b3a7a3a36d5833f14914d1b95c69d28c6a76d6 (git) Affected: b36ab9754efbd7429d214b3b03dc9843882571bd , < 9b0b3b5e5cae95e09bf0ae4a9bcb58d9b6d57f87 (git) Affected: b36ab9754efbd7429d214b3b03dc9843882571bd , < 96d6605bf0561d6e568b1dd9265a0f73b5b94f51 (git) Affected: b36ab9754efbd7429d214b3b03dc9843882571bd , < 30ef45b89a5961cdecf907ecff1ef3374d1de510 (git) Affected: b36ab9754efbd7429d214b3b03dc9843882571bd , < 398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1 (git) |
guessed | |
| Linux | Linux |
Affected:
3.4
Unaffected: 0 , < 3.4 (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:26.094Z",
"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:07:04.300Z",
"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-tegra/reset.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "b28c1a14accc79ead1e87bbdae53309da60be1e7",
"status": "affected",
"version": "b36ab9754efbd7429d214b3b03dc9843882571bd",
"versionType": "git"
},
{
"lessThan": "75a3bdfeed2f129a2c7d9fd7779382b78e35b014",
"status": "affected",
"version": "b36ab9754efbd7429d214b3b03dc9843882571bd",
"versionType": "git"
},
{
"lessThan": "2499b0ac908eefbb8a217aae609b7a5b5174f330",
"status": "affected",
"version": "b36ab9754efbd7429d214b3b03dc9843882571bd",
"versionType": "git"
},
{
"lessThan": "387435f4833f97aabfd74434ee526e31e8a626ea",
"status": "affected",
"version": "b36ab9754efbd7429d214b3b03dc9843882571bd",
"versionType": "git"
},
{
"lessThan": "46b3a7a3a36d5833f14914d1b95c69d28c6a76d6",
"status": "affected",
"version": "b36ab9754efbd7429d214b3b03dc9843882571bd",
"versionType": "git"
},
{
"lessThan": "9b0b3b5e5cae95e09bf0ae4a9bcb58d9b6d57f87",
"status": "affected",
"version": "b36ab9754efbd7429d214b3b03dc9843882571bd",
"versionType": "git"
},
{
"lessThan": "96d6605bf0561d6e568b1dd9265a0f73b5b94f51",
"status": "affected",
"version": "b36ab9754efbd7429d214b3b03dc9843882571bd",
"versionType": "git"
},
{
"lessThan": "30ef45b89a5961cdecf907ecff1ef3374d1de510",
"status": "affected",
"version": "b36ab9754efbd7429d214b3b03dc9843882571bd",
"versionType": "git"
},
{
"lessThan": "398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1",
"status": "affected",
"version": "b36ab9754efbd7429d214b3b03dc9843882571bd",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/arm/mach-tegra/reset.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "3.4"
},
{
"lessThan": "3.4",
"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.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.241",
"versionStartIncluding": "3.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.190",
"versionStartIncluding": "3.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.149",
"versionStartIncluding": "3.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.103",
"versionStartIncluding": "3.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.43",
"versionStartIncluding": "3.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15.11",
"versionStartIncluding": "3.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.2",
"versionStartIncluding": "3.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"versionStartIncluding": "3.4",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nARM: tegra: Use I/O memcpy to write to IRAM\n\nKasan crashes the kernel trying to check boundaries when using the\nnormal memcpy."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:36:25.112Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/b28c1a14accc79ead1e87bbdae53309da60be1e7"
},
{
"url": "https://git.kernel.org/stable/c/75a3bdfeed2f129a2c7d9fd7779382b78e35b014"
},
{
"url": "https://git.kernel.org/stable/c/2499b0ac908eefbb8a217aae609b7a5b5174f330"
},
{
"url": "https://git.kernel.org/stable/c/387435f4833f97aabfd74434ee526e31e8a626ea"
},
{
"url": "https://git.kernel.org/stable/c/46b3a7a3a36d5833f14914d1b95c69d28c6a76d6"
},
{
"url": "https://git.kernel.org/stable/c/9b0b3b5e5cae95e09bf0ae4a9bcb58d9b6d57f87"
},
{
"url": "https://git.kernel.org/stable/c/96d6605bf0561d6e568b1dd9265a0f73b5b94f51"
},
{
"url": "https://git.kernel.org/stable/c/30ef45b89a5961cdecf907ecff1ef3374d1de510"
},
{
"url": "https://git.kernel.org/stable/c/398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1"
}
],
"title": "ARM: tegra: Use I/O memcpy to write to IRAM",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39794",
"datePublished": "2025-09-12T15:59:31.226Z",
"dateReserved": "2025-04-16T07:20:57.132Z",
"dateUpdated": "2026-05-12T12:07:04.300Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-39794",
"date": "2026-09-16",
"epss": "0.00159",
"percentile": "0.05433"
},
"microsoft_vex": {
"current_release_date": "2025-09-16T01:01:56.000Z",
"cve": "CVE-2025-39794",
"id": "msrc_CVE-2025-39794",
"initial_release_date": "2025-09-02T00:00:00.000Z",
"product_status:fixed": "1",
"product_status:known_affected": "1",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "ARM: tegra: Use I/O memcpy to write to IRAM",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-39794.json",
"version": "1"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2025-39794\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-09-12T16:15:33.700\",\"lastModified\":\"2026-06-17T09:18:29.590\",\"vulnStatus\":\"Modified\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nARM: tegra: Use I/O memcpy to write to IRAM\\n\\nKasan crashes the kernel trying to check boundaries when using the\\nnormal memcpy.\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"arch/arm/mach-tegra/reset.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"b36ab9754efbd7429d214b3b03dc9843882571bd\",\"lessThan\":\"b28c1a14accc79ead1e87bbdae53309da60be1e7\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b36ab9754efbd7429d214b3b03dc9843882571bd\",\"lessThan\":\"75a3bdfeed2f129a2c7d9fd7779382b78e35b014\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b36ab9754efbd7429d214b3b03dc9843882571bd\",\"lessThan\":\"2499b0ac908eefbb8a217aae609b7a5b5174f330\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b36ab9754efbd7429d214b3b03dc9843882571bd\",\"lessThan\":\"387435f4833f97aabfd74434ee526e31e8a626ea\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b36ab9754efbd7429d214b3b03dc9843882571bd\",\"lessThan\":\"46b3a7a3a36d5833f14914d1b95c69d28c6a76d6\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b36ab9754efbd7429d214b3b03dc9843882571bd\",\"lessThan\":\"9b0b3b5e5cae95e09bf0ae4a9bcb58d9b6d57f87\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b36ab9754efbd7429d214b3b03dc9843882571bd\",\"lessThan\":\"96d6605bf0561d6e568b1dd9265a0f73b5b94f51\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b36ab9754efbd7429d214b3b03dc9843882571bd\",\"lessThan\":\"30ef45b89a5961cdecf907ecff1ef3374d1de510\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"b36ab9754efbd7429d214b3b03dc9843882571bd\",\"lessThan\":\"398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"arch/arm/mach-tegra/reset.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"3.4\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"3.4\",\"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.4\",\"versionEndExcluding\":\"5.4.297\",\"matchCriteriaId\":\"C6346BD3-EE5C-4FE3-9197-F4F0A4C05E5A\"},{\"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/2499b0ac908eefbb8a217aae609b7a5b5174f330\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/30ef45b89a5961cdecf907ecff1ef3374d1de510\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/387435f4833f97aabfd74434ee526e31e8a626ea\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/398e67e0f5ae04b29bcc9cbf342e339fe9d3f6f1\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/46b3a7a3a36d5833f14914d1b95c69d28c6a76d6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/75a3bdfeed2f129a2c7d9fd7779382b78e35b014\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/96d6605bf0561d6e568b1dd9265a0f73b5b94f51\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/9b0b3b5e5cae95e09bf0ae4a9bcb58d9b6d57f87\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/b28c1a14accc79ead1e87bbdae53309da60be1e7\",\"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\":[\"Third Party Advisory\"]},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]},{\"url\":\"https://cert-portal.siemens.com/productcert/html/ssa-032379.html\",\"source\":\"0b142b55-0307-4c5a-b3c9-f314f3fb7c5e\"}]}}",
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-30T01:20:23+00:00",
"cve": "CVE-2025-39794",
"id": "CVE-2025-39794",
"initial_release_date": "2025-09-12T00:00:00+00:00",
"product_status:known_affected": "260",
"product_status:known_not_affected": "14",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: ARM: tegra: Use I/O memcpy to write to IRAM",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-39794.json",
"version": "3"
}
}
}
oesa-2025-2695
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:
misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error
After devm_request_irq() fails with error in pci_endpoint_test_request_irq(), the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs have been released.
However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message:
remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c
To solve this issue, set the number of remaining IRQs to test->num_irqs, and release IRQs in advance by calling pci_endpoint_test_release_irq().
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: csa unmap use uninterruptible lock
After process exit to unmap csa and free GPU vm, if signal is accepted and then waiting to take vm lock is interrupted and return, it causes memory leaking and below warning backtrace.
Change to use uninterruptible wait lock fix the issue.
WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu] Call Trace: <TASK> drm_file_free.part.0+0x1da/0x230 [drm] drm_close_helper.isra.0+0x65/0x70 [drm] drm_release+0x6a/0x120 [drm] amdgpu_drm_release+0x51/0x60 [amdgpu] __fput+0x9f/0x280 ____fput+0xe/0x20 task_work_run+0x67/0xa0 do_exit+0x217/0x3c0 do_group_exit+0x3b/0xb0 get_signal+0x14a/0x8d0 arch_do_signal_or_restart+0xde/0x100 exit_to_user_mode_loop+0xc1/0x1a0 exit_to_user_mode_prepare+0xf4/0x100 syscall_exit_to_user_mode+0x17/0x40 do_syscall_64+0x69/0xc0
(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)(CVE-2025-38011)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: avoid NULL pointer dereference if no valid csum tree
[BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace:
BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Call Trace: <TASK> scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e
[CAUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification.
Normally call sites utilizing csum tree will check the fs state flag NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.
This results in scrub to call btrfs_search_slot() on a NULL pointer and triggered above crash.
[FIX] Check both extent and csum tree root before doing any tree search.(CVE-2025-38059)
In the Linux kernel, the following vulnerability has been resolved:
coresight: holding cscfg_csdev_lock while removing cscfg from csdev
There'll be possible race scenario for coresight config:
CPU0 CPU1 (perf enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() <iterating config_csdev_list> cscfg_remove_owned_csdev_configs() // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock)
iterating config_csdev_list could be raced with config_csdev_list's entry delete.
To resolve this race , hold csdev->cscfg_csdev_lock() while cscfg_remove_owned_csdev_configs()(CVE-2025-38132)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()
devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference.
Prevent null pointer dereference in mt7915_mmio_wed_init().(CVE-2025-38155)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: handle hdr_first_de() return value
The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently.
Additionally, error handling for the return value already exists at other points where this function is called.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-38167)
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix double free in delayed_free
The double free could happen in the following path.
exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double free This patch set ->vol_util as NULL after freeing it.(CVE-2025-38206)
In the Linux kernel, the following vulnerability has been resolved:
aoe: clean device rq_list in aoedev_downdev()
An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue().(CVE-2025-38326)
In the Linux kernel, the following vulnerability has been resolved:
wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()
Robert Morris reported:
|If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common priv, | struct sk_buff skb) |{ | struct p54_hdr hdr = (struct p54_hdr ) skb->data; | struct p54_eeprom_lm86 eeprom = (struct p54_eeprom_lm86 ) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...]
The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun.
This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them.
The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default.(CVE-2025-38348)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disable migration in nf_hook_run_bpf().
syzbot reported that the netfilter bpf prog can be called without migration disabled in xmit path.
Then the assertion in __bpf_prog_run() fails, triggering the splat below. [0]
Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().
[0]: BUG: assuming non migratable context at ./include/linux/filter.h:703 in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session 3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241 CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpf_prog_run include/linux/filter.h:703 [inline] bpf_prog_run include/linux/filter.h:725 [inline] nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623 nf_hook+0x370/0x680 include/linux/netfilter.h:272 NF_HOOK_COND include/linux/netfilter.h:305 [inline] ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:459 [inline] ip_local_out net/ipv4/ip_output.c:129 [inline] __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline] tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021 tcp_push+0x225/0x700 net/ipv4/tcp.c:759 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x4aa/0x5b0 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x6c7/0x1150 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe7d365d407 Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP:(CVE-2025-38640)
In the Linux kernel, the following vulnerability has been resolved:
MIPS: Don't crash in stack_top() for tasks without ABI or vDSO
Not all tasks have an ABI associated or vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL ABI pointer and crash.
This can for example happen when using kunit:
mips_stack_top+0x28/0xc0
arch_pick_mmap_layout+0x190/0x220
kunit_vm_mmap_init+0xf8/0x138
__kunit_add_resource+0x40/0xa8
kunit_vm_mmap+0x88/0xd8
usercopy_test_init+0xb8/0x240
kunit_try_run_case+0x5c/0x1a8
kunit_generic_run_threadfn_adapter+0x28/0x50
kthread+0x118/0x240
ret_from_kernel_thread+0x14/0x1c
Only dereference the ABI point if it is set.
The GIC page is also included as it is specific to the vDSO. Also move the randomization adjustment into the same conditional.(CVE-2025-38696)
In the Linux kernel, the following vulnerability has been resolved:
sctp: linearize cloned gso packets in sctp_rcv
A cloned head skb still shares these frag skbs in fraglist with the original head skb. It's not safe to access these frag skbs.
syzbot reported two use-of-uninitialized-memory bugs caused by this:
BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]
and
BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]
This patch fixes it by linearizing cloned gso packets in sctp_rcv().(CVE-2025-38718)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix UAF on smcsk after smc_listen_out()
BPF CI testing report a UAF issue:
[ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: error_code(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] <TASK > [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? page_fault_oops+0x180/0x4c 0 [ 16.457508] ? __lock_acquire+0x3e6/0x249 0 [ 16.457801] ? exc_page_fault+0x68/0x20 0 [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0 [ 16.458389] ? smc_listen_work+0xc02/0x159 0 [ 16.458689] ? smc_listen_work+0xc02/0x159 0 [ 16.458987] ? lock_is_held_type+0x8f/0x10 0 [ 16.459284] process_one_work+0x1ea/0x6d 0 [ 16.459570] worker_thread+0x1c3/0x38 0 [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfx_kthread+0x10/0x1 0 [ 16.460640] ret_from_fork+0x31/0x5 0 [ 16.460896] ? __pfx_kthread+0x10/0x1 0 [ 16.461166] ret_from_fork_asm+0x1a/0x3 0 [ 16.461453] </TASK > [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590
The direct cause of this issue is that after smc_listen_out_connected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows:
smc_listen_work | userspace
lock_sock(sk) | smc_listen_out_connected() | | - smc_listen_out | | | - release_sock | | |- sk->sk_data_ready() | | fd = accept(); | close(fd); | - socket->sk = NULL; / newclcsock->sk is NULL now / SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk))
Since smc_listen_out_connected() will not fail, simply swapping the order of the code can easily fix this issue.(CVE-2025-38734)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid a NULL pointer dereference
[WHY] Although unlikely drm_atomic_get_new_connector_state() or drm_atomic_get_old_connector_state() can return NULL.
[HOW] Check returns before dereference.
(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)(CVE-2025-39693)
In the Linux kernel, the following vulnerability has been resolved:
media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls
Both the ACE and CSI driver are missing a mei_cldev_disable() call in their remove() function.
This causes the mei_cl client to stay part of the mei_device->file_list list even though its memory is freed by mei_cl_bus_dev_release() calling kfree(cldev->cl).
This leads to a use-after-free when mei_vsc_remove() runs mei_stop() which first removes all mei bus devices calling mei_ace_remove() and mei_csi_remove() followed by mei_cl_bus_dev_release() and then calls mei_cl_all_disconnect() which walks over mei_device->file_list dereferecing the just freed cldev->cl.
And mei_vsc_remove() it self is run at shutdown because of the platform_device_unregister(tp->pdev) in vsc_tp_shutdown()
When building a kernel with KASAN this leads to the following KASAN report:
[ 106.634504] ================================================================== [ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1 [ 106.634729] [ 106.634767] Tainted: [E]=UNSIGNED_MODULE [ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025 [ 106.634773] Call Trace: [ 106.634777] <TASK> ... [ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) [ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei [ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei [ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc [ 106.635066] platform_remove (drivers/base/platform.c:1424)
Add the missing mei_cldev_disable() calls so that the mei_cl gets removed from mei_device->file_list before it is freed to fix this.(CVE-2025-39711)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise __get_user() to probe user read access
Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call.
Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed.
Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm.(CVE-2025-39716)
In the Linux kernel, the following vulnerability has been resolved:
iio: imu: bno055: fix OOB access of hw_xlate array
Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c.
In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array.
By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length.(CVE-2025-39719)
In the Linux kernel, the following vulnerability has been resolved:
s390/ism: fix concurrency management in ism_cmd()
The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that.
This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well.
A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it.
On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.(CVE-2025-39726)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Optimize module load time by optimizing PLT/GOT counting
When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows:
rcu: INFO: rcu_sched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler+0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constant_timer_interrupt+0x64/0x80 [<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x30/0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158
After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock.
When loading a module, module_frob_arch_sections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the count_max_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity.
To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations.
After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace".
Using the default configuration to test some modules, the results are as follows:
Module Size ip_tables 36K fat 143K radeon 2.5MB amdgpu 16MB
Without this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098
With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 22 1221/84 amdgpu 45 4525/1098(CVE-2025-39767)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Drop WARN_ON_ONCE() from flush_cache_vmap
I have observed warning to occassionally trigger.(CVE-2025-39781)
In the Linux kernel, the following vulnerability has been resolved:
ARM: tegra: Use I/O memcpy to write to IRAM
Kasan crashes the kernel trying to check boundaries when using the normal memcpy.(CVE-2025-39794)
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()
in ntrig_report_version(), hdev parameter passed from hid_probe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usb_dev has invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned when usb_rcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58)
add null check logic to ntrig_report_version() before calling hid_to_usb_dev()(CVE-2025-39808)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: prevent release journal inode after journal shutdown
Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode().
ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal,
Adding osb->journal checks will prevent null-ptr-deref during the above execution path.(CVE-2025-39842)
In the Linux kernel, the following vulnerability has been resolved:
pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()
In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource().
Fix this bug by adding a check of res.(CVE-2025-39846)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: vhci: Prevent use-after-free by removing debugfs files early
Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed.
Previously, debugfs files such as "force_suspend", "force_wakeup", and others were created under hdev->debugfs but not removed in vhci_release(). Since vhci_release() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors.
Although hdev->debugfs is later freed in hci_release_dev(), user can access files after vhci_data is freed but before hdev->debugfs is released.(CVE-2025-39861)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work
The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions:
1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync().
2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs.
The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread.
Scenario 1: Freed before the worker is scheduled
The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below:
CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE
Scenario 2: Freed after the worker is scheduled
The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario:
CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker / | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| / |
To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.(CVE-2025-39863)
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()
Patch series "mm/damon: avoid divide-by-zero in DAMON module's parameters application".
DAMON's RECLAIM and LRU_SORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors.
Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters.
This patch (of 2):
During the calculation of 'hot_thres' and 'cold_thres', either 'sample_interval' or 'aggr_interval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggr_interval' is already required to be set no smaller than 'sample_interval' in damon_set_attrs(), only the case where 'sample_interval' is zero needs to be checked.(CVE-2025-39909)
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()
When creating a new scheme of DAMON_RECLAIM, the calculation of 'min_age_region' uses 'aggr_interval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.(CVE-2025-39916)
In the Linux kernel, the following vulnerability has been resolved:
drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ
If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.(CVE-2025-39934)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: avoid buffer overflow in WID string configuration
Fix the following copy overflow warning identified by Smatch checker.
drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)
This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.(CVE-2025-39952)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid
Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled.
BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [<ffffffffc08b2527>] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [<ffffffffb4f62e32>] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: <TASK> dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b </TASK>
Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons).(CVE-2025-40038)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential null deref in ext4_mb_init()
In ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called when sbi->s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo slab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy() lacks null pointer checking, this leads to a null pointer dereference.
================================================================== EXT4-fs: no memory for groupinfo slab cache BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP PTI CPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none) RIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40 Call Trace: <TASK> xa_destroy+0x61/0x130 ext4_mb_init+0x483/0x540 __ext4_fill_super+0x116d/0x17b0 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 do_new_mount+0x197/0x300 __x64_sys_mount+0x116/0x150 do_syscall_64+0x50/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================
Therefore, add necessary null check to ext4_mb_avg_fragment_size_destroy() to prevent this issue. The same fix is also applied to ext4_mb_largest_free_orders_destroy().(CVE-2025-40119)
In the Linux kernel, the following vulnerability has been resolved:
EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller
When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows:
UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ...
This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above.
Fix this call trace by skipping DIMM enumeration on a disabled memory controller.(CVE-2025-40157)
In the Linux kernel, the following vulnerability has been resolved:
fs: quota: create dedicated workqueue for quota_release_work
There is a kernel panic due to WARN_ONCE when panic_on_warn is set.
This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors.
This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work.
------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...(CVE-2025-40196)
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try(). v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().(CVE-2025-40207)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"perf-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-119.0.0.122.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-119.0.0.122.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"perf-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-119.0.0.122.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-119.0.0.122.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-119.0.0.122.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\nmisc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error\n\nAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),\nthe pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs\nhave been released.\n\nHowever, some requested IRQs remain unreleased, so there are still\n/proc/irq/* entries remaining, and this results in WARN() with the\nfollowing message:\n\n remove_proc_entry: removing non-empty directory \u0026apos;irq/30\u0026apos;, leaking at least \u0026apos;pci-endpoint-test.0\u0026apos;\n WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c\n\nTo solve this issue, set the number of remaining IRQs to test-\u0026gt;num_irqs,\nand release IRQs in advance by calling pci_endpoint_test_release_irq().\n\n[kwilczynski: commit log](CVE-2025-23140)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: csa unmap use uninterruptible lock\n\nAfter process exit to unmap csa and free GPU vm, if signal is accepted\nand then waiting to take vm lock is interrupted and return, it causes\nmemory leaking and below warning backtrace.\n\nChange to use uninterruptible wait lock fix the issue.\n\nWARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525\n amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n drm_file_free.part.0+0x1da/0x230 [drm]\n drm_close_helper.isra.0+0x65/0x70 [drm]\n drm_release+0x6a/0x120 [drm]\n amdgpu_drm_release+0x51/0x60 [amdgpu]\n __fput+0x9f/0x280\n ____fput+0xe/0x20\n task_work_run+0x67/0xa0\n do_exit+0x217/0x3c0\n do_group_exit+0x3b/0xb0\n get_signal+0x14a/0x8d0\n arch_do_signal_or_restart+0xde/0x100\n exit_to_user_mode_loop+0xc1/0x1a0\n exit_to_user_mode_prepare+0xf4/0x100\n syscall_exit_to_user_mode+0x17/0x40\n do_syscall_64+0x69/0xc0\n\n(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)(CVE-2025-38011)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: avoid NULL pointer dereference if no valid csum tree\n\n[BUG]\nWhen trying read-only scrub on a btrfs with rescue=idatacsums mount\noption, it will crash with the following call trace:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000208\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs]\n scrub_simple_mirror+0x175/0x290 [btrfs]\n scrub_stripe+0x5f7/0x6f0 [btrfs]\n scrub_chunk+0x9a/0x150 [btrfs]\n scrub_enumerate_chunks+0x333/0x660 [btrfs]\n btrfs_scrub_dev+0x23e/0x600 [btrfs]\n btrfs_ioctl+0x1dcf/0x2f80 [btrfs]\n __x64_sys_ioctl+0x97/0xc0\n do_syscall_64+0x4f/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[CAUSE]\nMount option \u0026quot;rescue=idatacsums\u0026quot; will completely skip loading the csum\ntree, so that any data read will not find any data csum thus we will\nignore data checksum verification.\n\nNormally call sites utilizing csum tree will check the fs state flag\nNO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.\n\nThis results in scrub to call btrfs_search_slot() on a NULL pointer\nand triggered above crash.\n\n[FIX]\nCheck both extent and csum tree root before doing any tree search.(CVE-2025-38059)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: holding cscfg_csdev_lock while removing cscfg from csdev\n\nThere\u0026apos;ll be possible race scenario for coresight config:\n\nCPU0 CPU1\n(perf enable) load module\n cscfg_load_config_sets()\n activate config. // sysfs\n (sys_active_cnt == 1)\n...\ncscfg_csdev_enable_active_config()\n lock(csdev-\u0026gt;cscfg_csdev_lock)\n deactivate config // sysfs\n (sys_activec_cnt == 0)\n cscfg_unload_config_sets()\n \u0026lt;iterating config_csdev_list\u0026gt; cscfg_remove_owned_csdev_configs()\n // here load config activate by CPU1\n unlock(csdev-\u0026gt;cscfg_csdev_lock)\n\niterating config_csdev_list could be raced with config_csdev_list\u0026apos;s\nentry delete.\n\nTo resolve this race , hold csdev-\u0026gt;cscfg_csdev_lock() while\ncscfg_remove_owned_csdev_configs()(CVE-2025-38132)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()\n\ndevm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init()\ndoes not check for this case, which results in a NULL pointer\ndereference.\n\nPrevent null pointer dereference in mt7915_mmio_wed_init().(CVE-2025-38155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: handle hdr_first_de() return value\n\nThe hdr_first_de() function returns a pointer to a struct NTFS_DE. This\npointer may be NULL. To handle the NULL error effectively, it is important\nto implement an error handler. This will help manage potential errors\nconsistently.\n\nAdditionally, error handling for the return value already exists at other\npoints where this function is called.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-38167)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix double free in delayed_free\n\nThe double free could happen in the following path.\n\nexfat_create_upcase_table()\n exfat_create_upcase_table() : return error\n exfat_free_upcase_table() : free -\u0026gt;vol_utbl\n exfat_load_default_upcase_table : return error\n exfat_kill_sb()\n delayed_free()\n exfat_free_upcase_table() \u0026lt;--------- double free\nThis patch set -\u0026gt;vol_util as NULL after freeing it.(CVE-2025-38206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naoe: clean device rq_list in aoedev_downdev()\n\nAn aoe device\u0026apos;s rq_list contains accepted block requests that are\nwaiting to be transmitted to the aoe target. This queue was added as\npart of the conversion to blk_mq. However, the queue was not cleaned out\nwhen an aoe device is downed which caused blk_mq_freeze_queue() to sleep\nindefinitely waiting for those requests to complete, causing a hang. This\nfix cleans out the queue before calling blk_mq_freeze_queue().(CVE-2025-38326)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\n\nRobert Morris reported:\n\n|If a malicious USB device pretends to be an Intersil p54 wifi\n|interface and generates an eeprom_readback message with a large\n|eeprom-\u0026gt;v1.len, p54_rx_eeprom_readback() will copy data from the\n|message beyond the end of priv-\u0026gt;eeprom.\n|\n|static void p54_rx_eeprom_readback(struct p54_common *priv,\n| struct sk_buff *skb)\n|{\n| struct p54_hdr *hdr = (struct p54_hdr *) skb-\u0026gt;data;\n| struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-\u0026gt;data;\n|\n| if (priv-\u0026gt;fw_var \u0026gt;= 0x509) {\n| memcpy(priv-\u0026gt;eeprom, eeprom-\u0026gt;v2.data,\n| le16_to_cpu(eeprom-\u0026gt;v2.len));\n| } else {\n| memcpy(priv-\u0026gt;eeprom, eeprom-\u0026gt;v1.data,\n| le16_to_cpu(eeprom-\u0026gt;v1.len));\n| }\n| [...]\n\nThe eeprom-\u0026gt;v{1,2}.len is set by the driver in p54_download_eeprom().\nThe device is supposed to provide the same length back to the driver.\nBut yes, it\u0026apos;s possible (like shown in the report) to alter the value\nto something that causes a crash/panic due to overrun.\n\nThis patch addresses the issue by adding the size to the common device\ncontext, so p54_rx_eeprom_readback no longer relies on possibly tampered\nvalues... That said, it also checks if the \u0026quot;firmware\u0026quot; altered the value\nand no longer copies them.\n\nThe one, small saving grace is: Before the driver tries to read the eeprom,\nit needs to upload \u0026gt;a\u0026lt; firmware. the vendor firmware has a proprietary\nlicense and as a reason, it is not present on most distributions by\ndefault.(CVE-2025-38348)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Disable migration in nf_hook_run_bpf().\n\nsyzbot reported that the netfilter bpf prog can be called without\nmigration disabled in xmit path.\n\nThen the assertion in __bpf_prog_run() fails, triggering the splat\nbelow. [0]\n\nLet\u0026apos;s use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().\n\n[0]:\nBUG: assuming non migratable context at ./include/linux/filter.h:703\nin_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session\n3 locks held by sshd-session/5829:\n #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline]\n #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241\nCPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n __cant_migrate kernel/sched/core.c:8860 [inline]\n __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834\n __bpf_prog_run include/linux/filter.h:703 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20\n nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]\n nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623\n nf_hook+0x370/0x680 include/linux/netfilter.h:272\n NF_HOOK_COND include/linux/netfilter.h:305 [inline]\n ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433\n dst_output include/net/dst.h:459 [inline]\n ip_local_out net/ipv4/ip_output.c:129 [inline]\n __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527\n __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479\n tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline]\n tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838\n __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021\n tcp_push+0x225/0x700 net/ipv4/tcp.c:759\n tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359\n tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396\n inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n sock_write_iter+0x4aa/0x5b0 net/socket.c:1131\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x6c7/0x1150 fs/read_write.c:686\n ksys_write+0x1f8/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe7d365d407\nCode: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u0026lt;5b\u0026gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff\nRSP:(CVE-2025-38640)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Don\u0026apos;t crash in stack_top() for tasks without ABI or vDSO\n\nNot all tasks have an ABI associated or vDSO mapped,\nfor example kthreads never do.\nIf such a task ever ends up calling stack_top(), it will derefence the\nNULL ABI pointer and crash.\n\nThis can for example happen when using kunit:\n\n mips_stack_top+0x28/0xc0\n arch_pick_mmap_layout+0x190/0x220\n kunit_vm_mmap_init+0xf8/0x138\n __kunit_add_resource+0x40/0xa8\n kunit_vm_mmap+0x88/0xd8\n usercopy_test_init+0xb8/0x240\n kunit_try_run_case+0x5c/0x1a8\n kunit_generic_run_threadfn_adapter+0x28/0x50\n kthread+0x118/0x240\n ret_from_kernel_thread+0x14/0x1c\n\nOnly dereference the ABI point if it is set.\n\nThe GIC page is also included as it is specific to the vDSO.\nAlso move the randomization adjustment into the same conditional.(CVE-2025-38696)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: linearize cloned gso packets in sctp_rcv\n\nA cloned head skb still shares these frag skbs in fraglist with the\noriginal head skb. It\u0026apos;s not safe to access these frag skbs.\n\nsyzbot reported two use-of-uninitialized-memory bugs caused by this:\n\n BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211\n sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211\n sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998\n sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88\n sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331\n sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122\n __release_sock+0x1da/0x330 net/core/sock.c:3106\n release_sock+0x6b/0x250 net/core/sock.c:3660\n sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360\n sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885\n sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031\n inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:718 [inline]\n\nand\n\n BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987\n sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987\n sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88\n sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331\n sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n __release_sock+0x1d3/0x330 net/core/sock.c:3213\n release_sock+0x6b/0x270 net/core/sock.c:3767\n sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367\n sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886\n sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032\n inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n\nThis patch fixes it by linearizing cloned gso packets in sctp_rcv().(CVE-2025-38718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix UAF on smcsk after smc_listen_out()\n\nBPF CI testing report a UAF issue:\n\n [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0\n [ 16.447134] #PF: supervisor read access in kernel mod e\n [ 16.447516] #PF: error_code(0x0000) - not-present pag e\n [ 16.447878] PGD 0 P4D 0\n [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I\n [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2\n [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E\n [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4\n [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k\n [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0\n [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6\n [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0\n [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0\n [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5\n [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0\n [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0\n [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0\n [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3\n [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0\n [ 16.456459] PKRU: 5555555 4\n [ 16.456654] Call Trace :\n [ 16.456832] \u0026lt;TASK \u0026gt;\n [ 16.456989] ? __die+0x23/0x7 0\n [ 16.457215] ? page_fault_oops+0x180/0x4c 0\n [ 16.457508] ? __lock_acquire+0x3e6/0x249 0\n [ 16.457801] ? exc_page_fault+0x68/0x20 0\n [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0\n [ 16.458389] ? smc_listen_work+0xc02/0x159 0\n [ 16.458689] ? smc_listen_work+0xc02/0x159 0\n [ 16.458987] ? lock_is_held_type+0x8f/0x10 0\n [ 16.459284] process_one_work+0x1ea/0x6d 0\n [ 16.459570] worker_thread+0x1c3/0x38 0\n [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0\n [ 16.460144] kthread+0xe0/0x11 0\n [ 16.460372] ? __pfx_kthread+0x10/0x1 0\n [ 16.460640] ret_from_fork+0x31/0x5 0\n [ 16.460896] ? __pfx_kthread+0x10/0x1 0\n [ 16.461166] ret_from_fork_asm+0x1a/0x3 0\n [ 16.461453] \u0026lt;/TASK \u0026gt;\n [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ]\n [ 16.462134] CR2: 000000000000003 0\n [ 16.462380] ---[ end trace 0000000000000000 ]---\n [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590\n\nThe direct cause of this issue is that after smc_listen_out_connected(),\nnewclcsock-\u0026gt;sk may be NULL since it will releases the smcsk. Therefore,\nif the application closes the socket immediately after accept,\nnewclcsock-\u0026gt;sk can be NULL. A possible execution order could be as\nfollows:\n\nsmc_listen_work | userspace\n-----------------------------------------------------------------\nlock_sock(sk) |\nsmc_listen_out_connected() |\n| \\- smc_listen_out |\n| | \\- release_sock |\n | |- sk-\u0026gt;sk_data_ready() |\n | fd = accept();\n | close(fd);\n | \\- socket-\u0026gt;sk = NULL;\n/* newclcsock-\u0026gt;sk is NULL now */\nSMC_STAT_SERV_SUCC_INC(sock_net(newclcsock-\u0026gt;sk))\n\nSince smc_listen_out_connected() will not fail, simply swapping the order\nof the code can easily fix this issue.(CVE-2025-38734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Avoid a NULL pointer dereference\n\n[WHY]\nAlthough unlikely drm_atomic_get_new_connector_state() or\ndrm_atomic_get_old_connector_state() can return NULL.\n\n[HOW]\nCheck returns before dereference.\n\n(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)(CVE-2025-39693)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls\n\nBoth the ACE and CSI driver are missing a mei_cldev_disable() call in\ntheir remove() function.\n\nThis causes the mei_cl client to stay part of the mei_device-\u0026gt;file_list\nlist even though its memory is freed by mei_cl_bus_dev_release() calling\nkfree(cldev-\u0026gt;cl).\n\nThis leads to a use-after-free when mei_vsc_remove() runs mei_stop()\nwhich first removes all mei bus devices calling mei_ace_remove() and\nmei_csi_remove() followed by mei_cl_bus_dev_release() and then calls\nmei_cl_all_disconnect() which walks over mei_device-\u0026gt;file_list dereferecing\nthe just freed cldev-\u0026gt;cl.\n\nAnd mei_vsc_remove() it self is run at shutdown because of the\nplatform_device_unregister(tp-\u0026gt;pdev) in vsc_tp_shutdown()\n\nWhen building a kernel with KASAN this leads to the following KASAN report:\n\n[ 106.634504] ==================================================================\n[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei\n[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1\n[ 106.634729]\n[ 106.634767] Tainted: [E]=UNSIGNED_MODULE\n[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025\n[ 106.634773] Call Trace:\n[ 106.634777] \u0026lt;TASK\u0026gt;\n...\n[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)\n[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei\n[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei\n[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei\n...\n[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei\n[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc\n[ 106.635066] platform_remove (drivers/base/platform.c:1424)\n\nAdd the missing mei_cldev_disable() calls so that the mei_cl gets removed\nfrom mei_device-\u0026gt;file_list before it is freed to fix this.(CVE-2025-39711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise __get_user() to probe user read access\n\nBecause of the way read access support is implemented, read access\ninterruptions are only triggered at privilege levels 2 and 3. The\nkernel executes at privilege level 0, so __get_user() never triggers\na read access interruption (code 26). Thus, it is currently possible\nfor user code to access a read protected address via a system call.\n\nFix this by probing read access rights at privilege level 3 (PRIV_USER)\nand setting __gu_err to -EFAULT (-14) if access isn\u0026apos;t allowed.\n\nNote the cmpiclr instruction does a 32-bit compare because COND macro\ndoesn\u0026apos;t work inside asm.(CVE-2025-39716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: bno055: fix OOB access of hw_xlate array\n\nFix a potential out-of-bounds array access of the hw_xlate array in\nbno055.c.\n\nIn bno055_get_regmask(), hw_xlate was iterated over the length of the\nvals array instead of the length of the hw_xlate array. In the case of\nbno055_gyr_scale, the vals array is larger than the hw_xlate array,\nso this could result in an out-of-bounds access. In practice, this\nshouldn\u0026apos;t happen though because a match should always be found which\nbreaks out of the for loop before it iterates beyond the end of the\nhw_xlate array.\n\nBy adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be\nsure we are iterating over the correct length.(CVE-2025-39719)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/ism: fix concurrency management in ism_cmd()\n\nThe s390x ISM device data sheet clearly states that only one\nrequest-response sequence is allowable per ISM function at any point in\ntime. Unfortunately as of today the s390/ism driver in Linux does not\nhonor that requirement. This patch aims to rectify that.\n\nThis problem was discovered based on Aliaksei\u0026apos;s bug report which states\nthat for certain workloads the ISM functions end up entering error state\n(with PEC 2 as seen from the logs) after a while and as a consequence\nconnections handled by the respective function break, and for future\nconnection requests the ISM device is not considered -- given it is in a\ndysfunctional state. During further debugging PEC 3A was observed as\nwell.\n\nA kernel message like\n[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a\nis a reliable indicator of the stated function entering error state\nwith PEC 2. Let me also point out that a kernel message like\n[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery\nis a reliable indicator that the ISM function won\u0026apos;t be auto-recovered\nbecause the ISM driver currently lacks support for it.\n\nOn a technical level, without this synchronization, commands (inputs to\nthe FW) may be partially or fully overwritten (corrupted) by another CPU\ntrying to issue commands on the same function. There is hard evidence that\nthis can lead to DMB token values being used as DMB IOVAs, leading to\nPEC 2 PCI events indicating invalid DMA. But this is only one of the\nfailure modes imaginable. In theory even completely losing one command\nand executing another one twice and then trying to interpret the outputs\nas if the command we intended to execute was actually executed and not\nthe other one is also possible. Frankly, I don\u0026apos;t feel confident about\nproviding an exhaustive list of possible consequences.(CVE-2025-39726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Optimize module load time by optimizing PLT/GOT counting\n\nWhen enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and\nCONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,\nthe relevant logs are as follows:\n\nrcu: INFO: rcu_sched self-detected stall on CPU\n...\nCall Trace:\n[\u0026lt;900000000024f9e4\u0026gt;] show_stack+0x5c/0x180\n[\u0026lt;90000000002482f4\u0026gt;] dump_stack_lvl+0x94/0xbc\n[\u0026lt;9000000000224544\u0026gt;] rcu_dump_cpu_stacks+0x1fc/0x280\n[\u0026lt;900000000037ac80\u0026gt;] rcu_sched_clock_irq+0x720/0xf88\n[\u0026lt;9000000000396c34\u0026gt;] update_process_times+0xb4/0x150\n[\u0026lt;90000000003b2474\u0026gt;] tick_nohz_handler+0xf4/0x250\n[\u0026lt;9000000000397e28\u0026gt;] __hrtimer_run_queues+0x1d0/0x428\n[\u0026lt;9000000000399b2c\u0026gt;] hrtimer_interrupt+0x214/0x538\n[\u0026lt;9000000000253634\u0026gt;] constant_timer_interrupt+0x64/0x80\n[\u0026lt;9000000000349938\u0026gt;] __handle_irq_event_percpu+0x78/0x1a0\n[\u0026lt;9000000000349a78\u0026gt;] handle_irq_event_percpu+0x18/0x88\n[\u0026lt;9000000000354c00\u0026gt;] handle_percpu_irq+0x90/0xf0\n[\u0026lt;9000000000348c74\u0026gt;] handle_irq_desc+0x94/0xb8\n[\u0026lt;9000000001012b28\u0026gt;] handle_cpu_irq+0x68/0xa0\n[\u0026lt;9000000001def8c0\u0026gt;] handle_loongarch_irq+0x30/0x48\n[\u0026lt;9000000001def958\u0026gt;] do_vint+0x80/0xd0\n[\u0026lt;9000000000268a0c\u0026gt;] kasan_mem_to_shadow.part.0+0x2c/0x2a0\n[\u0026lt;90000000006344f4\u0026gt;] __asan_load8+0x4c/0x120\n[\u0026lt;900000000025c0d0\u0026gt;] module_frob_arch_sections+0x5c8/0x6b8\n[\u0026lt;90000000003895f0\u0026gt;] load_module+0x9e0/0x2958\n[\u0026lt;900000000038b770\u0026gt;] __do_sys_init_module+0x208/0x2d0\n[\u0026lt;9000000001df0c34\u0026gt;] do_syscall+0x94/0x190\n[\u0026lt;900000000024d6fc\u0026gt;] handle_syscall+0xbc/0x158\n\nAfter analysis, this is because the slow speed of loading the amdgpu\nmodule leads to the long time occupation of the cpu and then the soft\ndeadlock.\n\nWhen loading a module, module_frob_arch_sections() tries to figure out\nthe number of PLTs/GOTs that will be needed to handle all the RELAs. It\nwill call the count_max_entries() to find in an out-of-order date which\ncounting algorithm has O(n^2) complexity.\n\nTo make it faster, we sort the relocation list by info and addend. That\nway, to check for a duplicate relocation, it just needs to compare with\nthe previous entry. This reduces the complexity of the algorithm to O(n\n log n), as done in commit d4e0340919fb (\u0026quot;arm64/module: Optimize module\nload time by optimizing PLT counting\u0026quot;). This gives sinificant reduction\nin module load time for modules with large number of relocations.\n\nAfter applying this patch, the soft deadlock problem has been solved,\nand the kernel starts normally without \u0026quot;Call Trace\u0026quot;.\n\nUsing the default configuration to test some modules, the results are as\nfollows:\n\nModule Size\nip_tables 36K\nfat 143K\nradeon 2.5MB\namdgpu 16MB\n\nWithout this patch:\nModule Module load time (ms)\tCount(PLTs/GOTs)\nip_tables 18\t\t\t\t59/6\nfat 0\t\t\t\t162/14\nradeon 54\t\t\t\t1221/84\namdgpu 1411\t\t\t4525/1098\n\nWith this patch:\nModule Module load time (ms)\tCount(PLTs/GOTs)\nip_tables 18\t\t\t\t59/6\nfat 0\t\t\t\t162/14\nradeon 22\t\t\t\t1221/84\namdgpu 45\t\t\t\t4525/1098(CVE-2025-39767)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Drop WARN_ON_ONCE() from flush_cache_vmap\n\nI have observed warning to occassionally trigger.(CVE-2025-39781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: tegra: Use I/O memcpy to write to IRAM\n\nKasan crashes the kernel trying to check boundaries when using the\nnormal memcpy.(CVE-2025-39794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()\n\nin ntrig_report_version(), hdev parameter passed from hid_probe().\nsending descriptor to /dev/uhid can make hdev-\u0026gt;dev.parent-\u0026gt;parent to null\nif hdev-\u0026gt;dev.parent-\u0026gt;parent is null, usb_dev has\ninvalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned\nwhen usb_rcvctrlpipe() use usb_dev,it trigger\npage fault error for address(0xffffffffffffff58)\n\nadd null check logic to ntrig_report_version()\nbefore calling hid_to_usb_dev()(CVE-2025-39808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: prevent release journal inode after journal shutdown\n\nBefore calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already\nbeen executed in ocfs2_dismount_volume(), so osb-\u0026gt;journal must be NULL. \nTherefore, the following calltrace will inevitably fail when it reaches\njbd2_journal_release_jbd_inode().\n\nocfs2_dismount_volume()-\u0026gt;\n ocfs2_delete_osb()-\u0026gt;\n ocfs2_free_slot_info()-\u0026gt;\n __ocfs2_free_slot_info()-\u0026gt;\n evict()-\u0026gt;\n ocfs2_evict_inode()-\u0026gt;\n ocfs2_clear_inode()-\u0026gt;\n\t jbd2_journal_release_jbd_inode(osb-\u0026gt;journal-\u0026gt;j_journal,\n\nAdding osb-\u0026gt;journal checks will prevent null-ptr-deref during the above\nexecution path.(CVE-2025-39842)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()\n\nIn __iodyn_find_io_region(), pcmcia_make_resource() is assigned to\nres and used in pci_bus_alloc_resource(). There is a dereference of res\nin pci_bus_alloc_resource(), which could lead to a NULL pointer\ndereference on failure of pcmcia_make_resource().\n\nFix this bug by adding a check of res.(CVE-2025-39846)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: vhci: Prevent use-after-free by removing debugfs files early\n\nMove the creation of debugfs files into a dedicated function, and ensure\nthey are explicitly removed during vhci_release(), before associated\ndata structures are freed.\n\nPreviously, debugfs files such as \u0026quot;force_suspend\u0026quot;, \u0026quot;force_wakeup\u0026quot;, and\nothers were created under hdev-\u0026gt;debugfs but not removed in\nvhci_release(). Since vhci_release() frees the backing vhci_data\nstructure, any access to these files after release would result in\nuse-after-free errors.\n\nAlthough hdev-\u0026gt;debugfs is later freed in hci_release_dev(), user can\naccess files after vhci_data is freed but before hdev-\u0026gt;debugfs is\nreleased.(CVE-2025-39861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work\n\nThe brcmf_btcoex_detach() only shuts down the btcoex timer, if the\nflag timer_on is false. However, the brcmf_btcoex_timerfunc(), which\nruns as timer handler, sets timer_on to false. This creates critical\nrace conditions:\n\n1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()\nis executing, it may observe timer_on as false and skip the call to\ntimer_shutdown_sync().\n\n2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info\nworker after the cancel_work_sync() has been executed, resulting in\nuse-after-free bugs.\n\nThe use-after-free bugs occur in two distinct scenarios, depending on\nthe timing of when the brcmf_btcoex_info struct is freed relative to\nthe execution of its worker thread.\n\nScenario 1: Freed before the worker is scheduled\n\nThe brcmf_btcoex_info is deallocated before the worker is scheduled.\nA race condition can occur when schedule_work(\u0026amp;bt_local-\u0026gt;work) is\ncalled after the target memory has been freed. The sequence of events\nis detailed below:\n\nCPU0 | CPU1\nbrcmf_btcoex_detach | brcmf_btcoex_timerfunc\n | bt_local-\u0026gt;timer_on = false;\n if (cfg-\u0026gt;btcoex-\u0026gt;timer_on) |\n ... |\n cancel_work_sync(); |\n ... |\n kfree(cfg-\u0026gt;btcoex); // FREE |\n | schedule_work(\u0026amp;bt_local-\u0026gt;work); // USE\n\nScenario 2: Freed after the worker is scheduled\n\nThe brcmf_btcoex_info is freed after the worker has been scheduled\nbut before or during its execution. In this case, statements within\nthe brcmf_btcoex_handler() \u2014 such as the container_of macro and\nsubsequent dereferences of the brcmf_btcoex_info object will cause\na use-after-free access. The following timeline illustrates this\nscenario:\n\nCPU0 | CPU1\nbrcmf_btcoex_detach | brcmf_btcoex_timerfunc\n | bt_local-\u0026gt;timer_on = false;\n if (cfg-\u0026gt;btcoex-\u0026gt;timer_on) |\n ... |\n cancel_work_sync(); |\n ... | schedule_work(); // Reschedule\n |\n kfree(cfg-\u0026gt;btcoex); // FREE | brcmf_btcoex_handler() // Worker\n /* | btci = container_of(....); // USE\n The kfree() above could | ...\n also occur at any point | btci-\u0026gt; // USE\n during the worker\u0026apos;s execution|\n */ |\n\nTo resolve the race conditions, drop the conditional check and call\ntimer_shutdown_sync() directly. It can deactivate the timer reliably,\nregardless of its current state. Once stopped, the timer_on state is\nthen set to false.(CVE-2025-39863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()\n\nPatch series \u0026quot;mm/damon: avoid divide-by-zero in DAMON module\u0026apos;s parameters\napplication\u0026quot;.\n\nDAMON\u0026apos;s RECLAIM and LRU_SORT modules perform no validation on\nuser-configured parameters during application, which may lead to\ndivision-by-zero errors.\n\nAvoid the divide-by-zero by adding validation checks when DAMON modules\nattempt to apply the parameters.\n\n\nThis patch (of 2):\n\nDuring the calculation of \u0026apos;hot_thres\u0026apos; and \u0026apos;cold_thres\u0026apos;, either\n\u0026apos;sample_interval\u0026apos; or \u0026apos;aggr_interval\u0026apos; is used as the divisor, which may\nlead to division-by-zero errors. Fix it by directly returning -EINVAL\nwhen such a case occurs. Additionally, since \u0026apos;aggr_interval\u0026apos; is already\nrequired to be set no smaller than \u0026apos;sample_interval\u0026apos; in damon_set_attrs(),\nonly the case where \u0026apos;sample_interval\u0026apos; is zero needs to be checked.(CVE-2025-39909)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()\n\nWhen creating a new scheme of DAMON_RECLAIM, the calculation of\n\u0026apos;min_age_region\u0026apos; uses \u0026apos;aggr_interval\u0026apos; as the divisor, which may lead to\ndivision-by-zero errors. Fix it by directly returning -EINVAL when such a\ncase occurs.(CVE-2025-39916)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm: bridge: anx7625: Fix NULL pointer dereference with early IRQ\n\nIf the interrupt occurs before resource initialization is complete, the\ninterrupt handler/worker may access uninitialized data such as the I2C\ntcpc_client device, potentially leading to NULL pointer dereference.(CVE-2025-39934)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wilc1000: avoid buffer overflow in WID string configuration\n\nFix the following copy overflow warning identified by Smatch checker.\n\n drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()\n error: \u0026apos;__memcpy()\u0026apos; \u0026apos;cfg-\u0026gt;s[i]-\u0026gt;str\u0026apos; copy overflow (512 vs 65537)\n\nThis patch introduces size check before accessing the memory buffer.\nThe checks are base on the WID type of received data from the firmware.\nFor WID string configuration, the size limit is determined by individual\nelement size in \u0026apos;struct wilc_cfg_str_vals\u0026apos; that is maintained in \u0026apos;len\u0026apos; field\nof \u0026apos;struct wilc_cfg_str\u0026apos;.(CVE-2025-39952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn\u0026apos;t valid\n\nSkip the WRMSR and HLT fastpaths in SVM\u0026apos;s VM-Exit handler if the next RIP\nisn\u0026apos;t valid, e.g. because KVM is running with nrips=false. SVM must\ndecode and emulate to skip the instruction if the CPU doesn\u0026apos;t provide the\nnext RIP, and getting the instruction bytes to decode requires reading\nguest memory. Reading guest memory through the emulator can fault, i.e.\ncan sleep, which is disallowed since the fastpath handlers run with IRQs\ndisabled.\n\n BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106\n in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu\n preempt_count: 1, expected: 0\n INFO: lockdep is turned off.\n irq event stamp: 30580\n hardirqs last enabled at (30579): [\u0026lt;ffffffffc08b2527\u0026gt;] vcpu_run+0x1787/0x1db0 [kvm]\n hardirqs last disabled at (30580): [\u0026lt;ffffffffb4f62e32\u0026gt;] __schedule+0x1e2/0xed0\n softirqs last enabled at (30570): [\u0026lt;ffffffffb4247a64\u0026gt;] fpu_swap_kvm_fpstate+0x44/0x210\n softirqs last disabled at (30568): [\u0026lt;ffffffffb4247a64\u0026gt;] fpu_swap_kvm_fpstate+0x44/0x210\n CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE\n Tainted: [U]=USER\n Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7d/0xb0\n __might_resched+0x271/0x290\n __might_fault+0x28/0x80\n kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm]\n kvm_fetch_guest_virt+0x92/0xc0 [kvm]\n __do_insn_fetch_bytes+0xf3/0x1e0 [kvm]\n x86_decode_insn+0xd1/0x1010 [kvm]\n x86_emulate_instruction+0x105/0x810 [kvm]\n __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd]\n handle_fastpath_invd+0xc4/0x1a0 [kvm]\n vcpu_run+0x11a1/0x1db0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm]\n kvm_vcpu_ioctl+0x578/0x6a0 [kvm]\n __se_sys_ioctl+0x6d/0xb0\n do_syscall_64+0x8a/0x2c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f479d57a94b\n \u0026lt;/TASK\u0026gt;\n\nNote, this is essentially a reapply of commit 5c30e8101e8d (\u0026quot;KVM: SVM:\nSkip WRMSR fastpath on VM-Exit if next RIP isn\u0026apos;t valid\u0026quot;), but with\ndifferent justification (KVM now grabs SRCU when skipping the instruction\nfor other reasons).(CVE-2025-40038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential null deref in ext4_mb_init()\n\nIn ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called\nwhen sbi-\u0026gt;s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo\nslab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy()\nlacks null pointer checking, this leads to a null pointer dereference.\n\n==================================================================\nEXT4-fs: no memory for groupinfo slab cache\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: Oops: 0002 [#1] SMP PTI\nCPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none)\nRIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40\nCall Trace:\n \u0026lt;TASK\u0026gt;\n xa_destroy+0x61/0x130\n ext4_mb_init+0x483/0x540\n __ext4_fill_super+0x116d/0x17b0\n ext4_fill_super+0xd3/0x280\n get_tree_bdev_flags+0x132/0x1d0\n vfs_get_tree+0x29/0xd0\n do_new_mount+0x197/0x300\n __x64_sys_mount+0x116/0x150\n do_syscall_64+0x50/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n==================================================================\n\nTherefore, add necessary null check to ext4_mb_avg_fragment_size_destroy()\nto prevent this issue. The same fix is also applied to\next4_mb_largest_free_orders_destroy().(CVE-2025-40119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nEDAC/i10nm: Skip DIMM enumeration on a disabled memory controller\n\nWhen loading the i10nm_edac driver on some Intel Granite Rapids servers,\na call trace may appear as follows:\n\n UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16\n shift exponent -66 is negative\n ...\n __ubsan_handle_shift_out_of_bounds+0x1e3/0x390\n skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]\n i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]\n skx_register_mci+0x159/0x220 [skx_edac_common]\n i10nm_init+0xcb0/0x1ff0 [i10nm_edac]\n ...\n\nThis occurs because some BIOS may disable a memory controller if there\naren\u0026apos;t any memory DIMMs populated on this memory controller. The DIMMMTR\nregister of this disabled memory controller contains the invalid value\n~0, resulting in the call trace above.\n\nFix this call trace by skipping DIMM enumeration on a disabled memory\ncontroller.(CVE-2025-40157)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: quota: create dedicated workqueue for quota_release_work\n\nThere is a kernel panic due to WARN_ONCE when panic_on_warn is set.\n\nThis issue occurs when writeback is triggered due to sync call for an\nopened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance\nis needed at sync path, flush for quota_release_work is triggered.\nBy default quota_release_work is queued to \u0026quot;events_unbound\u0026quot; queue which\ndoes not have WQ_MEM_RECLAIM flag. During f2fs balance \u0026quot;writeback\u0026quot;\nworkqueue tries to flush quota_release_work causing kernel panic due to\nMEM_RECLAIM flag mismatch errors.\n\nThis patch creates dedicated workqueue with WQ_MEM_RECLAIM flag\nfor work quota_release_work.\n\n------------[ cut here ]------------\nWARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148\nCall trace:\n check_flush_dependency+0x13c/0x148\n __flush_work+0xd0/0x398\n flush_delayed_work+0x44/0x5c\n dquot_writeback_dquots+0x54/0x318\n f2fs_do_quota_sync+0xb8/0x1a8\n f2fs_write_checkpoint+0x3cc/0x99c\n f2fs_gc+0x190/0x750\n f2fs_balance_fs+0x110/0x168\n f2fs_write_single_data_page+0x474/0x7dc\n f2fs_write_data_pages+0x7d0/0xd0c\n do_writepages+0xe0/0x2f4\n __writeback_single_inode+0x44/0x4ac\n writeback_sb_inodes+0x30c/0x538\n wb_writeback+0xf4/0x440\n wb_workfn+0x128/0x5d4\n process_scheduled_works+0x1c4/0x45c\n worker_thread+0x32c/0x3e8\n kthread+0x11c/0x1b0\n ret_from_fork+0x10/0x20\nKernel panic - not syncing: kernel: panic_on_warn set ...(CVE-2025-40196)\n\nIn the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try(). v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().(CVE-2025-40207)",
"id": "OESA-2025-2695",
"modified": "2026-08-06T11:09:49Z",
"published": "2025-11-22T11:09:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2695"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23140"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38011"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38132"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38155"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38167"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38206"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38326"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38348"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38640"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38696"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38718"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39711"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39716"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39719"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39767"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39781"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39842"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39846"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39909"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40038"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40196"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40207"
}
],
"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-2025-23140",
"CVE-2025-38011",
"CVE-2025-38059",
"CVE-2025-38132",
"CVE-2025-38155",
"CVE-2025-38167",
"CVE-2025-38206",
"CVE-2025-38326",
"CVE-2025-38348",
"CVE-2025-38640",
"CVE-2025-38696",
"CVE-2025-38718",
"CVE-2025-38734",
"CVE-2025-39693",
"CVE-2025-39711",
"CVE-2025-39716",
"CVE-2025-39719",
"CVE-2025-39726",
"CVE-2025-39767",
"CVE-2025-39781",
"CVE-2025-39794",
"CVE-2025-39808",
"CVE-2025-39842",
"CVE-2025-39846",
"CVE-2025-39861",
"CVE-2025-39863",
"CVE-2025-39909",
"CVE-2025-39916",
"CVE-2025-39934",
"CVE-2025-39952",
"CVE-2025-40038",
"CVE-2025-40119",
"CVE-2025-40157",
"CVE-2025-40196",
"CVE-2025-40207"
]
}
oesa-2025-2696
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:
misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error
After devm_request_irq() fails with error in pci_endpoint_test_request_irq(), the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs have been released.
However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message:
remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c
To solve this issue, set the number of remaining IRQs to test->num_irqs, and release IRQs in advance by calling pci_endpoint_test_release_irq().
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: csa unmap use uninterruptible lock
After process exit to unmap csa and free GPU vm, if signal is accepted and then waiting to take vm lock is interrupted and return, it causes memory leaking and below warning backtrace.
Change to use uninterruptible wait lock fix the issue.
WARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525 amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu] Call Trace: <TASK> drm_file_free.part.0+0x1da/0x230 [drm] drm_close_helper.isra.0+0x65/0x70 [drm] drm_release+0x6a/0x120 [drm] amdgpu_drm_release+0x51/0x60 [amdgpu] __fput+0x9f/0x280 ____fput+0xe/0x20 task_work_run+0x67/0xa0 do_exit+0x217/0x3c0 do_group_exit+0x3b/0xb0 get_signal+0x14a/0x8d0 arch_do_signal_or_restart+0xde/0x100 exit_to_user_mode_loop+0xc1/0x1a0 exit_to_user_mode_prepare+0xf4/0x100 syscall_exit_to_user_mode+0x17/0x40 do_syscall_64+0x69/0xc0
(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)(CVE-2025-38011)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: avoid NULL pointer dereference if no valid csum tree
[BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace:
BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Call Trace: <TASK> scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e
[CAUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification.
Normally call sites utilizing csum tree will check the fs state flag NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.
This results in scrub to call btrfs_search_slot() on a NULL pointer and triggered above crash.
[FIX] Check both extent and csum tree root before doing any tree search.(CVE-2025-38059)
In the Linux kernel, the following vulnerability has been resolved:
coresight: holding cscfg_csdev_lock while removing cscfg from csdev
There'll be possible race scenario for coresight config:
CPU0 CPU1 (perf enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() <iterating config_csdev_list> cscfg_remove_owned_csdev_configs() // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock)
iterating config_csdev_list could be raced with config_csdev_list's entry delete.
To resolve this race , hold csdev->cscfg_csdev_lock() while cscfg_remove_owned_csdev_configs()(CVE-2025-38132)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()
devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference.
Prevent null pointer dereference in mt7915_mmio_wed_init().(CVE-2025-38155)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: handle hdr_first_de() return value
The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently.
Additionally, error handling for the return value already exists at other points where this function is called.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-38167)
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix double free in delayed_free
The double free could happen in the following path.
exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double free This patch set ->vol_util as NULL after freeing it.(CVE-2025-38206)
In the Linux kernel, the following vulnerability has been resolved:
aoe: clean device rq_list in aoedev_downdev()
An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue().(CVE-2025-38326)
In the Linux kernel, the following vulnerability has been resolved:
wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()
Robert Morris reported:
|If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common priv, | struct sk_buff skb) |{ | struct p54_hdr hdr = (struct p54_hdr ) skb->data; | struct p54_eeprom_lm86 eeprom = (struct p54_eeprom_lm86 ) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...]
The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun.
This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them.
The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default.(CVE-2025-38348)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disable migration in nf_hook_run_bpf().
syzbot reported that the netfilter bpf prog can be called without migration disabled in xmit path.
Then the assertion in __bpf_prog_run() fails, triggering the splat below. [0]
Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().
[0]: BUG: assuming non migratable context at ./include/linux/filter.h:703 in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session 3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241 CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpf_prog_run include/linux/filter.h:703 [inline] bpf_prog_run include/linux/filter.h:725 [inline] nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623 nf_hook+0x370/0x680 include/linux/netfilter.h:272 NF_HOOK_COND include/linux/netfilter.h:305 [inline] ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:459 [inline] ip_local_out net/ipv4/ip_output.c:129 [inline] __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline] tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021 tcp_push+0x225/0x700 net/ipv4/tcp.c:759 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x4aa/0x5b0 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x6c7/0x1150 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe7d365d407 Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP:(CVE-2025-38640)
In the Linux kernel, the following vulnerability has been resolved:
MIPS: Don't crash in stack_top() for tasks without ABI or vDSO
Not all tasks have an ABI associated or vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL ABI pointer and crash.
This can for example happen when using kunit:
mips_stack_top+0x28/0xc0
arch_pick_mmap_layout+0x190/0x220
kunit_vm_mmap_init+0xf8/0x138
__kunit_add_resource+0x40/0xa8
kunit_vm_mmap+0x88/0xd8
usercopy_test_init+0xb8/0x240
kunit_try_run_case+0x5c/0x1a8
kunit_generic_run_threadfn_adapter+0x28/0x50
kthread+0x118/0x240
ret_from_kernel_thread+0x14/0x1c
Only dereference the ABI point if it is set.
The GIC page is also included as it is specific to the vDSO. Also move the randomization adjustment into the same conditional.(CVE-2025-38696)
In the Linux kernel, the following vulnerability has been resolved:
sctp: linearize cloned gso packets in sctp_rcv
A cloned head skb still shares these frag skbs in fraglist with the original head skb. It's not safe to access these frag skbs.
syzbot reported two use-of-uninitialized-memory bugs caused by this:
BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]
and
BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]
This patch fixes it by linearizing cloned gso packets in sctp_rcv().(CVE-2025-38718)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix UAF on smcsk after smc_listen_out()
BPF CI testing report a UAF issue:
[ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: error_code(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] <TASK > [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? page_fault_oops+0x180/0x4c 0 [ 16.457508] ? __lock_acquire+0x3e6/0x249 0 [ 16.457801] ? exc_page_fault+0x68/0x20 0 [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0 [ 16.458389] ? smc_listen_work+0xc02/0x159 0 [ 16.458689] ? smc_listen_work+0xc02/0x159 0 [ 16.458987] ? lock_is_held_type+0x8f/0x10 0 [ 16.459284] process_one_work+0x1ea/0x6d 0 [ 16.459570] worker_thread+0x1c3/0x38 0 [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfx_kthread+0x10/0x1 0 [ 16.460640] ret_from_fork+0x31/0x5 0 [ 16.460896] ? __pfx_kthread+0x10/0x1 0 [ 16.461166] ret_from_fork_asm+0x1a/0x3 0 [ 16.461453] </TASK > [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590
The direct cause of this issue is that after smc_listen_out_connected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows:
smc_listen_work | userspace
lock_sock(sk) | smc_listen_out_connected() | | - smc_listen_out | | | - release_sock | | |- sk->sk_data_ready() | | fd = accept(); | close(fd); | - socket->sk = NULL; / newclcsock->sk is NULL now / SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk))
Since smc_listen_out_connected() will not fail, simply swapping the order of the code can easily fix this issue.(CVE-2025-38734)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid a NULL pointer dereference
[WHY] Although unlikely drm_atomic_get_new_connector_state() or drm_atomic_get_old_connector_state() can return NULL.
[HOW] Check returns before dereference.
(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)(CVE-2025-39693)
In the Linux kernel, the following vulnerability has been resolved:
media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls
Both the ACE and CSI driver are missing a mei_cldev_disable() call in their remove() function.
This causes the mei_cl client to stay part of the mei_device->file_list list even though its memory is freed by mei_cl_bus_dev_release() calling kfree(cldev->cl).
This leads to a use-after-free when mei_vsc_remove() runs mei_stop() which first removes all mei bus devices calling mei_ace_remove() and mei_csi_remove() followed by mei_cl_bus_dev_release() and then calls mei_cl_all_disconnect() which walks over mei_device->file_list dereferecing the just freed cldev->cl.
And mei_vsc_remove() it self is run at shutdown because of the platform_device_unregister(tp->pdev) in vsc_tp_shutdown()
When building a kernel with KASAN this leads to the following KASAN report:
[ 106.634504] ================================================================== [ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1 [ 106.634729] [ 106.634767] Tainted: [E]=UNSIGNED_MODULE [ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025 [ 106.634773] Call Trace: [ 106.634777] <TASK> ... [ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) [ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei [ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei [ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc [ 106.635066] platform_remove (drivers/base/platform.c:1424)
Add the missing mei_cldev_disable() calls so that the mei_cl gets removed from mei_device->file_list before it is freed to fix this.(CVE-2025-39711)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise __get_user() to probe user read access
Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call.
Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed.
Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm.(CVE-2025-39716)
In the Linux kernel, the following vulnerability has been resolved:
iio: imu: bno055: fix OOB access of hw_xlate array
Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c.
In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array.
By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length.(CVE-2025-39719)
In the Linux kernel, the following vulnerability has been resolved:
s390/ism: fix concurrency management in ism_cmd()
The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that.
This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well.
A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it.
On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.(CVE-2025-39726)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Optimize module load time by optimizing PLT/GOT counting
When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows:
rcu: INFO: rcu_sched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler+0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constant_timer_interrupt+0x64/0x80 [<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x30/0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158
After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock.
When loading a module, module_frob_arch_sections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the count_max_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity.
To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations.
After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace".
Using the default configuration to test some modules, the results are as follows:
Module Size ip_tables 36K fat 143K radeon 2.5MB amdgpu 16MB
Without this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098
With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 22 1221/84 amdgpu 45 4525/1098(CVE-2025-39767)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Drop WARN_ON_ONCE() from flush_cache_vmap
I have observed warning to occassionally trigger.(CVE-2025-39781)
In the Linux kernel, the following vulnerability has been resolved:
ARM: tegra: Use I/O memcpy to write to IRAM
Kasan crashes the kernel trying to check boundaries when using the normal memcpy.(CVE-2025-39794)
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()
in ntrig_report_version(), hdev parameter passed from hid_probe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usb_dev has invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned when usb_rcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58)
add null check logic to ntrig_report_version() before calling hid_to_usb_dev()(CVE-2025-39808)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: prevent release journal inode after journal shutdown
Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode().
ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal,
Adding osb->journal checks will prevent null-ptr-deref during the above execution path.(CVE-2025-39842)
In the Linux kernel, the following vulnerability has been resolved:
pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()
In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource().
Fix this bug by adding a check of res.(CVE-2025-39846)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: vhci: Prevent use-after-free by removing debugfs files early
Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed.
Previously, debugfs files such as "force_suspend", "force_wakeup", and others were created under hdev->debugfs but not removed in vhci_release(). Since vhci_release() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors.
Although hdev->debugfs is later freed in hci_release_dev(), user can access files after vhci_data is freed but before hdev->debugfs is released.(CVE-2025-39861)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work
The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions:
1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync().
2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs.
The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread.
Scenario 1: Freed before the worker is scheduled
The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below:
CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE
Scenario 2: Freed after the worker is scheduled
The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario:
CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker / | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| / |
To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.(CVE-2025-39863)
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()
Patch series "mm/damon: avoid divide-by-zero in DAMON module's parameters application".
DAMON's RECLAIM and LRU_SORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors.
Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters.
This patch (of 2):
During the calculation of 'hot_thres' and 'cold_thres', either 'sample_interval' or 'aggr_interval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggr_interval' is already required to be set no smaller than 'sample_interval' in damon_set_attrs(), only the case where 'sample_interval' is zero needs to be checked.(CVE-2025-39909)
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()
When creating a new scheme of DAMON_RECLAIM, the calculation of 'min_age_region' uses 'aggr_interval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.(CVE-2025-39916)
In the Linux kernel, the following vulnerability has been resolved:
drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ
If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.(CVE-2025-39934)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: avoid buffer overflow in WID string configuration
Fix the following copy overflow warning identified by Smatch checker.
drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)
This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.(CVE-2025-39952)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid
Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled.
BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [<ffffffffc08b2527>] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [<ffffffffb4f62e32>] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: <TASK> dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b </TASK>
Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons).(CVE-2025-40038)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential null deref in ext4_mb_init()
In ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called when sbi->s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo slab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy() lacks null pointer checking, this leads to a null pointer dereference.
================================================================== EXT4-fs: no memory for groupinfo slab cache BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP PTI CPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none) RIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40 Call Trace: <TASK> xa_destroy+0x61/0x130 ext4_mb_init+0x483/0x540 __ext4_fill_super+0x116d/0x17b0 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 do_new_mount+0x197/0x300 __x64_sys_mount+0x116/0x150 do_syscall_64+0x50/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================
Therefore, add necessary null check to ext4_mb_avg_fragment_size_destroy() to prevent this issue. The same fix is also applied to ext4_mb_largest_free_orders_destroy().(CVE-2025-40119)
In the Linux kernel, the following vulnerability has been resolved:
EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller
When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows:
UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ...
This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above.
Fix this call trace by skipping DIMM enumeration on a disabled memory controller.(CVE-2025-40157)
In the Linux kernel, the following vulnerability has been resolved:
fs: quota: create dedicated workqueue for quota_release_work
There is a kernel panic due to WARN_ONCE when panic_on_warn is set.
This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors.
This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work.
------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...(CVE-2025-40196)
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try(). v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().(CVE-2025-40207)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"perf-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-119.0.0.123.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-119.0.0.123.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"perf-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-119.0.0.123.oe2403sp2.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP2",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-119.0.0.123.oe2403sp2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmisc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error\n\nAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),\nthe pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs\nhave been released.\n\nHowever, some requested IRQs remain unreleased, so there are still\n/proc/irq/* entries remaining, and this results in WARN() with the\nfollowing message:\n\n remove_proc_entry: removing non-empty directory \u0026apos;irq/30\u0026apos;, leaking at least \u0026apos;pci-endpoint-test.0\u0026apos;\n WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c\n\nTo solve this issue, set the number of remaining IRQs to test-\u0026gt;num_irqs,\nand release IRQs in advance by calling pci_endpoint_test_release_irq().\n\n[kwilczynski: commit log](CVE-2025-23140)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: csa unmap use uninterruptible lock\n\nAfter process exit to unmap csa and free GPU vm, if signal is accepted\nand then waiting to take vm lock is interrupted and return, it causes\nmemory leaking and below warning backtrace.\n\nChange to use uninterruptible wait lock fix the issue.\n\nWARNING: CPU: 69 PID: 167800 at amd/amdgpu/amdgpu_kms.c:1525\n amdgpu_driver_postclose_kms+0x294/0x2a0 [amdgpu]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n drm_file_free.part.0+0x1da/0x230 [drm]\n drm_close_helper.isra.0+0x65/0x70 [drm]\n drm_release+0x6a/0x120 [drm]\n amdgpu_drm_release+0x51/0x60 [amdgpu]\n __fput+0x9f/0x280\n ____fput+0xe/0x20\n task_work_run+0x67/0xa0\n do_exit+0x217/0x3c0\n do_group_exit+0x3b/0xb0\n get_signal+0x14a/0x8d0\n arch_do_signal_or_restart+0xde/0x100\n exit_to_user_mode_loop+0xc1/0x1a0\n exit_to_user_mode_prepare+0xf4/0x100\n syscall_exit_to_user_mode+0x17/0x40\n do_syscall_64+0x69/0xc0\n\n(cherry picked from commit 7dbbfb3c171a6f63b01165958629c9c26abf38ab)(CVE-2025-38011)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: avoid NULL pointer dereference if no valid csum tree\n\n[BUG]\nWhen trying read-only scrub on a btrfs with rescue=idatacsums mount\noption, it will crash with the following call trace:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000208\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs]\n scrub_simple_mirror+0x175/0x290 [btrfs]\n scrub_stripe+0x5f7/0x6f0 [btrfs]\n scrub_chunk+0x9a/0x150 [btrfs]\n scrub_enumerate_chunks+0x333/0x660 [btrfs]\n btrfs_scrub_dev+0x23e/0x600 [btrfs]\n btrfs_ioctl+0x1dcf/0x2f80 [btrfs]\n __x64_sys_ioctl+0x97/0xc0\n do_syscall_64+0x4f/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[CAUSE]\nMount option \u0026quot;rescue=idatacsums\u0026quot; will completely skip loading the csum\ntree, so that any data read will not find any data csum thus we will\nignore data checksum verification.\n\nNormally call sites utilizing csum tree will check the fs state flag\nNO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.\n\nThis results in scrub to call btrfs_search_slot() on a NULL pointer\nand triggered above crash.\n\n[FIX]\nCheck both extent and csum tree root before doing any tree search.(CVE-2025-38059)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: holding cscfg_csdev_lock while removing cscfg from csdev\n\nThere\u0026apos;ll be possible race scenario for coresight config:\n\nCPU0 CPU1\n(perf enable) load module\n cscfg_load_config_sets()\n activate config. // sysfs\n (sys_active_cnt == 1)\n...\ncscfg_csdev_enable_active_config()\n lock(csdev-\u0026gt;cscfg_csdev_lock)\n deactivate config // sysfs\n (sys_activec_cnt == 0)\n cscfg_unload_config_sets()\n \u0026lt;iterating config_csdev_list\u0026gt; cscfg_remove_owned_csdev_configs()\n // here load config activate by CPU1\n unlock(csdev-\u0026gt;cscfg_csdev_lock)\n\niterating config_csdev_list could be raced with config_csdev_list\u0026apos;s\nentry delete.\n\nTo resolve this race , hold csdev-\u0026gt;cscfg_csdev_lock() while\ncscfg_remove_owned_csdev_configs()(CVE-2025-38132)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()\n\ndevm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init()\ndoes not check for this case, which results in a NULL pointer\ndereference.\n\nPrevent null pointer dereference in mt7915_mmio_wed_init().(CVE-2025-38155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: handle hdr_first_de() return value\n\nThe hdr_first_de() function returns a pointer to a struct NTFS_DE. This\npointer may be NULL. To handle the NULL error effectively, it is important\nto implement an error handler. This will help manage potential errors\nconsistently.\n\nAdditionally, error handling for the return value already exists at other\npoints where this function is called.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-38167)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix double free in delayed_free\n\nThe double free could happen in the following path.\n\nexfat_create_upcase_table()\n exfat_create_upcase_table() : return error\n exfat_free_upcase_table() : free -\u0026gt;vol_utbl\n exfat_load_default_upcase_table : return error\n exfat_kill_sb()\n delayed_free()\n exfat_free_upcase_table() \u0026lt;--------- double free\nThis patch set -\u0026gt;vol_util as NULL after freeing it.(CVE-2025-38206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naoe: clean device rq_list in aoedev_downdev()\n\nAn aoe device\u0026apos;s rq_list contains accepted block requests that are\nwaiting to be transmitted to the aoe target. This queue was added as\npart of the conversion to blk_mq. However, the queue was not cleaned out\nwhen an aoe device is downed which caused blk_mq_freeze_queue() to sleep\nindefinitely waiting for those requests to complete, causing a hang. This\nfix cleans out the queue before calling blk_mq_freeze_queue().(CVE-2025-38326)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\n\nRobert Morris reported:\n\n|If a malicious USB device pretends to be an Intersil p54 wifi\n|interface and generates an eeprom_readback message with a large\n|eeprom-\u0026gt;v1.len, p54_rx_eeprom_readback() will copy data from the\n|message beyond the end of priv-\u0026gt;eeprom.\n|\n|static void p54_rx_eeprom_readback(struct p54_common *priv,\n| struct sk_buff *skb)\n|{\n| struct p54_hdr *hdr = (struct p54_hdr *) skb-\u0026gt;data;\n| struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-\u0026gt;data;\n|\n| if (priv-\u0026gt;fw_var \u0026gt;= 0x509) {\n| memcpy(priv-\u0026gt;eeprom, eeprom-\u0026gt;v2.data,\n| le16_to_cpu(eeprom-\u0026gt;v2.len));\n| } else {\n| memcpy(priv-\u0026gt;eeprom, eeprom-\u0026gt;v1.data,\n| le16_to_cpu(eeprom-\u0026gt;v1.len));\n| }\n| [...]\n\nThe eeprom-\u0026gt;v{1,2}.len is set by the driver in p54_download_eeprom().\nThe device is supposed to provide the same length back to the driver.\nBut yes, it\u0026apos;s possible (like shown in the report) to alter the value\nto something that causes a crash/panic due to overrun.\n\nThis patch addresses the issue by adding the size to the common device\ncontext, so p54_rx_eeprom_readback no longer relies on possibly tampered\nvalues... That said, it also checks if the \u0026quot;firmware\u0026quot; altered the value\nand no longer copies them.\n\nThe one, small saving grace is: Before the driver tries to read the eeprom,\nit needs to upload \u0026gt;a\u0026lt; firmware. the vendor firmware has a proprietary\nlicense and as a reason, it is not present on most distributions by\ndefault.(CVE-2025-38348)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Disable migration in nf_hook_run_bpf().\n\nsyzbot reported that the netfilter bpf prog can be called without\nmigration disabled in xmit path.\n\nThen the assertion in __bpf_prog_run() fails, triggering the splat\nbelow. [0]\n\nLet\u0026apos;s use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().\n\n[0]:\nBUG: assuming non migratable context at ./include/linux/filter.h:703\nin_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session\n3 locks held by sshd-session/5829:\n #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline]\n #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241\nCPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n __cant_migrate kernel/sched/core.c:8860 [inline]\n __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834\n __bpf_prog_run include/linux/filter.h:703 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20\n nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]\n nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623\n nf_hook+0x370/0x680 include/linux/netfilter.h:272\n NF_HOOK_COND include/linux/netfilter.h:305 [inline]\n ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433\n dst_output include/net/dst.h:459 [inline]\n ip_local_out net/ipv4/ip_output.c:129 [inline]\n __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527\n __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479\n tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline]\n tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838\n __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021\n tcp_push+0x225/0x700 net/ipv4/tcp.c:759\n tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359\n tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396\n inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n sock_write_iter+0x4aa/0x5b0 net/socket.c:1131\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x6c7/0x1150 fs/read_write.c:686\n ksys_write+0x1f8/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe7d365d407\nCode: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u0026lt;5b\u0026gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff\nRSP:(CVE-2025-38640)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Don\u0026apos;t crash in stack_top() for tasks without ABI or vDSO\n\nNot all tasks have an ABI associated or vDSO mapped,\nfor example kthreads never do.\nIf such a task ever ends up calling stack_top(), it will derefence the\nNULL ABI pointer and crash.\n\nThis can for example happen when using kunit:\n\n mips_stack_top+0x28/0xc0\n arch_pick_mmap_layout+0x190/0x220\n kunit_vm_mmap_init+0xf8/0x138\n __kunit_add_resource+0x40/0xa8\n kunit_vm_mmap+0x88/0xd8\n usercopy_test_init+0xb8/0x240\n kunit_try_run_case+0x5c/0x1a8\n kunit_generic_run_threadfn_adapter+0x28/0x50\n kthread+0x118/0x240\n ret_from_kernel_thread+0x14/0x1c\n\nOnly dereference the ABI point if it is set.\n\nThe GIC page is also included as it is specific to the vDSO.\nAlso move the randomization adjustment into the same conditional.(CVE-2025-38696)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: linearize cloned gso packets in sctp_rcv\n\nA cloned head skb still shares these frag skbs in fraglist with the\noriginal head skb. It\u0026apos;s not safe to access these frag skbs.\n\nsyzbot reported two use-of-uninitialized-memory bugs caused by this:\n\n BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211\n sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211\n sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998\n sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88\n sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331\n sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122\n __release_sock+0x1da/0x330 net/core/sock.c:3106\n release_sock+0x6b/0x250 net/core/sock.c:3660\n sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360\n sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885\n sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031\n inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:718 [inline]\n\nand\n\n BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987\n sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987\n sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88\n sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331\n sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n __release_sock+0x1d3/0x330 net/core/sock.c:3213\n release_sock+0x6b/0x270 net/core/sock.c:3767\n sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367\n sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886\n sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032\n inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n\nThis patch fixes it by linearizing cloned gso packets in sctp_rcv().(CVE-2025-38718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix UAF on smcsk after smc_listen_out()\n\nBPF CI testing report a UAF issue:\n\n [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0\n [ 16.447134] #PF: supervisor read access in kernel mod e\n [ 16.447516] #PF: error_code(0x0000) - not-present pag e\n [ 16.447878] PGD 0 P4D 0\n [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I\n [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2\n [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E\n [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4\n [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k\n [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0\n [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6\n [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0\n [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0\n [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5\n [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0\n [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0\n [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0\n [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3\n [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0\n [ 16.456459] PKRU: 5555555 4\n [ 16.456654] Call Trace :\n [ 16.456832] \u0026lt;TASK \u0026gt;\n [ 16.456989] ? __die+0x23/0x7 0\n [ 16.457215] ? page_fault_oops+0x180/0x4c 0\n [ 16.457508] ? __lock_acquire+0x3e6/0x249 0\n [ 16.457801] ? exc_page_fault+0x68/0x20 0\n [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0\n [ 16.458389] ? smc_listen_work+0xc02/0x159 0\n [ 16.458689] ? smc_listen_work+0xc02/0x159 0\n [ 16.458987] ? lock_is_held_type+0x8f/0x10 0\n [ 16.459284] process_one_work+0x1ea/0x6d 0\n [ 16.459570] worker_thread+0x1c3/0x38 0\n [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0\n [ 16.460144] kthread+0xe0/0x11 0\n [ 16.460372] ? __pfx_kthread+0x10/0x1 0\n [ 16.460640] ret_from_fork+0x31/0x5 0\n [ 16.460896] ? __pfx_kthread+0x10/0x1 0\n [ 16.461166] ret_from_fork_asm+0x1a/0x3 0\n [ 16.461453] \u0026lt;/TASK \u0026gt;\n [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ]\n [ 16.462134] CR2: 000000000000003 0\n [ 16.462380] ---[ end trace 0000000000000000 ]---\n [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590\n\nThe direct cause of this issue is that after smc_listen_out_connected(),\nnewclcsock-\u0026gt;sk may be NULL since it will releases the smcsk. Therefore,\nif the application closes the socket immediately after accept,\nnewclcsock-\u0026gt;sk can be NULL. A possible execution order could be as\nfollows:\n\nsmc_listen_work | userspace\n-----------------------------------------------------------------\nlock_sock(sk) |\nsmc_listen_out_connected() |\n| \\- smc_listen_out |\n| | \\- release_sock |\n | |- sk-\u0026gt;sk_data_ready() |\n | fd = accept();\n | close(fd);\n | \\- socket-\u0026gt;sk = NULL;\n/* newclcsock-\u0026gt;sk is NULL now */\nSMC_STAT_SERV_SUCC_INC(sock_net(newclcsock-\u0026gt;sk))\n\nSince smc_listen_out_connected() will not fail, simply swapping the order\nof the code can easily fix this issue.(CVE-2025-38734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Avoid a NULL pointer dereference\n\n[WHY]\nAlthough unlikely drm_atomic_get_new_connector_state() or\ndrm_atomic_get_old_connector_state() can return NULL.\n\n[HOW]\nCheck returns before dereference.\n\n(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)(CVE-2025-39693)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls\n\nBoth the ACE and CSI driver are missing a mei_cldev_disable() call in\ntheir remove() function.\n\nThis causes the mei_cl client to stay part of the mei_device-\u0026gt;file_list\nlist even though its memory is freed by mei_cl_bus_dev_release() calling\nkfree(cldev-\u0026gt;cl).\n\nThis leads to a use-after-free when mei_vsc_remove() runs mei_stop()\nwhich first removes all mei bus devices calling mei_ace_remove() and\nmei_csi_remove() followed by mei_cl_bus_dev_release() and then calls\nmei_cl_all_disconnect() which walks over mei_device-\u0026gt;file_list dereferecing\nthe just freed cldev-\u0026gt;cl.\n\nAnd mei_vsc_remove() it self is run at shutdown because of the\nplatform_device_unregister(tp-\u0026gt;pdev) in vsc_tp_shutdown()\n\nWhen building a kernel with KASAN this leads to the following KASAN report:\n\n[ 106.634504] ==================================================================\n[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei\n[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1\n[ 106.634729]\n[ 106.634767] Tainted: [E]=UNSIGNED_MODULE\n[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025\n[ 106.634773] Call Trace:\n[ 106.634777] \u0026lt;TASK\u0026gt;\n...\n[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)\n[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei\n[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei\n[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei\n...\n[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei\n[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc\n[ 106.635066] platform_remove (drivers/base/platform.c:1424)\n\nAdd the missing mei_cldev_disable() calls so that the mei_cl gets removed\nfrom mei_device-\u0026gt;file_list before it is freed to fix this.(CVE-2025-39711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise __get_user() to probe user read access\n\nBecause of the way read access support is implemented, read access\ninterruptions are only triggered at privilege levels 2 and 3. The\nkernel executes at privilege level 0, so __get_user() never triggers\na read access interruption (code 26). Thus, it is currently possible\nfor user code to access a read protected address via a system call.\n\nFix this by probing read access rights at privilege level 3 (PRIV_USER)\nand setting __gu_err to -EFAULT (-14) if access isn\u0026apos;t allowed.\n\nNote the cmpiclr instruction does a 32-bit compare because COND macro\ndoesn\u0026apos;t work inside asm.(CVE-2025-39716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: bno055: fix OOB access of hw_xlate array\n\nFix a potential out-of-bounds array access of the hw_xlate array in\nbno055.c.\n\nIn bno055_get_regmask(), hw_xlate was iterated over the length of the\nvals array instead of the length of the hw_xlate array. In the case of\nbno055_gyr_scale, the vals array is larger than the hw_xlate array,\nso this could result in an out-of-bounds access. In practice, this\nshouldn\u0026apos;t happen though because a match should always be found which\nbreaks out of the for loop before it iterates beyond the end of the\nhw_xlate array.\n\nBy adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be\nsure we are iterating over the correct length.(CVE-2025-39719)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/ism: fix concurrency management in ism_cmd()\n\nThe s390x ISM device data sheet clearly states that only one\nrequest-response sequence is allowable per ISM function at any point in\ntime. Unfortunately as of today the s390/ism driver in Linux does not\nhonor that requirement. This patch aims to rectify that.\n\nThis problem was discovered based on Aliaksei\u0026apos;s bug report which states\nthat for certain workloads the ISM functions end up entering error state\n(with PEC 2 as seen from the logs) after a while and as a consequence\nconnections handled by the respective function break, and for future\nconnection requests the ISM device is not considered -- given it is in a\ndysfunctional state. During further debugging PEC 3A was observed as\nwell.\n\nA kernel message like\n[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a\nis a reliable indicator of the stated function entering error state\nwith PEC 2. Let me also point out that a kernel message like\n[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery\nis a reliable indicator that the ISM function won\u0026apos;t be auto-recovered\nbecause the ISM driver currently lacks support for it.\n\nOn a technical level, without this synchronization, commands (inputs to\nthe FW) may be partially or fully overwritten (corrupted) by another CPU\ntrying to issue commands on the same function. There is hard evidence that\nthis can lead to DMB token values being used as DMB IOVAs, leading to\nPEC 2 PCI events indicating invalid DMA. But this is only one of the\nfailure modes imaginable. In theory even completely losing one command\nand executing another one twice and then trying to interpret the outputs\nas if the command we intended to execute was actually executed and not\nthe other one is also possible. Frankly, I don\u0026apos;t feel confident about\nproviding an exhaustive list of possible consequences.(CVE-2025-39726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Optimize module load time by optimizing PLT/GOT counting\n\nWhen enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and\nCONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,\nthe relevant logs are as follows:\n\nrcu: INFO: rcu_sched self-detected stall on CPU\n...\nCall Trace:\n[\u0026lt;900000000024f9e4\u0026gt;] show_stack+0x5c/0x180\n[\u0026lt;90000000002482f4\u0026gt;] dump_stack_lvl+0x94/0xbc\n[\u0026lt;9000000000224544\u0026gt;] rcu_dump_cpu_stacks+0x1fc/0x280\n[\u0026lt;900000000037ac80\u0026gt;] rcu_sched_clock_irq+0x720/0xf88\n[\u0026lt;9000000000396c34\u0026gt;] update_process_times+0xb4/0x150\n[\u0026lt;90000000003b2474\u0026gt;] tick_nohz_handler+0xf4/0x250\n[\u0026lt;9000000000397e28\u0026gt;] __hrtimer_run_queues+0x1d0/0x428\n[\u0026lt;9000000000399b2c\u0026gt;] hrtimer_interrupt+0x214/0x538\n[\u0026lt;9000000000253634\u0026gt;] constant_timer_interrupt+0x64/0x80\n[\u0026lt;9000000000349938\u0026gt;] __handle_irq_event_percpu+0x78/0x1a0\n[\u0026lt;9000000000349a78\u0026gt;] handle_irq_event_percpu+0x18/0x88\n[\u0026lt;9000000000354c00\u0026gt;] handle_percpu_irq+0x90/0xf0\n[\u0026lt;9000000000348c74\u0026gt;] handle_irq_desc+0x94/0xb8\n[\u0026lt;9000000001012b28\u0026gt;] handle_cpu_irq+0x68/0xa0\n[\u0026lt;9000000001def8c0\u0026gt;] handle_loongarch_irq+0x30/0x48\n[\u0026lt;9000000001def958\u0026gt;] do_vint+0x80/0xd0\n[\u0026lt;9000000000268a0c\u0026gt;] kasan_mem_to_shadow.part.0+0x2c/0x2a0\n[\u0026lt;90000000006344f4\u0026gt;] __asan_load8+0x4c/0x120\n[\u0026lt;900000000025c0d0\u0026gt;] module_frob_arch_sections+0x5c8/0x6b8\n[\u0026lt;90000000003895f0\u0026gt;] load_module+0x9e0/0x2958\n[\u0026lt;900000000038b770\u0026gt;] __do_sys_init_module+0x208/0x2d0\n[\u0026lt;9000000001df0c34\u0026gt;] do_syscall+0x94/0x190\n[\u0026lt;900000000024d6fc\u0026gt;] handle_syscall+0xbc/0x158\n\nAfter analysis, this is because the slow speed of loading the amdgpu\nmodule leads to the long time occupation of the cpu and then the soft\ndeadlock.\n\nWhen loading a module, module_frob_arch_sections() tries to figure out\nthe number of PLTs/GOTs that will be needed to handle all the RELAs. It\nwill call the count_max_entries() to find in an out-of-order date which\ncounting algorithm has O(n^2) complexity.\n\nTo make it faster, we sort the relocation list by info and addend. That\nway, to check for a duplicate relocation, it just needs to compare with\nthe previous entry. This reduces the complexity of the algorithm to O(n\n log n), as done in commit d4e0340919fb (\u0026quot;arm64/module: Optimize module\nload time by optimizing PLT counting\u0026quot;). This gives sinificant reduction\nin module load time for modules with large number of relocations.\n\nAfter applying this patch, the soft deadlock problem has been solved,\nand the kernel starts normally without \u0026quot;Call Trace\u0026quot;.\n\nUsing the default configuration to test some modules, the results are as\nfollows:\n\nModule Size\nip_tables 36K\nfat 143K\nradeon 2.5MB\namdgpu 16MB\n\nWithout this patch:\nModule Module load time (ms)\tCount(PLTs/GOTs)\nip_tables 18\t\t\t\t59/6\nfat 0\t\t\t\t162/14\nradeon 54\t\t\t\t1221/84\namdgpu 1411\t\t\t4525/1098\n\nWith this patch:\nModule Module load time (ms)\tCount(PLTs/GOTs)\nip_tables 18\t\t\t\t59/6\nfat 0\t\t\t\t162/14\nradeon 22\t\t\t\t1221/84\namdgpu 45\t\t\t\t4525/1098(CVE-2025-39767)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Drop WARN_ON_ONCE() from flush_cache_vmap\n\nI have observed warning to occassionally trigger.(CVE-2025-39781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: tegra: Use I/O memcpy to write to IRAM\n\nKasan crashes the kernel trying to check boundaries when using the\nnormal memcpy.(CVE-2025-39794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()\n\nin ntrig_report_version(), hdev parameter passed from hid_probe().\nsending descriptor to /dev/uhid can make hdev-\u0026gt;dev.parent-\u0026gt;parent to null\nif hdev-\u0026gt;dev.parent-\u0026gt;parent is null, usb_dev has\ninvalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned\nwhen usb_rcvctrlpipe() use usb_dev,it trigger\npage fault error for address(0xffffffffffffff58)\n\nadd null check logic to ntrig_report_version()\nbefore calling hid_to_usb_dev()(CVE-2025-39808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: prevent release journal inode after journal shutdown\n\nBefore calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already\nbeen executed in ocfs2_dismount_volume(), so osb-\u0026gt;journal must be NULL. \nTherefore, the following calltrace will inevitably fail when it reaches\njbd2_journal_release_jbd_inode().\n\nocfs2_dismount_volume()-\u0026gt;\n ocfs2_delete_osb()-\u0026gt;\n ocfs2_free_slot_info()-\u0026gt;\n __ocfs2_free_slot_info()-\u0026gt;\n evict()-\u0026gt;\n ocfs2_evict_inode()-\u0026gt;\n ocfs2_clear_inode()-\u0026gt;\n\t jbd2_journal_release_jbd_inode(osb-\u0026gt;journal-\u0026gt;j_journal,\n\nAdding osb-\u0026gt;journal checks will prevent null-ptr-deref during the above\nexecution path.(CVE-2025-39842)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()\n\nIn __iodyn_find_io_region(), pcmcia_make_resource() is assigned to\nres and used in pci_bus_alloc_resource(). There is a dereference of res\nin pci_bus_alloc_resource(), which could lead to a NULL pointer\ndereference on failure of pcmcia_make_resource().\n\nFix this bug by adding a check of res.(CVE-2025-39846)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: vhci: Prevent use-after-free by removing debugfs files early\n\nMove the creation of debugfs files into a dedicated function, and ensure\nthey are explicitly removed during vhci_release(), before associated\ndata structures are freed.\n\nPreviously, debugfs files such as \u0026quot;force_suspend\u0026quot;, \u0026quot;force_wakeup\u0026quot;, and\nothers were created under hdev-\u0026gt;debugfs but not removed in\nvhci_release(). Since vhci_release() frees the backing vhci_data\nstructure, any access to these files after release would result in\nuse-after-free errors.\n\nAlthough hdev-\u0026gt;debugfs is later freed in hci_release_dev(), user can\naccess files after vhci_data is freed but before hdev-\u0026gt;debugfs is\nreleased.(CVE-2025-39861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work\n\nThe brcmf_btcoex_detach() only shuts down the btcoex timer, if the\nflag timer_on is false. However, the brcmf_btcoex_timerfunc(), which\nruns as timer handler, sets timer_on to false. This creates critical\nrace conditions:\n\n1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()\nis executing, it may observe timer_on as false and skip the call to\ntimer_shutdown_sync().\n\n2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info\nworker after the cancel_work_sync() has been executed, resulting in\nuse-after-free bugs.\n\nThe use-after-free bugs occur in two distinct scenarios, depending on\nthe timing of when the brcmf_btcoex_info struct is freed relative to\nthe execution of its worker thread.\n\nScenario 1: Freed before the worker is scheduled\n\nThe brcmf_btcoex_info is deallocated before the worker is scheduled.\nA race condition can occur when schedule_work(\u0026amp;bt_local-\u0026gt;work) is\ncalled after the target memory has been freed. The sequence of events\nis detailed below:\n\nCPU0 | CPU1\nbrcmf_btcoex_detach | brcmf_btcoex_timerfunc\n | bt_local-\u0026gt;timer_on = false;\n if (cfg-\u0026gt;btcoex-\u0026gt;timer_on) |\n ... |\n cancel_work_sync(); |\n ... |\n kfree(cfg-\u0026gt;btcoex); // FREE |\n | schedule_work(\u0026amp;bt_local-\u0026gt;work); // USE\n\nScenario 2: Freed after the worker is scheduled\n\nThe brcmf_btcoex_info is freed after the worker has been scheduled\nbut before or during its execution. In this case, statements within\nthe brcmf_btcoex_handler() \u2014 such as the container_of macro and\nsubsequent dereferences of the brcmf_btcoex_info object will cause\na use-after-free access. The following timeline illustrates this\nscenario:\n\nCPU0 | CPU1\nbrcmf_btcoex_detach | brcmf_btcoex_timerfunc\n | bt_local-\u0026gt;timer_on = false;\n if (cfg-\u0026gt;btcoex-\u0026gt;timer_on) |\n ... |\n cancel_work_sync(); |\n ... | schedule_work(); // Reschedule\n |\n kfree(cfg-\u0026gt;btcoex); // FREE | brcmf_btcoex_handler() // Worker\n /* | btci = container_of(....); // USE\n The kfree() above could | ...\n also occur at any point | btci-\u0026gt; // USE\n during the worker\u0026apos;s execution|\n */ |\n\nTo resolve the race conditions, drop the conditional check and call\ntimer_shutdown_sync() directly. It can deactivate the timer reliably,\nregardless of its current state. Once stopped, the timer_on state is\nthen set to false.(CVE-2025-39863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()\n\nPatch series \u0026quot;mm/damon: avoid divide-by-zero in DAMON module\u0026apos;s parameters\napplication\u0026quot;.\n\nDAMON\u0026apos;s RECLAIM and LRU_SORT modules perform no validation on\nuser-configured parameters during application, which may lead to\ndivision-by-zero errors.\n\nAvoid the divide-by-zero by adding validation checks when DAMON modules\nattempt to apply the parameters.\n\n\nThis patch (of 2):\n\nDuring the calculation of \u0026apos;hot_thres\u0026apos; and \u0026apos;cold_thres\u0026apos;, either\n\u0026apos;sample_interval\u0026apos; or \u0026apos;aggr_interval\u0026apos; is used as the divisor, which may\nlead to division-by-zero errors. Fix it by directly returning -EINVAL\nwhen such a case occurs. Additionally, since \u0026apos;aggr_interval\u0026apos; is already\nrequired to be set no smaller than \u0026apos;sample_interval\u0026apos; in damon_set_attrs(),\nonly the case where \u0026apos;sample_interval\u0026apos; is zero needs to be checked.(CVE-2025-39909)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()\n\nWhen creating a new scheme of DAMON_RECLAIM, the calculation of\n\u0026apos;min_age_region\u0026apos; uses \u0026apos;aggr_interval\u0026apos; as the divisor, which may lead to\ndivision-by-zero errors. Fix it by directly returning -EINVAL when such a\ncase occurs.(CVE-2025-39916)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm: bridge: anx7625: Fix NULL pointer dereference with early IRQ\n\nIf the interrupt occurs before resource initialization is complete, the\ninterrupt handler/worker may access uninitialized data such as the I2C\ntcpc_client device, potentially leading to NULL pointer dereference.(CVE-2025-39934)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wilc1000: avoid buffer overflow in WID string configuration\n\nFix the following copy overflow warning identified by Smatch checker.\n\n drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()\n error: \u0026apos;__memcpy()\u0026apos; \u0026apos;cfg-\u0026gt;s[i]-\u0026gt;str\u0026apos; copy overflow (512 vs 65537)\n\nThis patch introduces size check before accessing the memory buffer.\nThe checks are base on the WID type of received data from the firmware.\nFor WID string configuration, the size limit is determined by individual\nelement size in \u0026apos;struct wilc_cfg_str_vals\u0026apos; that is maintained in \u0026apos;len\u0026apos; field\nof \u0026apos;struct wilc_cfg_str\u0026apos;.(CVE-2025-39952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn\u0026apos;t valid\n\nSkip the WRMSR and HLT fastpaths in SVM\u0026apos;s VM-Exit handler if the next RIP\nisn\u0026apos;t valid, e.g. because KVM is running with nrips=false. SVM must\ndecode and emulate to skip the instruction if the CPU doesn\u0026apos;t provide the\nnext RIP, and getting the instruction bytes to decode requires reading\nguest memory. Reading guest memory through the emulator can fault, i.e.\ncan sleep, which is disallowed since the fastpath handlers run with IRQs\ndisabled.\n\n BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106\n in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu\n preempt_count: 1, expected: 0\n INFO: lockdep is turned off.\n irq event stamp: 30580\n hardirqs last enabled at (30579): [\u0026lt;ffffffffc08b2527\u0026gt;] vcpu_run+0x1787/0x1db0 [kvm]\n hardirqs last disabled at (30580): [\u0026lt;ffffffffb4f62e32\u0026gt;] __schedule+0x1e2/0xed0\n softirqs last enabled at (30570): [\u0026lt;ffffffffb4247a64\u0026gt;] fpu_swap_kvm_fpstate+0x44/0x210\n softirqs last disabled at (30568): [\u0026lt;ffffffffb4247a64\u0026gt;] fpu_swap_kvm_fpstate+0x44/0x210\n CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE\n Tainted: [U]=USER\n Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7d/0xb0\n __might_resched+0x271/0x290\n __might_fault+0x28/0x80\n kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm]\n kvm_fetch_guest_virt+0x92/0xc0 [kvm]\n __do_insn_fetch_bytes+0xf3/0x1e0 [kvm]\n x86_decode_insn+0xd1/0x1010 [kvm]\n x86_emulate_instruction+0x105/0x810 [kvm]\n __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd]\n handle_fastpath_invd+0xc4/0x1a0 [kvm]\n vcpu_run+0x11a1/0x1db0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm]\n kvm_vcpu_ioctl+0x578/0x6a0 [kvm]\n __se_sys_ioctl+0x6d/0xb0\n do_syscall_64+0x8a/0x2c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f479d57a94b\n \u0026lt;/TASK\u0026gt;\n\nNote, this is essentially a reapply of commit 5c30e8101e8d (\u0026quot;KVM: SVM:\nSkip WRMSR fastpath on VM-Exit if next RIP isn\u0026apos;t valid\u0026quot;), but with\ndifferent justification (KVM now grabs SRCU when skipping the instruction\nfor other reasons).(CVE-2025-40038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential null deref in ext4_mb_init()\n\nIn ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called\nwhen sbi-\u0026gt;s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo\nslab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy()\nlacks null pointer checking, this leads to a null pointer dereference.\n\n==================================================================\nEXT4-fs: no memory for groupinfo slab cache\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: Oops: 0002 [#1] SMP PTI\nCPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none)\nRIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40\nCall Trace:\n \u0026lt;TASK\u0026gt;\n xa_destroy+0x61/0x130\n ext4_mb_init+0x483/0x540\n __ext4_fill_super+0x116d/0x17b0\n ext4_fill_super+0xd3/0x280\n get_tree_bdev_flags+0x132/0x1d0\n vfs_get_tree+0x29/0xd0\n do_new_mount+0x197/0x300\n __x64_sys_mount+0x116/0x150\n do_syscall_64+0x50/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n==================================================================\n\nTherefore, add necessary null check to ext4_mb_avg_fragment_size_destroy()\nto prevent this issue. The same fix is also applied to\next4_mb_largest_free_orders_destroy().(CVE-2025-40119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nEDAC/i10nm: Skip DIMM enumeration on a disabled memory controller\n\nWhen loading the i10nm_edac driver on some Intel Granite Rapids servers,\na call trace may appear as follows:\n\n UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16\n shift exponent -66 is negative\n ...\n __ubsan_handle_shift_out_of_bounds+0x1e3/0x390\n skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]\n i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]\n skx_register_mci+0x159/0x220 [skx_edac_common]\n i10nm_init+0xcb0/0x1ff0 [i10nm_edac]\n ...\n\nThis occurs because some BIOS may disable a memory controller if there\naren\u0026apos;t any memory DIMMs populated on this memory controller. The DIMMMTR\nregister of this disabled memory controller contains the invalid value\n~0, resulting in the call trace above.\n\nFix this call trace by skipping DIMM enumeration on a disabled memory\ncontroller.(CVE-2025-40157)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: quota: create dedicated workqueue for quota_release_work\n\nThere is a kernel panic due to WARN_ONCE when panic_on_warn is set.\n\nThis issue occurs when writeback is triggered due to sync call for an\nopened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance\nis needed at sync path, flush for quota_release_work is triggered.\nBy default quota_release_work is queued to \u0026quot;events_unbound\u0026quot; queue which\ndoes not have WQ_MEM_RECLAIM flag. During f2fs balance \u0026quot;writeback\u0026quot;\nworkqueue tries to flush quota_release_work causing kernel panic due to\nMEM_RECLAIM flag mismatch errors.\n\nThis patch creates dedicated workqueue with WQ_MEM_RECLAIM flag\nfor work quota_release_work.\n\n------------[ cut here ]------------\nWARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148\nCall trace:\n check_flush_dependency+0x13c/0x148\n __flush_work+0xd0/0x398\n flush_delayed_work+0x44/0x5c\n dquot_writeback_dquots+0x54/0x318\n f2fs_do_quota_sync+0xb8/0x1a8\n f2fs_write_checkpoint+0x3cc/0x99c\n f2fs_gc+0x190/0x750\n f2fs_balance_fs+0x110/0x168\n f2fs_write_single_data_page+0x474/0x7dc\n f2fs_write_data_pages+0x7d0/0xd0c\n do_writepages+0xe0/0x2f4\n __writeback_single_inode+0x44/0x4ac\n writeback_sb_inodes+0x30c/0x538\n wb_writeback+0xf4/0x440\n wb_workfn+0x128/0x5d4\n process_scheduled_works+0x1c4/0x45c\n worker_thread+0x32c/0x3e8\n kthread+0x11c/0x1b0\n ret_from_fork+0x10/0x20\nKernel panic - not syncing: kernel: panic_on_warn set ...(CVE-2025-40196)\n\nIn the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try(). v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().(CVE-2025-40207)",
"id": "OESA-2025-2696",
"modified": "2026-08-06T11:09:49Z",
"published": "2025-11-22T11:09:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2696"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23140"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38011"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38132"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38155"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38167"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38206"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38326"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38348"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38640"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38696"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38718"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39711"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39716"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39719"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39767"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39781"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39842"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39846"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39909"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40038"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40196"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40207"
}
],
"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-2025-23140",
"CVE-2025-38011",
"CVE-2025-38059",
"CVE-2025-38132",
"CVE-2025-38155",
"CVE-2025-38167",
"CVE-2025-38206",
"CVE-2025-38326",
"CVE-2025-38348",
"CVE-2025-38640",
"CVE-2025-38696",
"CVE-2025-38718",
"CVE-2025-38734",
"CVE-2025-39693",
"CVE-2025-39711",
"CVE-2025-39716",
"CVE-2025-39719",
"CVE-2025-39726",
"CVE-2025-39767",
"CVE-2025-39781",
"CVE-2025-39794",
"CVE-2025-39808",
"CVE-2025-39842",
"CVE-2025-39846",
"CVE-2025-39861",
"CVE-2025-39863",
"CVE-2025-39909",
"CVE-2025-39916",
"CVE-2025-39934",
"CVE-2025-39952",
"CVE-2025-40038",
"CVE-2025-40119",
"CVE-2025-40157",
"CVE-2025-40196",
"CVE-2025-40207"
]
}
oesa-2025-2700
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:
misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error
After devm_request_irq() fails with error in pci_endpoint_test_request_irq(), the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs have been released.
However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message:
remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c
To solve this issue, set the number of remaining IRQs to test->num_irqs, and release IRQs in advance by calling pci_endpoint_test_release_irq().
In the Linux kernel, the following vulnerability has been resolved:
btrfs: avoid NULL pointer dereference if no valid csum tree
[BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace:
BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs] Call Trace: <TASK> scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs] scrub_simple_mirror+0x175/0x290 [btrfs] scrub_stripe+0x5f7/0x6f0 [btrfs] scrub_chunk+0x9a/0x150 [btrfs] scrub_enumerate_chunks+0x333/0x660 [btrfs] btrfs_scrub_dev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e
[CAUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification.
Normally call sites utilizing csum tree will check the fs state flag NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.
This results in scrub to call btrfs_search_slot() on a NULL pointer and triggered above crash.
[FIX] Check both extent and csum tree root before doing any tree search.(CVE-2025-38059)
In the Linux kernel, the following vulnerability has been resolved:
coresight: holding cscfg_csdev_lock while removing cscfg from csdev
There'll be possible race scenario for coresight config:
CPU0 CPU1 (perf enable) load module cscfg_load_config_sets() activate config. // sysfs (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config() lock(csdev->cscfg_csdev_lock) deactivate config // sysfs (sys_activec_cnt == 0) cscfg_unload_config_sets() <iterating config_csdev_list> cscfg_remove_owned_csdev_configs() // here load config activate by CPU1 unlock(csdev->cscfg_csdev_lock)
iterating config_csdev_list could be raced with config_csdev_list's entry delete.
To resolve this race , hold csdev->cscfg_csdev_lock() while cscfg_remove_owned_csdev_configs()(CVE-2025-38132)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()
devm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init() does not check for this case, which results in a NULL pointer dereference.
Prevent null pointer dereference in mt7915_mmio_wed_init().(CVE-2025-38155)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: handle hdr_first_de() return value
The hdr_first_de() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently.
Additionally, error handling for the return value already exists at other points where this function is called.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-38167)
In the Linux kernel, the following vulnerability has been resolved:
exfat: fix double free in delayed_free
The double free could happen in the following path.
exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double free This patch set ->vol_util as NULL after freeing it.(CVE-2025-38206)
In the Linux kernel, the following vulnerability has been resolved:
aoe: clean device rq_list in aoedev_downdev()
An aoe device's rq_list contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blk_mq. However, the queue was not cleaned out when an aoe device is downed which caused blk_mq_freeze_queue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blk_mq_freeze_queue().(CVE-2025-38326)
In the Linux kernel, the following vulnerability has been resolved:
wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()
Robert Morris reported:
|If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common priv, | struct sk_buff skb) |{ | struct p54_hdr hdr = (struct p54_hdr ) skb->data; | struct p54_eeprom_lm86 eeprom = (struct p54_eeprom_lm86 ) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...]
The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun.
This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them.
The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default.(CVE-2025-38348)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Disable migration in nf_hook_run_bpf().
syzbot reported that the netfilter bpf prog can be called without migration disabled in xmit path.
Then the assertion in __bpf_prog_run() fails, triggering the splat below. [0]
Let's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().
[0]: BUG: assuming non migratable context at ./include/linux/filter.h:703 in_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session 3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470 #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241 CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpf_prog_run include/linux/filter.h:703 [inline] bpf_prog_run include/linux/filter.h:725 [inline] nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20 nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623 nf_hook+0x370/0x680 include/linux/netfilter.h:272 NF_HOOK_COND include/linux/netfilter.h:305 [inline] ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:459 [inline] ip_local_out net/ipv4/ip_output.c:129 [inline] __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline] tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838 __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021 tcp_push+0x225/0x700 net/ipv4/tcp.c:759 tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x4aa/0x5b0 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x6c7/0x1150 fs/read_write.c:686 ksys_write+0x1f8/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe7d365d407 Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP:(CVE-2025-38640)
In the Linux kernel, the following vulnerability has been resolved:
MIPS: Don't crash in stack_top() for tasks without ABI or vDSO
Not all tasks have an ABI associated or vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL ABI pointer and crash.
This can for example happen when using kunit:
mips_stack_top+0x28/0xc0
arch_pick_mmap_layout+0x190/0x220
kunit_vm_mmap_init+0xf8/0x138
__kunit_add_resource+0x40/0xa8
kunit_vm_mmap+0x88/0xd8
usercopy_test_init+0xb8/0x240
kunit_try_run_case+0x5c/0x1a8
kunit_generic_run_threadfn_adapter+0x28/0x50
kthread+0x118/0x240
ret_from_kernel_thread+0x14/0x1c
Only dereference the ABI point if it is set.
The GIC page is also included as it is specific to the vDSO. Also move the randomization adjustment into the same conditional.(CVE-2025-38696)
In the Linux kernel, the following vulnerability has been resolved:
sctp: linearize cloned gso packets in sctp_rcv
A cloned head skb still shares these frag skbs in fraglist with the original head skb. It's not safe to access these frag skbs.
syzbot reported two use-of-uninitialized-memory bugs caused by this:
BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]
and
BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]
This patch fixes it by linearizing cloned gso packets in sctp_rcv().(CVE-2025-38718)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix UAF on smcsk after smc_listen_out()
BPF CI testing report a UAF issue:
[ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: error_code(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] <TASK > [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? page_fault_oops+0x180/0x4c 0 [ 16.457508] ? __lock_acquire+0x3e6/0x249 0 [ 16.457801] ? exc_page_fault+0x68/0x20 0 [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0 [ 16.458389] ? smc_listen_work+0xc02/0x159 0 [ 16.458689] ? smc_listen_work+0xc02/0x159 0 [ 16.458987] ? lock_is_held_type+0x8f/0x10 0 [ 16.459284] process_one_work+0x1ea/0x6d 0 [ 16.459570] worker_thread+0x1c3/0x38 0 [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfx_kthread+0x10/0x1 0 [ 16.460640] ret_from_fork+0x31/0x5 0 [ 16.460896] ? __pfx_kthread+0x10/0x1 0 [ 16.461166] ret_from_fork_asm+0x1a/0x3 0 [ 16.461453] </TASK > [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590
The direct cause of this issue is that after smc_listen_out_connected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows:
smc_listen_work | userspace
lock_sock(sk) | smc_listen_out_connected() | | - smc_listen_out | | | - release_sock | | |- sk->sk_data_ready() | | fd = accept(); | close(fd); | - socket->sk = NULL; / newclcsock->sk is NULL now / SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk))
Since smc_listen_out_connected() will not fail, simply swapping the order of the code can easily fix this issue.(CVE-2025-38734)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid a NULL pointer dereference
[WHY] Although unlikely drm_atomic_get_new_connector_state() or drm_atomic_get_old_connector_state() can return NULL.
[HOW] Check returns before dereference.
(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)(CVE-2025-39693)
In the Linux kernel, the following vulnerability has been resolved:
media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls
Both the ACE and CSI driver are missing a mei_cldev_disable() call in their remove() function.
This causes the mei_cl client to stay part of the mei_device->file_list list even though its memory is freed by mei_cl_bus_dev_release() calling kfree(cldev->cl).
This leads to a use-after-free when mei_vsc_remove() runs mei_stop() which first removes all mei bus devices calling mei_ace_remove() and mei_csi_remove() followed by mei_cl_bus_dev_release() and then calls mei_cl_all_disconnect() which walks over mei_device->file_list dereferecing the just freed cldev->cl.
And mei_vsc_remove() it self is run at shutdown because of the platform_device_unregister(tp->pdev) in vsc_tp_shutdown()
When building a kernel with KASAN this leads to the following KASAN report:
[ 106.634504] ================================================================== [ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1 [ 106.634729] [ 106.634767] Tainted: [E]=UNSIGNED_MODULE [ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025 [ 106.634773] Call Trace: [ 106.634777] <TASK> ... [ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) [ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei [ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei [ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei [ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc [ 106.635066] platform_remove (drivers/base/platform.c:1424)
Add the missing mei_cldev_disable() calls so that the mei_cl gets removed from mei_device->file_list before it is freed to fix this.(CVE-2025-39711)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise __get_user() to probe user read access
Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so __get_user() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call.
Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting __gu_err to -EFAULT (-14) if access isn't allowed.
Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm.(CVE-2025-39716)
In the Linux kernel, the following vulnerability has been resolved:
iio: imu: bno055: fix OOB access of hw_xlate array
Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c.
In bno055_get_regmask(), hw_xlate was iterated over the length of the vals array instead of the length of the hw_xlate array. In the case of bno055_gyr_scale, the vals array is larger than the hw_xlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hw_xlate array.
By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be sure we are iterating over the correct length.(CVE-2025-39719)
In the Linux kernel, the following vulnerability has been resolved:
s390/ism: fix concurrency management in ism_cmd()
The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that.
This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well.
A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it.
On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.(CVE-2025-39726)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Optimize module load time by optimizing PLT/GOT counting
When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows:
rcu: INFO: rcu_sched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler+0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constant_timer_interrupt+0x64/0x80 [<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x30/0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158
After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock.
When loading a module, module_frob_arch_sections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the count_max_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity.
To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations.
After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace".
Using the default configuration to test some modules, the results are as follows:
Module Size ip_tables 36K fat 143K radeon 2.5MB amdgpu 16MB
Without this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098
With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 22 1221/84 amdgpu 45 4525/1098(CVE-2025-39767)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Drop WARN_ON_ONCE() from flush_cache_vmap
I have observed warning to occassionally trigger.(CVE-2025-39781)
In the Linux kernel, the following vulnerability has been resolved:
ARM: tegra: Use I/O memcpy to write to IRAM
Kasan crashes the kernel trying to check boundaries when using the normal memcpy.(CVE-2025-39794)
In the Linux kernel, the following vulnerability has been resolved:
HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()
in ntrig_report_version(), hdev parameter passed from hid_probe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usb_dev has invalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned when usb_rcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58)
add null check logic to ntrig_report_version() before calling hid_to_usb_dev()(CVE-2025-39808)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: prevent release journal inode after journal shutdown
Before calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already been executed in ocfs2_dismount_volume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2_journal_release_jbd_inode().
ocfs2_dismount_volume()-> ocfs2_delete_osb()-> ocfs2_free_slot_info()-> __ocfs2_free_slot_info()-> evict()-> ocfs2_evict_inode()-> ocfs2_clear_inode()-> jbd2_journal_release_jbd_inode(osb->journal->j_journal,
Adding osb->journal checks will prevent null-ptr-deref during the above execution path.(CVE-2025-39842)
In the Linux kernel, the following vulnerability has been resolved:
pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()
In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to res and used in pci_bus_alloc_resource(). There is a dereference of res in pci_bus_alloc_resource(), which could lead to a NULL pointer dereference on failure of pcmcia_make_resource().
Fix this bug by adding a check of res.(CVE-2025-39846)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: vhci: Prevent use-after-free by removing debugfs files early
Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed.
Previously, debugfs files such as "force_suspend", "force_wakeup", and others were created under hdev->debugfs but not removed in vhci_release(). Since vhci_release() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors.
Although hdev->debugfs is later freed in hci_release_dev(), user can access files after vhci_data is freed but before hdev->debugfs is released.(CVE-2025-39861)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work
The brcmf_btcoex_detach() only shuts down the btcoex timer, if the flag timer_on is false. However, the brcmf_btcoex_timerfunc(), which runs as timer handler, sets timer_on to false. This creates critical race conditions:
1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc() is executing, it may observe timer_on as false and skip the call to timer_shutdown_sync().
2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info worker after the cancel_work_sync() has been executed, resulting in use-after-free bugs.
The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmf_btcoex_info struct is freed relative to the execution of its worker thread.
Scenario 1: Freed before the worker is scheduled
The brcmf_btcoex_info is deallocated before the worker is scheduled. A race condition can occur when schedule_work(&bt_local->work) is called after the target memory has been freed. The sequence of events is detailed below:
CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USE
Scenario 2: Freed after the worker is scheduled
The brcmf_btcoex_info is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmf_btcoex_handler() — such as the container_of macro and subsequent dereferences of the brcmf_btcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario:
CPU0 | CPU1 brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker / | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| / |
To resolve the race conditions, drop the conditional check and call timer_shutdown_sync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.(CVE-2025-39863)
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()
Patch series "mm/damon: avoid divide-by-zero in DAMON module's parameters application".
DAMON's RECLAIM and LRU_SORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors.
Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters.
This patch (of 2):
During the calculation of 'hot_thres' and 'cold_thres', either 'sample_interval' or 'aggr_interval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggr_interval' is already required to be set no smaller than 'sample_interval' in damon_set_attrs(), only the case where 'sample_interval' is zero needs to be checked.(CVE-2025-39909)
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()
When creating a new scheme of DAMON_RECLAIM, the calculation of 'min_age_region' uses 'aggr_interval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.(CVE-2025-39916)
In the Linux kernel, the following vulnerability has been resolved:
drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ
If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.(CVE-2025-39934)
In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: avoid buffer overflow in WID string configuration
Fix the following copy overflow warning identified by Smatch checker.
drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)
This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.(CVE-2025-39952)
In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid
Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled.
BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu preempt_count: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [<ffffffffc08b2527>] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [<ffffffffb4f62e32>] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 softirqs last disabled at (30568): [<ffffffffb4247a64>] fpu_swap_kvm_fpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: <TASK> dump_stack_lvl+0x7d/0xb0 __might_resched+0x271/0x290 __might_fault+0x28/0x80 kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm] kvm_fetch_guest_virt+0x92/0xc0 [kvm] __do_insn_fetch_bytes+0xf3/0x1e0 [kvm] x86_decode_insn+0xd1/0x1010 [kvm] x86_emulate_instruction+0x105/0x810 [kvm] __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd] handle_fastpath_invd+0xc4/0x1a0 [kvm] vcpu_run+0x11a1/0x1db0 [kvm] kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm] kvm_vcpu_ioctl+0x578/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x8a/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b </TASK>
Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons).(CVE-2025-40038)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix potential null deref in ext4_mb_init()
In ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called when sbi->s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo slab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy() lacks null pointer checking, this leads to a null pointer dereference.
================================================================== EXT4-fs: no memory for groupinfo slab cache BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP PTI CPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none) RIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40 Call Trace: <TASK> xa_destroy+0x61/0x130 ext4_mb_init+0x483/0x540 __ext4_fill_super+0x116d/0x17b0 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 do_new_mount+0x197/0x300 __x64_sys_mount+0x116/0x150 do_syscall_64+0x50/0x1c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e ==================================================================
Therefore, add necessary null check to ext4_mb_avg_fragment_size_destroy() to prevent this issue. The same fix is also applied to ext4_mb_largest_free_orders_destroy().(CVE-2025-40119)
In the Linux kernel, the following vulnerability has been resolved:
EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller
When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows:
UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsan_handle_shift_out_of_bounds+0x1e3/0x390 skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common] i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac] skx_register_mci+0x159/0x220 [skx_edac_common] i10nm_init+0xcb0/0x1ff0 [i10nm_edac] ...
This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above.
Fix this call trace by skipping DIMM enumeration on a disabled memory controller.(CVE-2025-40157)
In the Linux kernel, the following vulnerability has been resolved:
fs: quota: create dedicated workqueue for quota_release_work
There is a kernel panic due to WARN_ONCE when panic_on_warn is set.
This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance is needed at sync path, flush for quota_release_work is triggered. By default quota_release_work is queued to "events_unbound" queue which does not have WQ_MEM_RECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quota_release_work causing kernel panic due to MEM_RECLAIM flag mismatch errors.
This patch creates dedicated workqueue with WQ_MEM_RECLAIM flag for work quota_release_work.
------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148 Call trace: check_flush_dependency+0x13c/0x148 __flush_work+0xd0/0x398 flush_delayed_work+0x44/0x5c dquot_writeback_dquots+0x54/0x318 f2fs_do_quota_sync+0xb8/0x1a8 f2fs_write_checkpoint+0x3cc/0x99c f2fs_gc+0x190/0x750 f2fs_balance_fs+0x110/0x168 f2fs_write_single_data_page+0x474/0x7dc f2fs_write_data_pages+0x7d0/0xd0c do_writepages+0xe0/0x2f4 __writeback_single_inode+0x44/0x4ac writeback_sb_inodes+0x30c/0x538 wb_writeback+0xf4/0x440 wb_workfn+0x128/0x5d4 process_scheduled_works+0x1c4/0x45c worker_thread+0x32c/0x3e8 kthread+0x11c/0x1b0 ret_from_fork+0x10/0x20 Kernel panic - not syncing: kernel: panic_on_warn set ...(CVE-2025-40196)
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try(). v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().(CVE-2025-40207)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"kernel-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"kernel-source-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"perf-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"python3-perf-6.6.0-119.0.0.110.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-119.0.0.110.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-119.0.0.110.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"kernel-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"kernel-source-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"perf-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"python3-perf-6.6.0-119.0.0.110.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-119.0.0.110.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-119.0.0.110.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\nmisc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error\n\nAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),\nthe pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs\nhave been released.\n\nHowever, some requested IRQs remain unreleased, so there are still\n/proc/irq/* entries remaining, and this results in WARN() with the\nfollowing message:\n\n remove_proc_entry: removing non-empty directory \u0026apos;irq/30\u0026apos;, leaking at least \u0026apos;pci-endpoint-test.0\u0026apos;\n WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c\n\nTo solve this issue, set the number of remaining IRQs to test-\u0026gt;num_irqs,\nand release IRQs in advance by calling pci_endpoint_test_release_irq().\n\n[kwilczynski: commit log](CVE-2025-23140)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: avoid NULL pointer dereference if no valid csum tree\n\n[BUG]\nWhen trying read-only scrub on a btrfs with rescue=idatacsums mount\noption, it will crash with the following call trace:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000208\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022\n RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs]\n Call Trace:\n \u0026lt;TASK\u0026gt;\n scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs]\n scrub_simple_mirror+0x175/0x290 [btrfs]\n scrub_stripe+0x5f7/0x6f0 [btrfs]\n scrub_chunk+0x9a/0x150 [btrfs]\n scrub_enumerate_chunks+0x333/0x660 [btrfs]\n btrfs_scrub_dev+0x23e/0x600 [btrfs]\n btrfs_ioctl+0x1dcf/0x2f80 [btrfs]\n __x64_sys_ioctl+0x97/0xc0\n do_syscall_64+0x4f/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[CAUSE]\nMount option \u0026quot;rescue=idatacsums\u0026quot; will completely skip loading the csum\ntree, so that any data read will not find any data csum thus we will\nignore data checksum verification.\n\nNormally call sites utilizing csum tree will check the fs state flag\nNO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.\n\nThis results in scrub to call btrfs_search_slot() on a NULL pointer\nand triggered above crash.\n\n[FIX]\nCheck both extent and csum tree root before doing any tree search.(CVE-2025-38059)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncoresight: holding cscfg_csdev_lock while removing cscfg from csdev\n\nThere\u0026apos;ll be possible race scenario for coresight config:\n\nCPU0 CPU1\n(perf enable) load module\n cscfg_load_config_sets()\n activate config. // sysfs\n (sys_active_cnt == 1)\n...\ncscfg_csdev_enable_active_config()\n lock(csdev-\u0026gt;cscfg_csdev_lock)\n deactivate config // sysfs\n (sys_activec_cnt == 0)\n cscfg_unload_config_sets()\n \u0026lt;iterating config_csdev_list\u0026gt; cscfg_remove_owned_csdev_configs()\n // here load config activate by CPU1\n unlock(csdev-\u0026gt;cscfg_csdev_lock)\n\niterating config_csdev_list could be raced with config_csdev_list\u0026apos;s\nentry delete.\n\nTo resolve this race , hold csdev-\u0026gt;cscfg_csdev_lock() while\ncscfg_remove_owned_csdev_configs()(CVE-2025-38132)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7915: Fix null-ptr-deref in mt7915_mmio_wed_init()\n\ndevm_ioremap() returns NULL on error. Currently, mt7915_mmio_wed_init()\ndoes not check for this case, which results in a NULL pointer\ndereference.\n\nPrevent null pointer dereference in mt7915_mmio_wed_init().(CVE-2025-38155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: handle hdr_first_de() return value\n\nThe hdr_first_de() function returns a pointer to a struct NTFS_DE. This\npointer may be NULL. To handle the NULL error effectively, it is important\nto implement an error handler. This will help manage potential errors\nconsistently.\n\nAdditionally, error handling for the return value already exists at other\npoints where this function is called.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-38167)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nexfat: fix double free in delayed_free\n\nThe double free could happen in the following path.\n\nexfat_create_upcase_table()\n exfat_create_upcase_table() : return error\n exfat_free_upcase_table() : free -\u0026gt;vol_utbl\n exfat_load_default_upcase_table : return error\n exfat_kill_sb()\n delayed_free()\n exfat_free_upcase_table() \u0026lt;--------- double free\nThis patch set -\u0026gt;vol_util as NULL after freeing it.(CVE-2025-38206)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naoe: clean device rq_list in aoedev_downdev()\n\nAn aoe device\u0026apos;s rq_list contains accepted block requests that are\nwaiting to be transmitted to the aoe target. This queue was added as\npart of the conversion to blk_mq. However, the queue was not cleaned out\nwhen an aoe device is downed which caused blk_mq_freeze_queue() to sleep\nindefinitely waiting for those requests to complete, causing a hang. This\nfix cleans out the queue before calling blk_mq_freeze_queue().(CVE-2025-38326)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\n\nRobert Morris reported:\n\n|If a malicious USB device pretends to be an Intersil p54 wifi\n|interface and generates an eeprom_readback message with a large\n|eeprom-\u0026gt;v1.len, p54_rx_eeprom_readback() will copy data from the\n|message beyond the end of priv-\u0026gt;eeprom.\n|\n|static void p54_rx_eeprom_readback(struct p54_common *priv,\n| struct sk_buff *skb)\n|{\n| struct p54_hdr *hdr = (struct p54_hdr *) skb-\u0026gt;data;\n| struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-\u0026gt;data;\n|\n| if (priv-\u0026gt;fw_var \u0026gt;= 0x509) {\n| memcpy(priv-\u0026gt;eeprom, eeprom-\u0026gt;v2.data,\n| le16_to_cpu(eeprom-\u0026gt;v2.len));\n| } else {\n| memcpy(priv-\u0026gt;eeprom, eeprom-\u0026gt;v1.data,\n| le16_to_cpu(eeprom-\u0026gt;v1.len));\n| }\n| [...]\n\nThe eeprom-\u0026gt;v{1,2}.len is set by the driver in p54_download_eeprom().\nThe device is supposed to provide the same length back to the driver.\nBut yes, it\u0026apos;s possible (like shown in the report) to alter the value\nto something that causes a crash/panic due to overrun.\n\nThis patch addresses the issue by adding the size to the common device\ncontext, so p54_rx_eeprom_readback no longer relies on possibly tampered\nvalues... That said, it also checks if the \u0026quot;firmware\u0026quot; altered the value\nand no longer copies them.\n\nThe one, small saving grace is: Before the driver tries to read the eeprom,\nit needs to upload \u0026gt;a\u0026lt; firmware. the vendor firmware has a proprietary\nlicense and as a reason, it is not present on most distributions by\ndefault.(CVE-2025-38348)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Disable migration in nf_hook_run_bpf().\n\nsyzbot reported that the netfilter bpf prog can be called without\nmigration disabled in xmit path.\n\nThen the assertion in __bpf_prog_run() fails, triggering the splat\nbelow. [0]\n\nLet\u0026apos;s use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().\n\n[0]:\nBUG: assuming non migratable context at ./include/linux/filter.h:703\nin_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session\n3 locks held by sshd-session/5829:\n #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline]\n #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241\nCPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n __cant_migrate kernel/sched/core.c:8860 [inline]\n __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834\n __bpf_prog_run include/linux/filter.h:703 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20\n nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]\n nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623\n nf_hook+0x370/0x680 include/linux/netfilter.h:272\n NF_HOOK_COND include/linux/netfilter.h:305 [inline]\n ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433\n dst_output include/net/dst.h:459 [inline]\n ip_local_out net/ipv4/ip_output.c:129 [inline]\n __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527\n __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479\n tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline]\n tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838\n __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021\n tcp_push+0x225/0x700 net/ipv4/tcp.c:759\n tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359\n tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396\n inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n sock_write_iter+0x4aa/0x5b0 net/socket.c:1131\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x6c7/0x1150 fs/read_write.c:686\n ksys_write+0x1f8/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe7d365d407\nCode: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 \u0026lt;5b\u0026gt; c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff\nRSP:(CVE-2025-38640)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: Don\u0026apos;t crash in stack_top() for tasks without ABI or vDSO\n\nNot all tasks have an ABI associated or vDSO mapped,\nfor example kthreads never do.\nIf such a task ever ends up calling stack_top(), it will derefence the\nNULL ABI pointer and crash.\n\nThis can for example happen when using kunit:\n\n mips_stack_top+0x28/0xc0\n arch_pick_mmap_layout+0x190/0x220\n kunit_vm_mmap_init+0xf8/0x138\n __kunit_add_resource+0x40/0xa8\n kunit_vm_mmap+0x88/0xd8\n usercopy_test_init+0xb8/0x240\n kunit_try_run_case+0x5c/0x1a8\n kunit_generic_run_threadfn_adapter+0x28/0x50\n kthread+0x118/0x240\n ret_from_kernel_thread+0x14/0x1c\n\nOnly dereference the ABI point if it is set.\n\nThe GIC page is also included as it is specific to the vDSO.\nAlso move the randomization adjustment into the same conditional.(CVE-2025-38696)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: linearize cloned gso packets in sctp_rcv\n\nA cloned head skb still shares these frag skbs in fraglist with the\noriginal head skb. It\u0026apos;s not safe to access these frag skbs.\n\nsyzbot reported two use-of-uninitialized-memory bugs caused by this:\n\n BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211\n sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211\n sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998\n sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88\n sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331\n sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122\n __release_sock+0x1da/0x330 net/core/sock.c:3106\n release_sock+0x6b/0x250 net/core/sock.c:3660\n sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360\n sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885\n sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031\n inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:718 [inline]\n\nand\n\n BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987\n sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987\n sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88\n sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331\n sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n __release_sock+0x1d3/0x330 net/core/sock.c:3213\n release_sock+0x6b/0x270 net/core/sock.c:3767\n sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367\n sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886\n sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032\n inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n\nThis patch fixes it by linearizing cloned gso packets in sctp_rcv().(CVE-2025-38718)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix UAF on smcsk after smc_listen_out()\n\nBPF CI testing report a UAF issue:\n\n [ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0\n [ 16.447134] #PF: supervisor read access in kernel mod e\n [ 16.447516] #PF: error_code(0x0000) - not-present pag e\n [ 16.447878] PGD 0 P4D 0\n [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I\n [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2\n [ 16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL E\n [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4\n [ 16.450201] Workqueue: smc_hs_wq smc_listen_wor k\n [ 16.450531] RIP: 0010:smc_listen_work+0xc02/0x159 0\n [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6\n [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0\n [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0\n [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5\n [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0\n [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0\n [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0\n [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3\n [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0\n [ 16.456459] PKRU: 5555555 4\n [ 16.456654] Call Trace :\n [ 16.456832] \u0026lt;TASK \u0026gt;\n [ 16.456989] ? __die+0x23/0x7 0\n [ 16.457215] ? page_fault_oops+0x180/0x4c 0\n [ 16.457508] ? __lock_acquire+0x3e6/0x249 0\n [ 16.457801] ? exc_page_fault+0x68/0x20 0\n [ 16.458080] ? asm_exc_page_fault+0x26/0x3 0\n [ 16.458389] ? smc_listen_work+0xc02/0x159 0\n [ 16.458689] ? smc_listen_work+0xc02/0x159 0\n [ 16.458987] ? lock_is_held_type+0x8f/0x10 0\n [ 16.459284] process_one_work+0x1ea/0x6d 0\n [ 16.459570] worker_thread+0x1c3/0x38 0\n [ 16.459839] ? __pfx_worker_thread+0x10/0x1 0\n [ 16.460144] kthread+0xe0/0x11 0\n [ 16.460372] ? __pfx_kthread+0x10/0x1 0\n [ 16.460640] ret_from_fork+0x31/0x5 0\n [ 16.460896] ? __pfx_kthread+0x10/0x1 0\n [ 16.461166] ret_from_fork_asm+0x1a/0x3 0\n [ 16.461453] \u0026lt;/TASK \u0026gt;\n [ 16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE) ]\n [ 16.462134] CR2: 000000000000003 0\n [ 16.462380] ---[ end trace 0000000000000000 ]---\n [ 16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590\n\nThe direct cause of this issue is that after smc_listen_out_connected(),\nnewclcsock-\u0026gt;sk may be NULL since it will releases the smcsk. Therefore,\nif the application closes the socket immediately after accept,\nnewclcsock-\u0026gt;sk can be NULL. A possible execution order could be as\nfollows:\n\nsmc_listen_work | userspace\n-----------------------------------------------------------------\nlock_sock(sk) |\nsmc_listen_out_connected() |\n| \\- smc_listen_out |\n| | \\- release_sock |\n | |- sk-\u0026gt;sk_data_ready() |\n | fd = accept();\n | close(fd);\n | \\- socket-\u0026gt;sk = NULL;\n/* newclcsock-\u0026gt;sk is NULL now */\nSMC_STAT_SERV_SUCC_INC(sock_net(newclcsock-\u0026gt;sk))\n\nSince smc_listen_out_connected() will not fail, simply swapping the order\nof the code can easily fix this issue.(CVE-2025-38734)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Avoid a NULL pointer dereference\n\n[WHY]\nAlthough unlikely drm_atomic_get_new_connector_state() or\ndrm_atomic_get_old_connector_state() can return NULL.\n\n[HOW]\nCheck returns before dereference.\n\n(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)(CVE-2025-39693)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls\n\nBoth the ACE and CSI driver are missing a mei_cldev_disable() call in\ntheir remove() function.\n\nThis causes the mei_cl client to stay part of the mei_device-\u0026gt;file_list\nlist even though its memory is freed by mei_cl_bus_dev_release() calling\nkfree(cldev-\u0026gt;cl).\n\nThis leads to a use-after-free when mei_vsc_remove() runs mei_stop()\nwhich first removes all mei bus devices calling mei_ace_remove() and\nmei_csi_remove() followed by mei_cl_bus_dev_release() and then calls\nmei_cl_all_disconnect() which walks over mei_device-\u0026gt;file_list dereferecing\nthe just freed cldev-\u0026gt;cl.\n\nAnd mei_vsc_remove() it self is run at shutdown because of the\nplatform_device_unregister(tp-\u0026gt;pdev) in vsc_tp_shutdown()\n\nWhen building a kernel with KASAN this leads to the following KASAN report:\n\n[ 106.634504] ==================================================================\n[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei\n[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1\n[ 106.634729]\n[ 106.634767] Tainted: [E]=UNSIGNED_MODULE\n[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025\n[ 106.634773] Call Trace:\n[ 106.634777] \u0026lt;TASK\u0026gt;\n...\n[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)\n[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei\n[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei\n[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei\n...\n[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei\n[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc\n[ 106.635066] platform_remove (drivers/base/platform.c:1424)\n\nAdd the missing mei_cldev_disable() calls so that the mei_cl gets removed\nfrom mei_device-\u0026gt;file_list before it is freed to fix this.(CVE-2025-39711)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise __get_user() to probe user read access\n\nBecause of the way read access support is implemented, read access\ninterruptions are only triggered at privilege levels 2 and 3. The\nkernel executes at privilege level 0, so __get_user() never triggers\na read access interruption (code 26). Thus, it is currently possible\nfor user code to access a read protected address via a system call.\n\nFix this by probing read access rights at privilege level 3 (PRIV_USER)\nand setting __gu_err to -EFAULT (-14) if access isn\u0026apos;t allowed.\n\nNote the cmpiclr instruction does a 32-bit compare because COND macro\ndoesn\u0026apos;t work inside asm.(CVE-2025-39716)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: imu: bno055: fix OOB access of hw_xlate array\n\nFix a potential out-of-bounds array access of the hw_xlate array in\nbno055.c.\n\nIn bno055_get_regmask(), hw_xlate was iterated over the length of the\nvals array instead of the length of the hw_xlate array. In the case of\nbno055_gyr_scale, the vals array is larger than the hw_xlate array,\nso this could result in an out-of-bounds access. In practice, this\nshouldn\u0026apos;t happen though because a match should always be found which\nbreaks out of the for loop before it iterates beyond the end of the\nhw_xlate array.\n\nBy adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be\nsure we are iterating over the correct length.(CVE-2025-39719)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/ism: fix concurrency management in ism_cmd()\n\nThe s390x ISM device data sheet clearly states that only one\nrequest-response sequence is allowable per ISM function at any point in\ntime. Unfortunately as of today the s390/ism driver in Linux does not\nhonor that requirement. This patch aims to rectify that.\n\nThis problem was discovered based on Aliaksei\u0026apos;s bug report which states\nthat for certain workloads the ISM functions end up entering error state\n(with PEC 2 as seen from the logs) after a while and as a consequence\nconnections handled by the respective function break, and for future\nconnection requests the ISM device is not considered -- given it is in a\ndysfunctional state. During further debugging PEC 3A was observed as\nwell.\n\nA kernel message like\n[ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a\nis a reliable indicator of the stated function entering error state\nwith PEC 2. Let me also point out that a kernel message like\n[ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery\nis a reliable indicator that the ISM function won\u0026apos;t be auto-recovered\nbecause the ISM driver currently lacks support for it.\n\nOn a technical level, without this synchronization, commands (inputs to\nthe FW) may be partially or fully overwritten (corrupted) by another CPU\ntrying to issue commands on the same function. There is hard evidence that\nthis can lead to DMB token values being used as DMB IOVAs, leading to\nPEC 2 PCI events indicating invalid DMA. But this is only one of the\nfailure modes imaginable. In theory even completely losing one command\nand executing another one twice and then trying to interpret the outputs\nas if the command we intended to execute was actually executed and not\nthe other one is also possible. Frankly, I don\u0026apos;t feel confident about\nproviding an exhaustive list of possible consequences.(CVE-2025-39726)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Optimize module load time by optimizing PLT/GOT counting\n\nWhen enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and\nCONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,\nthe relevant logs are as follows:\n\nrcu: INFO: rcu_sched self-detected stall on CPU\n...\nCall Trace:\n[\u0026lt;900000000024f9e4\u0026gt;] show_stack+0x5c/0x180\n[\u0026lt;90000000002482f4\u0026gt;] dump_stack_lvl+0x94/0xbc\n[\u0026lt;9000000000224544\u0026gt;] rcu_dump_cpu_stacks+0x1fc/0x280\n[\u0026lt;900000000037ac80\u0026gt;] rcu_sched_clock_irq+0x720/0xf88\n[\u0026lt;9000000000396c34\u0026gt;] update_process_times+0xb4/0x150\n[\u0026lt;90000000003b2474\u0026gt;] tick_nohz_handler+0xf4/0x250\n[\u0026lt;9000000000397e28\u0026gt;] __hrtimer_run_queues+0x1d0/0x428\n[\u0026lt;9000000000399b2c\u0026gt;] hrtimer_interrupt+0x214/0x538\n[\u0026lt;9000000000253634\u0026gt;] constant_timer_interrupt+0x64/0x80\n[\u0026lt;9000000000349938\u0026gt;] __handle_irq_event_percpu+0x78/0x1a0\n[\u0026lt;9000000000349a78\u0026gt;] handle_irq_event_percpu+0x18/0x88\n[\u0026lt;9000000000354c00\u0026gt;] handle_percpu_irq+0x90/0xf0\n[\u0026lt;9000000000348c74\u0026gt;] handle_irq_desc+0x94/0xb8\n[\u0026lt;9000000001012b28\u0026gt;] handle_cpu_irq+0x68/0xa0\n[\u0026lt;9000000001def8c0\u0026gt;] handle_loongarch_irq+0x30/0x48\n[\u0026lt;9000000001def958\u0026gt;] do_vint+0x80/0xd0\n[\u0026lt;9000000000268a0c\u0026gt;] kasan_mem_to_shadow.part.0+0x2c/0x2a0\n[\u0026lt;90000000006344f4\u0026gt;] __asan_load8+0x4c/0x120\n[\u0026lt;900000000025c0d0\u0026gt;] module_frob_arch_sections+0x5c8/0x6b8\n[\u0026lt;90000000003895f0\u0026gt;] load_module+0x9e0/0x2958\n[\u0026lt;900000000038b770\u0026gt;] __do_sys_init_module+0x208/0x2d0\n[\u0026lt;9000000001df0c34\u0026gt;] do_syscall+0x94/0x190\n[\u0026lt;900000000024d6fc\u0026gt;] handle_syscall+0xbc/0x158\n\nAfter analysis, this is because the slow speed of loading the amdgpu\nmodule leads to the long time occupation of the cpu and then the soft\ndeadlock.\n\nWhen loading a module, module_frob_arch_sections() tries to figure out\nthe number of PLTs/GOTs that will be needed to handle all the RELAs. It\nwill call the count_max_entries() to find in an out-of-order date which\ncounting algorithm has O(n^2) complexity.\n\nTo make it faster, we sort the relocation list by info and addend. That\nway, to check for a duplicate relocation, it just needs to compare with\nthe previous entry. This reduces the complexity of the algorithm to O(n\n log n), as done in commit d4e0340919fb (\u0026quot;arm64/module: Optimize module\nload time by optimizing PLT counting\u0026quot;). This gives sinificant reduction\nin module load time for modules with large number of relocations.\n\nAfter applying this patch, the soft deadlock problem has been solved,\nand the kernel starts normally without \u0026quot;Call Trace\u0026quot;.\n\nUsing the default configuration to test some modules, the results are as\nfollows:\n\nModule Size\nip_tables 36K\nfat 143K\nradeon 2.5MB\namdgpu 16MB\n\nWithout this patch:\nModule Module load time (ms)\tCount(PLTs/GOTs)\nip_tables 18\t\t\t\t59/6\nfat 0\t\t\t\t162/14\nradeon 54\t\t\t\t1221/84\namdgpu 1411\t\t\t4525/1098\n\nWith this patch:\nModule Module load time (ms)\tCount(PLTs/GOTs)\nip_tables 18\t\t\t\t59/6\nfat 0\t\t\t\t162/14\nradeon 22\t\t\t\t1221/84\namdgpu 45\t\t\t\t4525/1098(CVE-2025-39767)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Drop WARN_ON_ONCE() from flush_cache_vmap\n\nI have observed warning to occassionally trigger.(CVE-2025-39781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: tegra: Use I/O memcpy to write to IRAM\n\nKasan crashes the kernel trying to check boundaries when using the\nnormal memcpy.(CVE-2025-39794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()\n\nin ntrig_report_version(), hdev parameter passed from hid_probe().\nsending descriptor to /dev/uhid can make hdev-\u0026gt;dev.parent-\u0026gt;parent to null\nif hdev-\u0026gt;dev.parent-\u0026gt;parent is null, usb_dev has\ninvalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returned\nwhen usb_rcvctrlpipe() use usb_dev,it trigger\npage fault error for address(0xffffffffffffff58)\n\nadd null check logic to ntrig_report_version()\nbefore calling hid_to_usb_dev()(CVE-2025-39808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: prevent release journal inode after journal shutdown\n\nBefore calling ocfs2_delete_osb(), ocfs2_journal_shutdown() has already\nbeen executed in ocfs2_dismount_volume(), so osb-\u0026gt;journal must be NULL. \nTherefore, the following calltrace will inevitably fail when it reaches\njbd2_journal_release_jbd_inode().\n\nocfs2_dismount_volume()-\u0026gt;\n ocfs2_delete_osb()-\u0026gt;\n ocfs2_free_slot_info()-\u0026gt;\n __ocfs2_free_slot_info()-\u0026gt;\n evict()-\u0026gt;\n ocfs2_evict_inode()-\u0026gt;\n ocfs2_clear_inode()-\u0026gt;\n\t jbd2_journal_release_jbd_inode(osb-\u0026gt;journal-\u0026gt;j_journal,\n\nAdding osb-\u0026gt;journal checks will prevent null-ptr-deref during the above\nexecution path.(CVE-2025-39842)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()\n\nIn __iodyn_find_io_region(), pcmcia_make_resource() is assigned to\nres and used in pci_bus_alloc_resource(). There is a dereference of res\nin pci_bus_alloc_resource(), which could lead to a NULL pointer\ndereference on failure of pcmcia_make_resource().\n\nFix this bug by adding a check of res.(CVE-2025-39846)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: vhci: Prevent use-after-free by removing debugfs files early\n\nMove the creation of debugfs files into a dedicated function, and ensure\nthey are explicitly removed during vhci_release(), before associated\ndata structures are freed.\n\nPreviously, debugfs files such as \u0026quot;force_suspend\u0026quot;, \u0026quot;force_wakeup\u0026quot;, and\nothers were created under hdev-\u0026gt;debugfs but not removed in\nvhci_release(). Since vhci_release() frees the backing vhci_data\nstructure, any access to these files after release would result in\nuse-after-free errors.\n\nAlthough hdev-\u0026gt;debugfs is later freed in hci_release_dev(), user can\naccess files after vhci_data is freed but before hdev-\u0026gt;debugfs is\nreleased.(CVE-2025-39861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info work\n\nThe brcmf_btcoex_detach() only shuts down the btcoex timer, if the\nflag timer_on is false. However, the brcmf_btcoex_timerfunc(), which\nruns as timer handler, sets timer_on to false. This creates critical\nrace conditions:\n\n1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()\nis executing, it may observe timer_on as false and skip the call to\ntimer_shutdown_sync().\n\n2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_info\nworker after the cancel_work_sync() has been executed, resulting in\nuse-after-free bugs.\n\nThe use-after-free bugs occur in two distinct scenarios, depending on\nthe timing of when the brcmf_btcoex_info struct is freed relative to\nthe execution of its worker thread.\n\nScenario 1: Freed before the worker is scheduled\n\nThe brcmf_btcoex_info is deallocated before the worker is scheduled.\nA race condition can occur when schedule_work(\u0026amp;bt_local-\u0026gt;work) is\ncalled after the target memory has been freed. The sequence of events\nis detailed below:\n\nCPU0 | CPU1\nbrcmf_btcoex_detach | brcmf_btcoex_timerfunc\n | bt_local-\u0026gt;timer_on = false;\n if (cfg-\u0026gt;btcoex-\u0026gt;timer_on) |\n ... |\n cancel_work_sync(); |\n ... |\n kfree(cfg-\u0026gt;btcoex); // FREE |\n | schedule_work(\u0026amp;bt_local-\u0026gt;work); // USE\n\nScenario 2: Freed after the worker is scheduled\n\nThe brcmf_btcoex_info is freed after the worker has been scheduled\nbut before or during its execution. In this case, statements within\nthe brcmf_btcoex_handler() \u2014 such as the container_of macro and\nsubsequent dereferences of the brcmf_btcoex_info object will cause\na use-after-free access. The following timeline illustrates this\nscenario:\n\nCPU0 | CPU1\nbrcmf_btcoex_detach | brcmf_btcoex_timerfunc\n | bt_local-\u0026gt;timer_on = false;\n if (cfg-\u0026gt;btcoex-\u0026gt;timer_on) |\n ... |\n cancel_work_sync(); |\n ... | schedule_work(); // Reschedule\n |\n kfree(cfg-\u0026gt;btcoex); // FREE | brcmf_btcoex_handler() // Worker\n /* | btci = container_of(....); // USE\n The kfree() above could | ...\n also occur at any point | btci-\u0026gt; // USE\n during the worker\u0026apos;s execution|\n */ |\n\nTo resolve the race conditions, drop the conditional check and call\ntimer_shutdown_sync() directly. It can deactivate the timer reliably,\nregardless of its current state. Once stopped, the timer_on state is\nthen set to false.(CVE-2025-39863)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/lru_sort: avoid divide-by-zero in damon_lru_sort_apply_parameters()\n\nPatch series \u0026quot;mm/damon: avoid divide-by-zero in DAMON module\u0026apos;s parameters\napplication\u0026quot;.\n\nDAMON\u0026apos;s RECLAIM and LRU_SORT modules perform no validation on\nuser-configured parameters during application, which may lead to\ndivision-by-zero errors.\n\nAvoid the divide-by-zero by adding validation checks when DAMON modules\nattempt to apply the parameters.\n\n\nThis patch (of 2):\n\nDuring the calculation of \u0026apos;hot_thres\u0026apos; and \u0026apos;cold_thres\u0026apos;, either\n\u0026apos;sample_interval\u0026apos; or \u0026apos;aggr_interval\u0026apos; is used as the divisor, which may\nlead to division-by-zero errors. Fix it by directly returning -EINVAL\nwhen such a case occurs. Additionally, since \u0026apos;aggr_interval\u0026apos; is already\nrequired to be set no smaller than \u0026apos;sample_interval\u0026apos; in damon_set_attrs(),\nonly the case where \u0026apos;sample_interval\u0026apos; is zero needs to be checked.(CVE-2025-39909)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()\n\nWhen creating a new scheme of DAMON_RECLAIM, the calculation of\n\u0026apos;min_age_region\u0026apos; uses \u0026apos;aggr_interval\u0026apos; as the divisor, which may lead to\ndivision-by-zero errors. Fix it by directly returning -EINVAL when such a\ncase occurs.(CVE-2025-39916)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm: bridge: anx7625: Fix NULL pointer dereference with early IRQ\n\nIf the interrupt occurs before resource initialization is complete, the\ninterrupt handler/worker may access uninitialized data such as the I2C\ntcpc_client device, potentially leading to NULL pointer dereference.(CVE-2025-39934)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: wilc1000: avoid buffer overflow in WID string configuration\n\nFix the following copy overflow warning identified by Smatch checker.\n\n drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()\n error: \u0026apos;__memcpy()\u0026apos; \u0026apos;cfg-\u0026gt;s[i]-\u0026gt;str\u0026apos; copy overflow (512 vs 65537)\n\nThis patch introduces size check before accessing the memory buffer.\nThe checks are base on the WID type of received data from the firmware.\nFor WID string configuration, the size limit is determined by individual\nelement size in \u0026apos;struct wilc_cfg_str_vals\u0026apos; that is maintained in \u0026apos;len\u0026apos; field\nof \u0026apos;struct wilc_cfg_str\u0026apos;.(CVE-2025-39952)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn\u0026apos;t valid\n\nSkip the WRMSR and HLT fastpaths in SVM\u0026apos;s VM-Exit handler if the next RIP\nisn\u0026apos;t valid, e.g. because KVM is running with nrips=false. SVM must\ndecode and emulate to skip the instruction if the CPU doesn\u0026apos;t provide the\nnext RIP, and getting the instruction bytes to decode requires reading\nguest memory. Reading guest memory through the emulator can fault, i.e.\ncan sleep, which is disallowed since the fastpath handlers run with IRQs\ndisabled.\n\n BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106\n in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 32611, name: qemu\n preempt_count: 1, expected: 0\n INFO: lockdep is turned off.\n irq event stamp: 30580\n hardirqs last enabled at (30579): [\u0026lt;ffffffffc08b2527\u0026gt;] vcpu_run+0x1787/0x1db0 [kvm]\n hardirqs last disabled at (30580): [\u0026lt;ffffffffb4f62e32\u0026gt;] __schedule+0x1e2/0xed0\n softirqs last enabled at (30570): [\u0026lt;ffffffffb4247a64\u0026gt;] fpu_swap_kvm_fpstate+0x44/0x210\n softirqs last disabled at (30568): [\u0026lt;ffffffffb4247a64\u0026gt;] fpu_swap_kvm_fpstate+0x44/0x210\n CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE\n Tainted: [U]=USER\n Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7d/0xb0\n __might_resched+0x271/0x290\n __might_fault+0x28/0x80\n kvm_vcpu_read_guest_page+0x8d/0xc0 [kvm]\n kvm_fetch_guest_virt+0x92/0xc0 [kvm]\n __do_insn_fetch_bytes+0xf3/0x1e0 [kvm]\n x86_decode_insn+0xd1/0x1010 [kvm]\n x86_emulate_instruction+0x105/0x810 [kvm]\n __svm_skip_emulated_instruction+0xc4/0x140 [kvm_amd]\n handle_fastpath_invd+0xc4/0x1a0 [kvm]\n vcpu_run+0x11a1/0x1db0 [kvm]\n kvm_arch_vcpu_ioctl_run+0x5cc/0x730 [kvm]\n kvm_vcpu_ioctl+0x578/0x6a0 [kvm]\n __se_sys_ioctl+0x6d/0xb0\n do_syscall_64+0x8a/0x2c0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x7f479d57a94b\n \u0026lt;/TASK\u0026gt;\n\nNote, this is essentially a reapply of commit 5c30e8101e8d (\u0026quot;KVM: SVM:\nSkip WRMSR fastpath on VM-Exit if next RIP isn\u0026apos;t valid\u0026quot;), but with\ndifferent justification (KVM now grabs SRCU when skipping the instruction\nfor other reasons).(CVE-2025-40038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential null deref in ext4_mb_init()\n\nIn ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called\nwhen sbi-\u0026gt;s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo\nslab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy()\nlacks null pointer checking, this leads to a null pointer dereference.\n\n==================================================================\nEXT4-fs: no memory for groupinfo slab cache\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: Oops: 0002 [#1] SMP PTI\nCPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none)\nRIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40\nCall Trace:\n \u0026lt;TASK\u0026gt;\n xa_destroy+0x61/0x130\n ext4_mb_init+0x483/0x540\n __ext4_fill_super+0x116d/0x17b0\n ext4_fill_super+0xd3/0x280\n get_tree_bdev_flags+0x132/0x1d0\n vfs_get_tree+0x29/0xd0\n do_new_mount+0x197/0x300\n __x64_sys_mount+0x116/0x150\n do_syscall_64+0x50/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n==================================================================\n\nTherefore, add necessary null check to ext4_mb_avg_fragment_size_destroy()\nto prevent this issue. The same fix is also applied to\next4_mb_largest_free_orders_destroy().(CVE-2025-40119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nEDAC/i10nm: Skip DIMM enumeration on a disabled memory controller\n\nWhen loading the i10nm_edac driver on some Intel Granite Rapids servers,\na call trace may appear as follows:\n\n UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16\n shift exponent -66 is negative\n ...\n __ubsan_handle_shift_out_of_bounds+0x1e3/0x390\n skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]\n i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]\n skx_register_mci+0x159/0x220 [skx_edac_common]\n i10nm_init+0xcb0/0x1ff0 [i10nm_edac]\n ...\n\nThis occurs because some BIOS may disable a memory controller if there\naren\u0026apos;t any memory DIMMs populated on this memory controller. The DIMMMTR\nregister of this disabled memory controller contains the invalid value\n~0, resulting in the call trace above.\n\nFix this call trace by skipping DIMM enumeration on a disabled memory\ncontroller.(CVE-2025-40157)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs: quota: create dedicated workqueue for quota_release_work\n\nThere is a kernel panic due to WARN_ONCE when panic_on_warn is set.\n\nThis issue occurs when writeback is triggered due to sync call for an\nopened file(ie, writeback reason is WB_REASON_SYNC). When f2fs balance\nis needed at sync path, flush for quota_release_work is triggered.\nBy default quota_release_work is queued to \u0026quot;events_unbound\u0026quot; queue which\ndoes not have WQ_MEM_RECLAIM flag. During f2fs balance \u0026quot;writeback\u0026quot;\nworkqueue tries to flush quota_release_work causing kernel panic due to\nMEM_RECLAIM flag mismatch errors.\n\nThis patch creates dedicated workqueue with WQ_MEM_RECLAIM flag\nfor work quota_release_work.\n\n------------[ cut here ]------------\nWARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 check_flush_dependency+0x13c/0x148\nCall trace:\n check_flush_dependency+0x13c/0x148\n __flush_work+0xd0/0x398\n flush_delayed_work+0x44/0x5c\n dquot_writeback_dquots+0x54/0x318\n f2fs_do_quota_sync+0xb8/0x1a8\n f2fs_write_checkpoint+0x3cc/0x99c\n f2fs_gc+0x190/0x750\n f2fs_balance_fs+0x110/0x168\n f2fs_write_single_data_page+0x474/0x7dc\n f2fs_write_data_pages+0x7d0/0xd0c\n do_writepages+0xe0/0x2f4\n __writeback_single_inode+0x44/0x4ac\n writeback_sb_inodes+0x30c/0x538\n wb_writeback+0xf4/0x440\n wb_workfn+0x128/0x5d4\n process_scheduled_works+0x1c4/0x45c\n worker_thread+0x32c/0x3e8\n kthread+0x11c/0x1b0\n ret_from_fork+0x10/0x20\nKernel panic - not syncing: kernel: panic_on_warn set ...(CVE-2025-40196)\n\nIn the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try(). v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try().(CVE-2025-40207)",
"id": "OESA-2025-2700",
"modified": "2026-08-06T11:09:49Z",
"published": "2025-11-22T11:09:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2700"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23140"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38059"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38132"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38155"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38167"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38206"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38326"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38348"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38640"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38696"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38718"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38734"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39693"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39711"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39716"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39719"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39726"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39767"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39781"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39842"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39846"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39863"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39909"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39916"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39934"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39952"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40038"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40119"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40157"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40196"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40207"
}
],
"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-2025-23140",
"CVE-2025-38059",
"CVE-2025-38132",
"CVE-2025-38155",
"CVE-2025-38167",
"CVE-2025-38206",
"CVE-2025-38326",
"CVE-2025-38348",
"CVE-2025-38640",
"CVE-2025-38696",
"CVE-2025-38718",
"CVE-2025-38734",
"CVE-2025-39693",
"CVE-2025-39711",
"CVE-2025-39716",
"CVE-2025-39719",
"CVE-2025-39726",
"CVE-2025-39767",
"CVE-2025-39781",
"CVE-2025-39794",
"CVE-2025-39808",
"CVE-2025-39842",
"CVE-2025-39846",
"CVE-2025-39861",
"CVE-2025-39863",
"CVE-2025-39909",
"CVE-2025-39916",
"CVE-2025-39934",
"CVE-2025-39952",
"CVE-2025-40038",
"CVE-2025-40119",
"CVE-2025-40157",
"CVE-2025-40196",
"CVE-2025-40207"
]
}
oesa-2026-1950
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:
btrfs: fix extent map use-after-free when handling missing device in read_one_chunk
Store the error code before freeing the extent_map. Though it's reference counted structure, in that function it's the first and last allocation so this would lead to a potential use-after-free.
The error can happen eg. when chunk is stored on a missing device and the degraded mount option is missing.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721(CVE-2022-50300)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix locking in pdc_iodc_print() firmware call
Utilize pdc_lock spinlock to protect parallel modifications of the iodc_dbuf[] buffer, check length to prevent buffer overflow of iodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong indentings.(CVE-2022-50518)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Add length check in indx_get_root
This adds a length check to guarantee the retrieved index root is legit.
[ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320 [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243 [ 162.460851] [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42 [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 162.462609] Call Trace: [ 162.462954] <TASK> [ 162.463276] dump_stack_lvl+0x49/0x63 [ 162.463822] print_report.cold+0xf5/0x689 [ 162.464608] ? unwind_get_return_address+0x3a/0x60 [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.466975] kasan_report+0xa7/0x130 [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0 [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320 [ 162.468536] __asan_load2+0x68/0x90 [ 162.468923] hdr_find_e.isra.0+0x10c/0x320 [ 162.469282] ? cmp_uints+0xe0/0xe0 [ 162.469557] ? cmp_sdh+0x90/0x90 [ 162.469864] ? ni_find_attr+0x214/0x300 [ 162.470217] ? ni_load_mi+0x80/0x80 [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.470931] ? ntfs_bread_run+0x190/0x190 [ 162.471307] ? indx_get_root+0xe4/0x190 [ 162.471556] ? indx_get_root+0x140/0x190 [ 162.471833] ? indx_init+0x1e0/0x1e0 [ 162.472069] ? fnd_clear+0x115/0x140 [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100 [ 162.472731] indx_find+0x184/0x470 [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0 [ 162.474704] ? do_syscall_64+0x3b/0x90 [ 162.474962] dir_search_u+0x196/0x2f0 [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450 [ 162.475661] ? ntfs_security_init+0x3d6/0x440 [ 162.475906] ? is_sd_valid+0x180/0x180 [ 162.476191] ntfs_extend_init+0x13f/0x2c0 [ 162.476496] ? ntfs_fix_post_read+0x130/0x130 [ 162.476861] ? iput.part.0+0x286/0x320 [ 162.477325] ntfs_fill_super+0x11e0/0x1b50 [ 162.477709] ? put_ntfs+0x1d0/0x1d0 [ 162.477970] ? vsprintf+0x20/0x20 [ 162.478258] ? set_blocksize+0x95/0x150 [ 162.478538] get_tree_bdev+0x232/0x370 [ 162.478789] ? put_ntfs+0x1d0/0x1d0 [ 162.479038] ntfs_fs_get_tree+0x15/0x20 [ 162.479374] vfs_get_tree+0x4c/0x130 [ 162.479729] path_mount+0x654/0xfe0 [ 162.480124] ? putname+0x80/0xa0 [ 162.480484] ? finish_automount+0x2e0/0x2e0 [ 162.480894] ? putname+0x80/0xa0 [ 162.481467] ? kmem_cache_free+0x1c4/0x440 [ 162.482280] ? putname+0x80/0xa0 [ 162.482714] do_mount+0xd6/0xf0 [ 162.483264] ? path_mount+0xfe0/0xfe0 [ 162.484782] ? __kasan_check_write+0x14/0x20 [ 162.485593] __x64_sys_mount+0xca/0x110 [ 162.486024] do_syscall_64+0x3b/0x90 [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 162.487141] RIP: 0033:0x7f9d374e948a [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0 [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020 [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0 [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff [ 162.493644] </TASK> [ 162.493908] [ 162.494214] The buggy address belongs to the physical page: [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000 [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000 [ 162.500542] page dumped becau ---truncated---(CVE-2023-53194)
In the Linux kernel, the following vulnerability has been resolved:
rpl: Fix use-after-free in rpl_do_srh_inline().
Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers the splat below [0].
rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after skb_cow_head(), which is illegal as the header could be freed then.
Let's fix it by making oldhdr to a local struct instead of a pointer.
[0]: [root@fedora net]# ./lwt_dst_cache_ref_loop.sh ... TEST: rpl (input) [ 57.631529] ================================================================== BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) Read of size 40 at addr ffff888122bf96d8 by task ping6/1543
CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:409 mm/kasan/report.c:521) kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636) kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1)) __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2)) rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174) rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282) lwtunnel_input (net/core/lwtunnel.c:459) ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1)) __netif_receive_skb_one_core (net/core/dev.c:5967) process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440) __napi_poll.constprop.0 (net/core/dev.c:7452) net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643) handle_softirqs (kernel/softirq.c:579) do_softirq (kernel/softirq.c:480 (discriminator 20)) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:407) __dev_queue_xmit (net/core/dev.c:4740) ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141) ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226) ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248) ip6_send_skb (net/ipv6/ip6_output.c:1983) rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918) __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1)) __x64_sys_sendto (net/socket.c:2231) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f68cffb2a06 Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08 RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06 RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003 RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4 R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0 </TASK>
Allocated by task 1543: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1)) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249) kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88)) __alloc_skb (net/core/skbuff.c:669) __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1)) ip6_ ---truncated---(CVE-2025-38476)
In the Linux kernel, the following vulnerability has been resolved:
ARM: tegra: Use I/O memcpy to write to IRAM
Kasan crashes the kernel trying to check boundaries when using the normal memcpy.(CVE-2025-39794)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: avoid potential out-of-bounds in btrfs_encode_fh()
The function btrfs_encode_fh() does not properly account for the three cases it handles.
Before writing to the file handle (fh), the function only returns to the user BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or BTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).
However, when a parent exists and the root ID of the parent and the inode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT (10 dwords, 40 bytes).
If *max_len is not large enough, this write goes out of bounds because BTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than BTRFS_FID_SIZE_CONNECTABLE originally returned.
This results in an 8-byte out-of-bounds write at fid->parent_root_objectid = parent_root_id.
A previous attempt to fix this issue was made but was lost.
https://lore.kernel.org/all/(CVE-2025-40205)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-core: fix wrong reinitialization of ringbuffer on reopen
dvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the DVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which reinitializes the waitqueue list head to empty.
Since dmxdev->dvr_buffer.queue is a shared waitqueue (all opens of the same DVR device share it), this orphans any existing waitqueue entries from io_uring poll or epoll, leaving them with stale prev/next pointers while the list head is reset to {self, self}.
The waitqueue and spinlock in dvr_buffer are already properly initialized once in dvb_dmxdev_init(). The open path only needs to reset the buffer data pointer, size, and read/write positions.
Replace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct assignment of data/size and a call to dvb_ringbuffer_reset(), which properly resets pread, pwrite, and error with correct memory ordering without touching the waitqueue or spinlock.(CVE-2026-23253)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: validate DFA start states are in bounds in unpack_pdb
Start states are read from untrusted data and used as indexes into the DFA state tables. The aa_dfa_next() function call in unpack_pdb() will access dfa->tables[YYTD_ID_BASE][start], and if the start state exceeds the number of states in the DFA, this results in an out-of-bound read.
================================================================== BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360 Read of size 4 at addr ffff88811956fb90 by task su/1097 ...
Reject policies with out-of-bounds start states during unpacking to prevent the issue.(CVE-2026-23269)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix memory leak in ice_set_ringparam()
In ice_set_ringparam, tx_rings and xdp_rings are allocated before rx_rings. If the allocation of rx_rings fails, the code jumps to the done label leaking both tx_rings and xdp_rings. Furthermore, if the setup of an individual Rx ring fails during the loop, the code jumps to the free_tx label which releases tx_rings but leaks xdp_rings.
Fix this by introducing a free_xdp label and updating the error paths to ensure both xdp_rings and tx_rings are properly freed if rx_rings allocation or setup fails.
Compile tested only. Issue found using a prototype static analysis tool and code review.(CVE-2026-23389)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: replace recursive profile removal with iterative approach
The profile removal code uses recursion when removing nested profiles, which can lead to kernel stack exhaustion and system crashes.
Reproducer: $ pf='a'; for ((i=0; i<1024; i++)); do echo -e "profile $pf { \n }" | apparmor_parser -K -a; pf="$pf//x"; done $ echo -n a > /sys/kernel/security/apparmor/.remove
Replace the recursive __aa_profile_list_release() approach with an iterative approach in __remove_profile(). The function repeatedly finds and removes leaf profiles until the entire subtree is removed, maintaining the same removal semantic without recursion.(CVE-2026-23404)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: fix: limit the number of levels of policy namespaces
Currently the number of policy namespaces is not bounded relying on the user namespace limit. However policy namespaces aren't strictly tied to user namespaces and it is possible to create them and nest them arbitrarily deep which can be used to exhaust system resource.
Hard cap policy namespaces to the same depth as user namespaces.(CVE-2026-23405)
A vulnerability exists in the AppArmor security module of the Linux kernel, stemming from a side-effect bug in the usage of the match_char macro. This macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the Deterministic Finite Automaton (DFA) to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary. This vulnerability may impact the confidentiality of the kernel.(CVE-2026-23406)
An out-of-bounds read and write vulnerability exists in the AppArmor security module of the Linux kernel. In the verify_dfa() function, while traversing the differential encoding chain, it reads k = DEFAULT_TABLE[j] and uses k as an array index without validating whether k is within the bounds of the valid state count (state_count). If an attacker can supply a malicious Deterministic Finite Automaton (DFA) with a crafted value where DEFAULT_TABLE[j] >= state_count, it will lead to out-of-bounds reads and writes. This vulnerability may impact the confidentiality and stability of the kernel.(CVE-2026-23407)
In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix double free of ns_name in aa_replace_profiles()
if ns_name is NULL after 1071 error = aa_unpack(udata, &lh, &ns_name);
and if ent->ns_name contains an ns_name in 1089 } else if (ent->ns_name) {
then ns_name is assigned the ent->ns_name 1095 ns_name = ent->ns_name;
however ent->ns_name is freed at 1262 aa_load_ent_free(ent);
and then again when freeing ns_name at 1270 kfree(ns_name);
Fix this by NULLing out ent->ns_name after it is transferred to ns_name
")(CVE-2026-23408)
A race condition vulnerability exists in the AppArmor security module of the Linux kernel, leading to a use-after-free issue. This vulnerability can be triggered when an attacker simultaneously opens rawdata files and removes an associated AppArmor profile. Since rawdata inodes are not refcounted, there is a time window during profile removal where the i_private pointer may reference freed memory, causing the system to access freed memory regions. This can result in program crashes, unexpected value usage, or arbitrary code execution, threatening the confidentiality, integrity, and availability of the system.(CVE-2026-23410)
A vulnerability exists in the AppArmor security module of the Linux kernel when handling the i_private field of the inode structure. AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs callback functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. This vulnerability could allow a local attacker to bypass AppArmor's access control policies through a specially crafted request, leading to privilege escalation and impacting system confidentiality, integrity, and availability.(CVE-2026-23411)
In the Linux kernel, the following vulnerability has been resolved:
PM: runtime: Fix a race condition related to device removal
The following code in pm_runtime_work() may dereference the dev->parent pointer after the parent device has been freed:
/* Maybe the parent is now able to suspend. */
if (parent && !parent->power.ignore_children) {
spin_unlock(&dev->power.lock);
spin_lock(&parent->power.lock);
rpm_idle(parent, RPM_ASYNC);
spin_unlock(&parent->power.lock);
spin_lock(&dev->power.lock);
}
Fix this by inserting a flush_work() call in pm_runtime_remove().
Without this patch blktest block/001 triggers the following complaint sporadically:
BUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160 Read of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081 Workqueue: pm pm_runtime_work Call Trace: <TASK> dump_stack_lvl+0x61/0x80 print_address_description.constprop.0+0x8b/0x310 print_report+0xfd/0x1d7 kasan_report+0xd8/0x1d0 __kasan_check_byte+0x42/0x60 lock_acquire.part.0+0x38/0x230 lock_acquire+0x70/0x160 _raw_spin_lock+0x36/0x50 rpm_suspend+0xc6a/0xfe0 rpm_idle+0x578/0x770 pm_runtime_work+0xee/0x120 process_one_work+0xde3/0x1410 worker_thread+0x5eb/0xfe0 kthread+0x37b/0x480 ret_from_fork+0x6cb/0x920 ret_from_fork_asm+0x11/0x20 </TASK>
Allocated by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_alloc_info+0x3d/0x50 __kasan_kmalloc+0xa0/0xb0 __kmalloc_noprof+0x311/0x990 scsi_alloc_target+0x122/0xb60 [scsi_mod] __scsi_scan_target+0x101/0x460 [scsi_mod] scsi_scan_channel+0x179/0x1c0 [scsi_mod] scsi_scan_host_selected+0x259/0x2d0 [scsi_mod] store_scan+0x2d2/0x390 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810 do_syscall_64+0xee/0xfc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53
Freed by task 4314: kasan_save_stack+0x2a/0x50 kasan_save_track+0x18/0x40 kasan_save_free_info+0x3f/0x50 __kasan_slab_free+0x67/0x80 kfree+0x225/0x6c0 scsi_target_dev_release+0x3d/0x60 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_dev_release+0xacf/0x12c0 [scsi_mod] device_release+0xa3/0x220 kobject_cleanup+0x105/0x3a0 kobject_put+0x72/0xd0 put_device+0x17/0x20 scsi_device_put+0x7f/0xc0 [scsi_mod] sdev_store_delete+0xa5/0x120 [scsi_mod] dev_attr_store+0x43/0x80 sysfs_kf_write+0xde/0x140 kernfs_fop_write_iter+0x3ef/0x670 vfs_write+0x506/0x1470 ksys_write+0xfd/0x230 __x64_sys_write+0x76/0xc0 x64_sys_call+0x213/0x1810(CVE-2026-23452)
In the Linux kernel, the Bluetooth SCO module's sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn->sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk->sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)
In the Linux kernel, the following vulnerability has been resolved:
xen/privcmd: restrict usage in unprivileged domU
The Xen privcmd driver allows to issue arbitrary hypercalls from user space processes. This is normally no problem, as access is usually limited to root and the hypervisor will deny any hypercalls affecting other domains.
In case the guest is booted using secure boot, however, the privcmd driver would be enabling a root user process to modify e.g. kernel memory contents, thus breaking the secure boot feature.
The only known case where an unprivileged domU is really needing to use the privcmd driver is the case when it is acting as the device model for another guest. In this case all hypercalls issued via the privcmd driver will target that other guest.
Fortunately the privcmd driver can already be locked down to allow only hypercalls targeting a specific domain, but this mode can be activated from user land only today.
The target domain can be obtained from Xenstore, so when not running in dom0 restrict the privcmd driver to that target domain from the beginning, resolving the potential problem of breaking secure boot.
This is XSA-482
V2: - defer reading from Xenstore if Xenstore isn't ready yet (Jan Beulich) - wait in open() if target domain isn't known yet - issue message in case no target domain found (Jan Beulich)(CVE-2026-31788)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"perf-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-309.0.0.212.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-309.0.0.212.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"perf-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-309.0.0.212.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-309.0.0.212.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-309.0.0.212.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\nbtrfs: fix extent map use-after-free when handling missing device in read_one_chunk\n\nStore the error code before freeing the extent_map. Though it\u0026apos;s\nreference counted structure, in that function it\u0026apos;s the first and last\nallocation so this would lead to a potential use-after-free.\n\nThe error can happen eg. when chunk is stored on a missing device and\nthe degraded mount option is missing.\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721(CVE-2022-50300)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix locking in pdc_iodc_print() firmware call\n\nUtilize pdc_lock spinlock to protect parallel modifications of the\niodc_dbuf[] buffer, check length to prevent buffer overflow of\niodc_dbuf[], drop the iodc_retbuf[] buffer and fix some wrong\nindentings.(CVE-2022-50518)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Add length check in indx_get_root\n\nThis adds a length check to guarantee the retrieved index root is legit.\n\n[ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320\n[ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243\n[ 162.460851]\n[ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42\n[ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[ 162.462609] Call Trace:\n[ 162.462954] \u0026lt;TASK\u0026gt;\n[ 162.463276] dump_stack_lvl+0x49/0x63\n[ 162.463822] print_report.cold+0xf5/0x689\n[ 162.464608] ? unwind_get_return_address+0x3a/0x60\n[ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320\n[ 162.466975] kasan_report+0xa7/0x130\n[ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0\n[ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320\n[ 162.468536] __asan_load2+0x68/0x90\n[ 162.468923] hdr_find_e.isra.0+0x10c/0x320\n[ 162.469282] ? cmp_uints+0xe0/0xe0\n[ 162.469557] ? cmp_sdh+0x90/0x90\n[ 162.469864] ? ni_find_attr+0x214/0x300\n[ 162.470217] ? ni_load_mi+0x80/0x80\n[ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 162.470931] ? ntfs_bread_run+0x190/0x190\n[ 162.471307] ? indx_get_root+0xe4/0x190\n[ 162.471556] ? indx_get_root+0x140/0x190\n[ 162.471833] ? indx_init+0x1e0/0x1e0\n[ 162.472069] ? fnd_clear+0x115/0x140\n[ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100\n[ 162.472731] indx_find+0x184/0x470\n[ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0\n[ 162.474429] ? indx_find_buffer+0x2d0/0x2d0\n[ 162.474704] ? do_syscall_64+0x3b/0x90\n[ 162.474962] dir_search_u+0x196/0x2f0\n[ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450\n[ 162.475661] ? ntfs_security_init+0x3d6/0x440\n[ 162.475906] ? is_sd_valid+0x180/0x180\n[ 162.476191] ntfs_extend_init+0x13f/0x2c0\n[ 162.476496] ? ntfs_fix_post_read+0x130/0x130\n[ 162.476861] ? iput.part.0+0x286/0x320\n[ 162.477325] ntfs_fill_super+0x11e0/0x1b50\n[ 162.477709] ? put_ntfs+0x1d0/0x1d0\n[ 162.477970] ? vsprintf+0x20/0x20\n[ 162.478258] ? set_blocksize+0x95/0x150\n[ 162.478538] get_tree_bdev+0x232/0x370\n[ 162.478789] ? put_ntfs+0x1d0/0x1d0\n[ 162.479038] ntfs_fs_get_tree+0x15/0x20\n[ 162.479374] vfs_get_tree+0x4c/0x130\n[ 162.479729] path_mount+0x654/0xfe0\n[ 162.480124] ? putname+0x80/0xa0\n[ 162.480484] ? finish_automount+0x2e0/0x2e0\n[ 162.480894] ? putname+0x80/0xa0\n[ 162.481467] ? kmem_cache_free+0x1c4/0x440\n[ 162.482280] ? putname+0x80/0xa0\n[ 162.482714] do_mount+0xd6/0xf0\n[ 162.483264] ? path_mount+0xfe0/0xfe0\n[ 162.484782] ? __kasan_check_write+0x14/0x20\n[ 162.485593] __x64_sys_mount+0xca/0x110\n[ 162.486024] do_syscall_64+0x3b/0x90\n[ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 162.487141] RIP: 0033:0x7f9d374e948a\n[ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5\n[ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a\n[ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0\n[ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020\n[ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0\n[ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff\n[ 162.493644] \u0026lt;/TASK\u0026gt;\n[ 162.493908]\n[ 162.494214] The buggy address belongs to the physical page:\n[ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc\n[ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\n[ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000\n[ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000\n[ 162.500542] page dumped becau\n---truncated---(CVE-2023-53194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrpl: Fix use-after-free in rpl_do_srh_inline().\n\nRunning lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers\nthe splat below [0].\n\nrpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after\nskb_cow_head(), which is illegal as the header could be freed then.\n\nLet\u0026apos;s fix it by making oldhdr to a local struct instead of a pointer.\n\n[0]:\n[root@fedora net]# ./lwt_dst_cache_ref_loop.sh\n...\nTEST: rpl (input)\n[ 57.631529] ==================================================================\nBUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)\nRead of size 40 at addr ffff888122bf96d8 by task ping6/1543\n\nCPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:122)\n print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)\n kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)\n kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))\n __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2))\n rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)\n rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)\n lwtunnel_input (net/core/lwtunnel.c:459)\n ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))\n __netif_receive_skb_one_core (net/core/dev.c:5967)\n process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)\n __napi_poll.constprop.0 (net/core/dev.c:7452)\n net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)\n handle_softirqs (kernel/softirq.c:579)\n do_softirq (kernel/softirq.c:480 (discriminator 20))\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip (kernel/softirq.c:407)\n __dev_queue_xmit (net/core/dev.c:4740)\n ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)\n ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)\n ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)\n ip6_send_skb (net/ipv6/ip6_output.c:1983)\n rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)\n __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))\n __x64_sys_sendto (net/socket.c:2231)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\nRIP: 0033:0x7f68cffb2a06\nCode: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 \u0026lt;48\u0026gt; 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08\nRSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06\nRDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003\nRBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4\nR13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 1543:\n kasan_save_stack (mm/kasan/common.c:48)\n kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))\n __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)\n kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)\n kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88))\n __alloc_skb (net/core/skbuff.c:669)\n __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1))\n ip6_\n---truncated---(CVE-2025-38476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: tegra: Use I/O memcpy to write to IRAM\n\nKasan crashes the kernel trying to check boundaries when using the\nnormal memcpy.(CVE-2025-39794)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: avoid potential out-of-bounds in btrfs_encode_fh()\n\nThe function btrfs_encode_fh() does not properly account for the three\ncases it handles.\n\nBefore writing to the file handle (fh), the function only returns to the\nuser BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) or\nBTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).\n\nHowever, when a parent exists and the root ID of the parent and the\ninode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT\n(10 dwords, 40 bytes).\n\nIf *max_len is not large enough, this write goes out of bounds because\nBTRFS_FID_SIZE_CONNECTABLE_ROOT is greater than\nBTRFS_FID_SIZE_CONNECTABLE originally returned.\n\nThis results in an 8-byte out-of-bounds write at\nfid-\u0026gt;parent_root_objectid = parent_root_id.\n\nA previous attempt to fix this issue was made but was lost.\n\nhttps://lore.kernel.org/all/(CVE-2025-40205)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-core: fix wrong reinitialization of ringbuffer on reopen\n\ndvb_dvr_open() calls dvb_ringbuffer_init() when a new reader opens the\nDVR device. dvb_ringbuffer_init() calls init_waitqueue_head(), which\nreinitializes the waitqueue list head to empty.\n\nSince dmxdev-\u0026gt;dvr_buffer.queue is a shared waitqueue (all opens of the\nsame DVR device share it), this orphans any existing waitqueue entries\nfrom io_uring poll or epoll, leaving them with stale prev/next pointers\nwhile the list head is reset to {self, self}.\n\nThe waitqueue and spinlock in dvr_buffer are already properly\ninitialized once in dvb_dmxdev_init(). The open path only needs to\nreset the buffer data pointer, size, and read/write positions.\n\nReplace the dvb_ringbuffer_init() call in dvb_dvr_open() with direct\nassignment of data/size and a call to dvb_ringbuffer_reset(), which\nproperly resets pread, pwrite, and error with correct memory ordering\nwithout touching the waitqueue or spinlock.(CVE-2026-23253)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: validate DFA start states are in bounds in unpack_pdb\n\nStart states are read from untrusted data and used as indexes into the\nDFA state tables. The aa_dfa_next() function call in unpack_pdb() will\naccess dfa-\u0026gt;tables[YYTD_ID_BASE][start], and if the start state exceeds\nthe number of states in the DFA, this results in an out-of-bound read.\n\n==================================================================\n BUG: KASAN: slab-out-of-bounds in aa_dfa_next+0x2a1/0x360\n Read of size 4 at addr ffff88811956fb90 by task su/1097\n ...\n\nReject policies with out-of-bounds start states during unpacking\nto prevent the issue.(CVE-2026-23269)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix memory leak in ice_set_ringparam()\n\nIn ice_set_ringparam, tx_rings and xdp_rings are allocated before\nrx_rings. If the allocation of rx_rings fails, the code jumps to\nthe done label leaking both tx_rings and xdp_rings. Furthermore, if\nthe setup of an individual Rx ring fails during the loop, the code jumps\nto the free_tx label which releases tx_rings but leaks xdp_rings.\n\nFix this by introducing a free_xdp label and updating the error paths to\nensure both xdp_rings and tx_rings are properly freed if rx_rings\nallocation or setup fails.\n\nCompile tested only. Issue found using a prototype static analysis tool\nand code review.(CVE-2026-23389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: replace recursive profile removal with iterative approach\n\nThe profile removal code uses recursion when removing nested profiles,\nwhich can lead to kernel stack exhaustion and system crashes.\n\nReproducer:\n $ pf=\u0026apos;a\u0026apos;; for ((i=0; i\u0026lt;1024; i++)); do\n echo -e \u0026quot;profile $pf { \\n }\u0026quot; | apparmor_parser -K -a;\n pf=\u0026quot;$pf//x\u0026quot;;\n done\n $ echo -n a \u0026gt; /sys/kernel/security/apparmor/.remove\n\nReplace the recursive __aa_profile_list_release() approach with an\niterative approach in __remove_profile(). The function repeatedly\nfinds and removes leaf profiles until the entire subtree is removed,\nmaintaining the same removal semantic without recursion.(CVE-2026-23404)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix: limit the number of levels of policy namespaces\n\nCurrently the number of policy namespaces is not bounded relying on\nthe user namespace limit. However policy namespaces aren\u0026apos;t strictly\ntied to user namespaces and it is possible to create them and nest\nthem arbitrarily deep which can be used to exhaust system resource.\n\nHard cap policy namespaces to the same depth as user namespaces.(CVE-2026-23405)\n\nA vulnerability exists in the AppArmor security module of the Linux kernel, stemming from a side-effect bug in the usage of the match_char macro. This macro evaluates its character parameter multiple times when traversing differential encoding chains. When invoked with *str++, the string pointer advances on each iteration of the inner do-while loop, causing the Deterministic Finite Automaton (DFA) to check different characters at each iteration and therefore skip input characters. This results in out-of-bounds reads when the pointer advances past the input buffer boundary. This vulnerability may impact the confidentiality of the kernel.(CVE-2026-23406)\n\nAn out-of-bounds read and write vulnerability exists in the AppArmor security module of the Linux kernel. In the verify_dfa() function, while traversing the differential encoding chain, it reads `k = DEFAULT_TABLE[j]` and uses `k` as an array index without validating whether `k` is within the bounds of the valid state count (state_count). If an attacker can supply a malicious Deterministic Finite Automaton (DFA) with a crafted value where `DEFAULT_TABLE[j] \u0026gt;= state_count`, it will lead to out-of-bounds reads and writes. This vulnerability may impact the confidentiality and stability of the kernel.(CVE-2026-23407)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: Fix double free of ns_name in aa_replace_profiles()\n\nif ns_name is NULL after\n1071 error = aa_unpack(udata, \u0026amp;lh, \u0026amp;ns_name);\n\nand if ent-\u0026gt;ns_name contains an ns_name in\n1089 } else if (ent-\u0026gt;ns_name) {\n\nthen ns_name is assigned the ent-\u0026gt;ns_name\n1095 ns_name = ent-\u0026gt;ns_name;\n\nhowever ent-\u0026gt;ns_name is freed at\n1262 aa_load_ent_free(ent);\n\nand then again when freeing ns_name at\n1270 kfree(ns_name);\n\nFix this by NULLing out ent-\u0026gt;ns_name after it is transferred to ns_name\n\n\u0026quot;)(CVE-2026-23408)\n\nA race condition vulnerability exists in the AppArmor security module of the Linux kernel, leading to a use-after-free issue. This vulnerability can be triggered when an attacker simultaneously opens rawdata files and removes an associated AppArmor profile. Since rawdata inodes are not refcounted, there is a time window during profile removal where the i_private pointer may reference freed memory, causing the system to access freed memory regions. This can result in program crashes, unexpected value usage, or arbitrary code execution, threatening the confidentiality, integrity, and availability of the system.(CVE-2026-23410)\n\nA vulnerability exists in the AppArmor security module of the Linux kernel when handling the i_private field of the inode structure. AppArmor was putting the reference to i_private data on its end after removing the original entry from the file system. However the inode can and does live beyond that point and it is possible that some of the fs callback functions will be invoked after the reference has been put, which results in a race between freeing the data and accessing it through the fs. While the rawdata/loaddata is the most likely candidate to fail the race, as it has the fewest references. If properly crafted it might be possible to trigger a race for the other types stored in i_private. This vulnerability could allow a local attacker to bypass AppArmor\u0026apos;s access control policies through a specially crafted request, leading to privilege escalation and impacting system confidentiality, integrity, and availability.(CVE-2026-23411)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPM: runtime: Fix a race condition related to device removal\n\nThe following code in pm_runtime_work() may dereference the dev-\u0026gt;parent\npointer after the parent device has been freed:\n\n\t/* Maybe the parent is now able to suspend. */\n\tif (parent \u0026amp;\u0026amp; !parent-\u0026gt;power.ignore_children) {\n\t\tspin_unlock(\u0026amp;dev-\u0026gt;power.lock);\n\n\t\tspin_lock(\u0026amp;parent-\u0026gt;power.lock);\n\t\trpm_idle(parent, RPM_ASYNC);\n\t\tspin_unlock(\u0026amp;parent-\u0026gt;power.lock);\n\n\t\tspin_lock(\u0026amp;dev-\u0026gt;power.lock);\n\t}\n\nFix this by inserting a flush_work() call in pm_runtime_remove().\n\nWithout this patch blktest block/001 triggers the following complaint\nsporadically:\n\nBUG: KASAN: slab-use-after-free in lock_acquire+0x70/0x160\nRead of size 1 at addr ffff88812bef7198 by task kworker/u553:1/3081\nWorkqueue: pm pm_runtime_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x61/0x80\n print_address_description.constprop.0+0x8b/0x310\n print_report+0xfd/0x1d7\n kasan_report+0xd8/0x1d0\n __kasan_check_byte+0x42/0x60\n lock_acquire.part.0+0x38/0x230\n lock_acquire+0x70/0x160\n _raw_spin_lock+0x36/0x50\n rpm_suspend+0xc6a/0xfe0\n rpm_idle+0x578/0x770\n pm_runtime_work+0xee/0x120\n process_one_work+0xde3/0x1410\n worker_thread+0x5eb/0xfe0\n kthread+0x37b/0x480\n ret_from_fork+0x6cb/0x920\n ret_from_fork_asm+0x11/0x20\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_alloc_info+0x3d/0x50\n __kasan_kmalloc+0xa0/0xb0\n __kmalloc_noprof+0x311/0x990\n scsi_alloc_target+0x122/0xb60 [scsi_mod]\n __scsi_scan_target+0x101/0x460 [scsi_mod]\n scsi_scan_channel+0x179/0x1c0 [scsi_mod]\n scsi_scan_host_selected+0x259/0x2d0 [scsi_mod]\n store_scan+0x2d2/0x390 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810\n do_syscall_64+0xee/0xfc0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFreed by task 4314:\n kasan_save_stack+0x2a/0x50\n kasan_save_track+0x18/0x40\n kasan_save_free_info+0x3f/0x50\n __kasan_slab_free+0x67/0x80\n kfree+0x225/0x6c0\n scsi_target_dev_release+0x3d/0x60 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_dev_release+0xacf/0x12c0 [scsi_mod]\n device_release+0xa3/0x220\n kobject_cleanup+0x105/0x3a0\n kobject_put+0x72/0xd0\n put_device+0x17/0x20\n scsi_device_put+0x7f/0xc0 [scsi_mod]\n sdev_store_delete+0xa5/0x120 [scsi_mod]\n dev_attr_store+0x43/0x80\n sysfs_kf_write+0xde/0x140\n kernfs_fop_write_iter+0x3ef/0x670\n vfs_write+0x506/0x1470\n ksys_write+0xfd/0x230\n __x64_sys_write+0x76/0xc0\n x64_sys_call+0x213/0x1810(CVE-2026-23452)\n\nIn the Linux kernel, the Bluetooth SCO module\u0026apos;s sco_recv_frame() function contains a use-after-free vulnerability. The function reads conn-\u0026gt;sk under sco_conn_lock() but immediately releases the lock without holding a reference to the socket. A concurrent close() operation can free the socket between the lock release and the subsequent sk-\u0026gt;sk_state access, resulting in a use-after-free vulnerability. Other functions in the same file (sco_sock_timeout(), sco_conn_del()) correctly use sco_sock_hold() to safely hold references under the lock. The vulnerability is fixed by using sco_sock_hold() to acquire a reference before releasing the lock and adding sock_put() on all exit paths.(CVE-2026-31408)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxen/privcmd: restrict usage in unprivileged domU\n\nThe Xen privcmd driver allows to issue arbitrary hypercalls from\nuser space processes. This is normally no problem, as access is\nusually limited to root and the hypervisor will deny any hypercalls\naffecting other domains.\n\nIn case the guest is booted using secure boot, however, the privcmd\ndriver would be enabling a root user process to modify e.g. kernel\nmemory contents, thus breaking the secure boot feature.\n\nThe only known case where an unprivileged domU is really needing to\nuse the privcmd driver is the case when it is acting as the device\nmodel for another guest. In this case all hypercalls issued via the\nprivcmd driver will target that other guest.\n\nFortunately the privcmd driver can already be locked down to allow\nonly hypercalls targeting a specific domain, but this mode can be\nactivated from user land only today.\n\nThe target domain can be obtained from Xenstore, so when not running\nin dom0 restrict the privcmd driver to that target domain from the\nbeginning, resolving the potential problem of breaking secure boot.\n\nThis is XSA-482\n\n---\nV2:\n- defer reading from Xenstore if Xenstore isn\u0026apos;t ready yet (Jan Beulich)\n- wait in open() if target domain isn\u0026apos;t known yet\n- issue message in case no target domain found (Jan Beulich)(CVE-2026-31788)",
"id": "OESA-2026-1950",
"modified": "2026-08-06T11:10:57Z",
"published": "2026-04-17T11:10:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1950"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50300"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50518"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53194"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38476"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39794"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40205"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23253"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23269"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23389"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23404"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23405"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23406"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23407"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23408"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23410"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23411"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23452"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31408"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31788"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-50300",
"CVE-2022-50518",
"CVE-2023-53194",
"CVE-2025-38476",
"CVE-2025-39794",
"CVE-2025-40205",
"CVE-2026-23253",
"CVE-2026-23269",
"CVE-2026-23389",
"CVE-2026-23404",
"CVE-2026-23405",
"CVE-2026-23406",
"CVE-2026-23407",
"CVE-2026-23408",
"CVE-2026-23410",
"CVE-2026-23411",
"CVE-2026-23452",
"CVE-2026-31408",
"CVE-2026-31788"
]
}
SSA-032379
Vulnerability from csaf_siemens - Published: 2026-05-12 00:00 - Updated: 2026-05-12 00:00SUSE-SU-2025:21040-1
Vulnerability from csaf_suse - Published: 2025-11-13 15:32 - Updated: 2025-11-13 15:32SUSE-SU-2025:21052-1
Vulnerability from csaf_suse - Published: 2025-11-25 18:51 - Updated: 2025-11-25 18:51SUSE-SU-2025:21056-1
Vulnerability from csaf_suse - Published: 2025-11-13 14:22 - Updated: 2025-11-13 14:22SUSE-SU-2025:21064-1
Vulnerability from csaf_suse - Published: 2025-11-25 16:39 - Updated: 2025-11-25 16:39SUSE-SU-2025:4057-1
Vulnerability from csaf_suse - Published: 2025-11-11 18:36 - Updated: 2025-11-11 18:36Sightings
| 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.