Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-39853 (GCVE-0-2025-39853)
Vulnerability from cvelistv5 – Published: 2025-09-19 15:26 – Updated: 2026-05-12 12:07| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
e3219ce6a775468368fb270fae3eb82a6787b436 , < 971feafe157afac443027acdc235badc6838560b
(git)
Affected: e3219ce6a775468368fb270fae3eb82a6787b436 , < 3c6fb929afa313d9d11f780451d113f73922fe5d (git) Affected: e3219ce6a775468368fb270fae3eb82a6787b436 , < 1eadabcf5623f1237a539b16586b4ed8ac8dffcd (git) Affected: e3219ce6a775468368fb270fae3eb82a6787b436 , < e2a5e74879f9b494bbd66fa93f355feacde450c7 (git) Affected: e3219ce6a775468368fb270fae3eb82a6787b436 , < fb216d980fae6561c7c70af8ef826faf059c6515 (git) Affected: e3219ce6a775468368fb270fae3eb82a6787b436 , < 66e7cdbda74ee823ec2bf7b830ebd235c54f5ddf (git) Affected: e3219ce6a775468368fb270fae3eb82a6787b436 , < 9c21fc4cebd44dd21016c61261a683af390343f8 (git) Affected: e3219ce6a775468368fb270fae3eb82a6787b436 , < a556f06338e1d5a85af0e32ecb46e365547f92b9 (git) |
guessed | |
| Linux | Linux |
Affected:
4.6
Unaffected: 0 , < 4.6 (semver) Unaffected: 5.4.299 , ≤ 5.4.* (semver) Unaffected: 5.10.243 , ≤ 5.10.* (semver) Unaffected: 5.15.192 , ≤ 5.15.* (semver) Unaffected: 6.1.151 , ≤ 6.1.* (semver) Unaffected: 6.6.105 , ≤ 6.6.* (semver) Unaffected: 6.12.46 , ≤ 6.12.* (semver) Unaffected: 6.16.6 , ≤ 6.16.* (semver) Unaffected: 6.17 , ≤ * (original_commit_for_fix) |
guessed | |
| Siemens | RUGGEDCOM RST2428P |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 family |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XCH328 |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XCM324 |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XCM328 |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XCM332 |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRH334 (24 V DC, 8xFO, CC) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRM334 (230 V AC, 12xFO) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRM334 (230 V AC, 8xFO) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRM334 (230V AC, 2x10G, 24xSFP, 8xSFP+) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRM334 (24 V DC, 12xFO) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRM334 (24 V DC, 8xFO) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRM334 (24V DC, 2x10G, 24xSFP, 8xSFP+) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRM334 (2x230 V AC, 12xFO) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRM334 (2x230 V AC, 8xFO) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SCALANCE XRM334 (2x230V AC, 2x10G, 24xSFP, 8xSFP+) |
Affected:
0 , < V3.3
(custom)
|
guessed | |
| Siemens | SIMATIC CN 4100 |
Affected:
0 , < V5.0
(custom)
|
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T17:44:09.789Z",
"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": "RUGGEDCOM RST2428P",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 family",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XCH328",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XCM324",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XCM328",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XCM332",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRH334 (24 V DC, 8xFO, CC)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (230 V AC, 12xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (230 V AC, 8xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (230V AC, 2x10G, 24xSFP, 8xSFP+)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (24 V DC, 12xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (24 V DC, 8xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (24V DC, 2x10G, 24xSFP, 8xSFP+)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (2x230 V AC, 12xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (2x230 V AC, 8xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (2x230V AC, 2x10G, 24xSFP, 8xSFP+)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC CN 4100",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V5.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-12T12:07:39.499Z",
"orgId": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"shortName": "siemens-SADP"
},
"references": [
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-089022.html"
},
{
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
}
],
"x_adpType": "supplier"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_client.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "971feafe157afac443027acdc235badc6838560b",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "3c6fb929afa313d9d11f780451d113f73922fe5d",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "1eadabcf5623f1237a539b16586b4ed8ac8dffcd",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "e2a5e74879f9b494bbd66fa93f355feacde450c7",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "fb216d980fae6561c7c70af8ef826faf059c6515",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "66e7cdbda74ee823ec2bf7b830ebd235c54f5ddf",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "9c21fc4cebd44dd21016c61261a683af390343f8",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "a556f06338e1d5a85af0e32ecb46e365547f92b9",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_client.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.6"
},
{
"lessThan": "4.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.299",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.243",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.192",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.151",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.105",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.46",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.6",
"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.299",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.243",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.192",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.151",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.105",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.46",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.16.6",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.17",
"versionStartIncluding": "4.6",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:37:42.526Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/971feafe157afac443027acdc235badc6838560b"
},
{
"url": "https://git.kernel.org/stable/c/3c6fb929afa313d9d11f780451d113f73922fe5d"
},
{
"url": "https://git.kernel.org/stable/c/1eadabcf5623f1237a539b16586b4ed8ac8dffcd"
},
{
"url": "https://git.kernel.org/stable/c/e2a5e74879f9b494bbd66fa93f355feacde450c7"
},
{
"url": "https://git.kernel.org/stable/c/fb216d980fae6561c7c70af8ef826faf059c6515"
},
{
"url": "https://git.kernel.org/stable/c/66e7cdbda74ee823ec2bf7b830ebd235c54f5ddf"
},
{
"url": "https://git.kernel.org/stable/c/9c21fc4cebd44dd21016c61261a683af390343f8"
},
{
"url": "https://git.kernel.org/stable/c/a556f06338e1d5a85af0e32ecb46e365547f92b9"
}
],
"title": "i40e: Fix potential invalid access when MAC list is empty",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-39853",
"datePublished": "2025-09-19T15:26:25.101Z",
"dateReserved": "2025-04-16T07:20:57.142Z",
"dateUpdated": "2026-05-12T12:07:39.499Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-39853",
"date": "2026-10-01",
"epss": "0.00163",
"percentile": "0.0496"
},
"microsoft_vex": {
"current_release_date": "2026-02-24T14:42:30.000Z",
"cve": "CVE-2025-39853",
"id": "msrc_CVE-2025-39853",
"initial_release_date": "2025-09-02T00:00:00.000Z",
"product_status:fixed": "2",
"product_status:known_affected": "3",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "i40e: Fix potential invalid access when MAC list is empty",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-39853.json",
"version": "3"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_client.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "971feafe157afac443027acdc235badc6838560b",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "3c6fb929afa313d9d11f780451d113f73922fe5d",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "1eadabcf5623f1237a539b16586b4ed8ac8dffcd",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "e2a5e74879f9b494bbd66fa93f355feacde450c7",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "fb216d980fae6561c7c70af8ef826faf059c6515",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "66e7cdbda74ee823ec2bf7b830ebd235c54f5ddf",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "9c21fc4cebd44dd21016c61261a683af390343f8",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
},
{
"lessThan": "a556f06338e1d5a85af0e32ecb46e365547f92b9",
"status": "affected",
"version": "e3219ce6a775468368fb270fae3eb82a6787b436",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/ethernet/intel/i40e/i40e_client.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.6"
},
{
"lessThan": "4.6",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.299",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.243",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.192",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.151",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.105",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.46",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.16.*",
"status": "unaffected",
"version": "6.16.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.17",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"affectedData": [
{
"defaultStatus": "unknown",
"product": "RUGGEDCOM RST2428P",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XC-300/XR-300/XC-400/XR-500WG/XR-500 family",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XCH328",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XCM324",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XCM328",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XCM332",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRH334 (24 V DC, 8xFO, CC)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (230 V AC, 12xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (230 V AC, 8xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (230V AC, 2x10G, 24xSFP, 8xSFP+)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (24 V DC, 12xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (24 V DC, 8xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (24V DC, 2x10G, 24xSFP, 8xSFP+)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (2x230 V AC, 12xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (2x230 V AC, 8xFO)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SCALANCE XRM334 (2x230V AC, 2x10G, 24xSFP, 8xSFP+)",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V3.3",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
},
{
"defaultStatus": "unknown",
"product": "SIMATIC CN 4100",
"vendor": "Siemens",
"versions": [
{
"lessThan": "V5.0",
"status": "affected",
"version": "0",
"versionType": "custom"
}
]
}
],
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "786241CD-E02D-49BE-AC37-05BF5BCAAC1A",
"versionEndExcluding": "5.4.299",
"versionStartIncluding": "4.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6DE4B49A-F1A3-4F0C-96D3-68676CE6BB4C",
"versionEndExcluding": "5.10.243",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "8A911BD7-361F-45C0-A4A6-33FCBA0F6117",
"versionEndExcluding": "5.15.192",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BC2D0B88-F133-4143-B91D-0A439AA143C0",
"versionEndExcluding": "6.1.151",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B9364B0C-6B18-422E-8254-73EF0E856875",
"versionEndExcluding": "6.6.105",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "F7E2B332-E920-4CAC-B400-288602DB6F16",
"versionEndExcluding": "6.12.46",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "548F104C-0F08-438B-9C97-64C903F0C678",
"versionEndExcluding": "6.16.6",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc1:*:*:*:*:*:*",
"matchCriteriaId": "327D22EF-390B-454C-BD31-2ED23C998A1C",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc2:*:*:*:*:*:*",
"matchCriteriaId": "C730CD9A-D969-4A8E-9522-162AAF7C0EE9",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc3:*:*:*:*:*:*",
"matchCriteriaId": "39982C4B-716E-4B2F-8196-FA301F47807D",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.17:rc4:*:*:*:*:*:*",
"matchCriteriaId": "340BEEA9-D70D-4290-B502-FBB1032353B1",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*",
"matchCriteriaId": "FA6FEEC2-9F11-4643-8827-749718254FED",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry."
}
],
"id": "CVE-2025-39853",
"lastModified": "2026-06-17T09:18:37.847",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "NONE",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.2,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-09-19T16:15:44.213",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/1eadabcf5623f1237a539b16586b4ed8ac8dffcd"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3c6fb929afa313d9d11f780451d113f73922fe5d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/66e7cdbda74ee823ec2bf7b830ebd235c54f5ddf"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/971feafe157afac443027acdc235badc6838560b"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/9c21fc4cebd44dd21016c61261a683af390343f8"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/a556f06338e1d5a85af0e32ecb46e365547f92b9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e2a5e74879f9b494bbd66fa93f355feacde450c7"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/fb216d980fae6561c7c70af8ef826faf059c6515"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"source": "0b142b55-0307-4c5a-b3c9-f314f3fb7c5e",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-089022.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-30T01:23:39+00:00",
"cve": "CVE-2025-39853",
"id": "CVE-2025-39853",
"initial_release_date": "2025-09-19T00:00:00+00:00",
"product_status:known_affected": "260",
"product_status:known_not_affected": "14",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: i40e: Fix potential invalid access when MAC list is empty",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-39853.json",
"version": "3"
}
}
}
ICSA-26-134-10
Vulnerability from csaf_cisa - Published: 2026-05-12 00:00 - Updated: 2026-05-14 06:00MSRC_CVE-2025-39853
Vulnerability from csaf_microsoft - Published: 2025-09-02 00:00 - Updated: 2026-02-24 14:42NCSC-2026-0147
Vulnerability from csaf_ncscnl - Published: 2026-05-13 06:33 - Updated: 2026-05-13 06:33Multiple security vulnerabilities affecting the Linux kernel, including the i40e driver, AppArmor LSM, and AMD CPU microcode, were fixed across various SUSE Linux Enterprise and Micro kernel versions to address privilege escalation, denial of service, and information leaks.
OESA-2025-2465 (CVE-2024-56591)
Vulnerability from osv_openeuler – Published: 2025-10-17 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Use disable_delayed_work_sync
This makes use of disable_delayed_work_sync instead cancel_delayed_work_sync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.(CVE-2024-56591)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails.
Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.
Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path.
Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.(CVE-2025-22005)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a couple integer overflows on 32bit systems
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---(CVE-2025-37741)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.(CVE-2025-38319)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Limit access to parser->buffer when trace_get_user failed
When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:
BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165
CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0
The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise gateway LWS calls to probe user read access
We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER).
Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.(CVE-2025-39715)
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-qcom: Add SM6115 MDSS compatible
Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot:
arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed)
------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] ERROR could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the fields in the descriptor.(CVE-2025-39760)
In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in smb2_compound_op.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to cfile should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
cfile, except the patched one.
3. Existing callers would not handle refcount update of cfile if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of vars, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
is_replayable_error, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.(CVE-2025-39819)
A use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)
In the Linux kernel, the following vulnerability has been resolved:
mm: move page table sync declarations to linux/pgtable.h
During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:
BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK>
It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks.
And looking at __populate_section_memmap():
if (vmemmap_can_optimize(altmap, pgmap))
// does not sync top level page tables
r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
else
// sync top level page tables in x86
r = vmemmap_populate(start, end, nid, altmap);
In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.
However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.
We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.
It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.
The solution: Make page table sync more code robust and harder to miss
To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.
The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables.
pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t pgd, p4d_t p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); }
It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---(CVE-2025-39844)
In the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).
The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].
Fix by checking that the remote destination exists before dereferencing it.
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo
ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy
ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3
[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77
[4] #!/bin/bash
ip address add 2001:db8:1::1/128 dev lo
ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy
ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix potential invalid access when MAC list is empty
list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.
Fix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)
A NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)
A vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()
Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:
... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ...
The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.
We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.
As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.
Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/(CVE-2025-39886)
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix sched_numa_find_nth_cpu() if mask offline
sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.
The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):
[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[ 1.423635] Mem abort info:
[ 1.423889] ESR = 0x0000000096000006
[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.424715] SET = 0, FnV = 0
[ 1.424995] EA = 0, S1PTW = 0
[ 1.425279] FSC = 0x06: level 2 translation fault
[ 1.425735] Data abort info:
[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP
[ 1.429525] Modules linked in:
[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[ 1.432543] sp : ffffffc084e1b960
[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[ 1.439332] Call trace:
[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[ 1.440016] smp_call_function_any+0xc8/0xd0
[ 1.440416] armv8_pmu_init+0x58/0x27c
[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c
[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8
[ 1.441603] armv8_pmu_device_probe+0x1c/0x28
[ 1.442007] platform_probe+0x5c/0xac
[ 1.442347] really_probe+0xbc/0x298
[ 1.442683] __driver_probe_device+0x78/0x12c
[ 1.443087] driver_probe_device+0xdc/0x160
[ 1.443475] __driver_attach+0x94/0x19c
[ 1.443833] bus_for_each_dev+0x74/0xd4
[ 1.444190] driver_attach+0x24/0x30
[ 1.444525] bus_add_driver+0xe4/0x208
[ 1.444874] driver_register+0x60/0x128
[ 1.445233] __platform_driver_register+0x24/0x30
[ 1.445662] armv8_pmu_driver_init+0x28/0x4c
[ 1.446059] do_one_initcall+0x44/0x25c
[ 1.446416] kernel_init_freeable+0x1dc/0x3bc
[ 1.446820] kernel_init+0x20/0x1d8
[ 1.447151] ret_from_fork+0x10/0x20
[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[ 1.448040] ---[ end trace 0000000000000000 ]---
[ 1.448483] note: swapper/0[1] exited with preempt_count 1
[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.449741] SMP: stopping secondary CPUs
[ 1.450105] Kernel Offset: disabled
[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[
---truncated---(CVE-2025-39895)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Silence warning when chunk allocation fails in trace_pid_write
Syzkaller trigger a fault injection warning:
WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning.
The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.(CVE-2025-39914)
In the Linux kernel, the following vulnerability has been resolved:
cgroup: split cgroup_destroy_wq into 3 workqueues
A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.
Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20
Root Cause:
CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die
Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)
Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation
This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.
[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-source-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"perf-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"python3-perf-6.6.0-112.0.0.104.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.104.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-112.0.0.104.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-source-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"perf-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"python3-perf-6.6.0-112.0.0.104.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.104.oe2403.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-112.0.0.104.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_conn: Use disable_delayed_work_sync\n\nThis makes use of disable_delayed_work_sync instead\ncancel_delayed_work_sync as it not only cancel the ongoing work but also\ndisables new submit which is disarable since the object holding the work\nis about to be freed.(CVE-2024-56591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().\n\nfib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything\nwhen it fails.\n\nCommit 7dd73168e273 (\u0026quot;ipv6: Always allocate pcpu memory in a fib6_nh\u0026quot;)\nmoved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()\nbut forgot to add cleanup for fib6_nh-\u0026gt;nh_common.nhc_pcpu_rth_output in\ncase it fails to allocate fib6_nh-\u0026gt;rt6i_pcpu, resulting in memleak.\n\nLet\u0026apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the\nerror path.\n\nNote that we can remove the fib6_nh_release() call in nh_create_ipv6()\nlater in net-next.git.(CVE-2025-22005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix a couple integer overflows on 32bit systems\n\nOn 32bit systems the \u0026quot;off + sizeof(struct NTFS_DE)\u0026quot; addition can\nhave an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling \u0026quot;ioctl$LOOP_SET_STATUS64\u0026quot;, the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---(CVE-2025-37741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table\n\nThe function atomctrl_initialize_mc_reg_table() and\natomctrl_initialize_mc_reg_table_v2_2() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()\nfails to retrieve vram_info, it returns NULL which is later\ndereferenced.(CVE-2025-38319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser-\u0026gt;buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser-\u0026gt;buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release-\u0026gt;\nftrace_process_regex-\u0026gt;strsep-\u0026gt;strpbrk. We can solve this problem by\nlimiting access to parser-\u0026gt;buffer when trace_get_user failed.(CVE-2025-39683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise gateway LWS calls to probe user read access\n\nWe use load and stbys,e instructions to trigger memory reference\ninterruptions without writing to memory. Because of the way read\naccess support is implemented, read access interruptions are only\ntriggered at privilege levels 2 and 3. The kernel and gateway\npage execute at privilege level 0, so this code never triggers\na read access interruption. Thus, it is currently possible for\nuser code to execute a LWS compare and swap operation at an\naddress that is read protected at privilege level 3 (PRIV_USER).\n\nFix this by probing read access rights at privilege level 3 and\nbranching to lws_fault if access isn\u0026apos;t allowed.(CVE-2025-39715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-qcom: Add SM6115 MDSS compatible\n\nAdd the SM6115 MDSS compatible to clients compatible list, as it also\nneeds that workaround.\nWithout this workaround, for example, QRB4210 RB2 which is based on\nSM4250/SM6115 generates a lot of smmu unhandled context faults during\nboot:\n\narm_smmu_context_fault: 116854 callbacks suppressed\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\narm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\n\nand also failed initialisation of lontium lt9611uxc, gpu and dpu is\nobserved:\n(binding MDSS components triggered by lt9611uxc have failed)\n\n ------------[ cut here ]------------\n !aspace\n WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]\n Modules linked in: ... (long list of modules)\n CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT\n Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : msm_gem_vma_init+0x150/0x18c [msm]\n lr : msm_gem_vma_init+0x150/0x18c [msm]\n sp : ffff80008144b280\n \t\t...\n Call trace:\n msm_gem_vma_init+0x150/0x18c [msm] (P)\n get_vma_locked+0xc0/0x194 [msm]\n msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]\n msm_gem_kernel_new+0x48/0x160 [msm]\n msm_gpu_init+0x34c/0x53c [msm]\n adreno_gpu_init+0x1b0/0x2d8 [msm]\n a6xx_gpu_init+0x1e8/0x9e0 [msm]\n adreno_bind+0x2b8/0x348 [msm]\n component_bind_all+0x100/0x230\n msm_drm_bind+0x13c/0x3d0 [msm]\n try_to_bring_up_aggregate_device+0x164/0x1d0\n __component_add+0xa4/0x174\n component_add+0x14/0x20\n dsi_dev_attach+0x20/0x34 [msm]\n dsi_host_attach+0x58/0x98 [msm]\n devm_mipi_dsi_attach+0x34/0x90\n lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]\n lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]\n i2c_device_probe+0x148/0x2a8\n really_probe+0xbc/0x2c0\n __driver_probe_device+0x78/0x120\n driver_probe_device+0x3c/0x154\n __driver_attach+0x90/0x1a0\n bus_for_each_dev+0x68/0xb8\n driver_attach+0x24/0x30\n bus_add_driver+0xe4/0x208\n driver_register+0x68/0x124\n i2c_register_driver+0x48/0xcc\n lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]\n do_one_initcall+0x60/0x1d4\n do_init_module+0x54/0x1fc\n load_module+0x1748/0x1c8c\n init_module_from_file+0x74/0xa0\n __arm64_sys_finit_module+0x130/0x2f8\n invoke_syscall+0x48/0x104\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x2c/0x80\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n ---[ end trace 0000000000000000 ]---\n msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22\n msm_dpu 5e01000.display-controller: failed to load adreno gpu\n platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19\n msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22\n msm_dpu 5e01000.display-controller: adev bind failed: -22\n lt9611uxc 0-002b: failed to attach dsi to host\n lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: config: Prevent OOB read in SS endpoint companion parsing\n\nusb_parse_ss_endpoint_companion() checks descriptor type before length,\nenabling a potentially odd read outside of the buffer size.\n\nFix this up by checking the size first before looking at any of the\nfields in the descriptor.(CVE-2025-39760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb: Fix inconsistent refcnt update\n\nA possible inconsistent update of refcount was identified in `smb2_compound_op`.\nSuch inconsistent update could lead to possible resource leaks.\n\nWhy it is a possible bug:\n1. In the comment section of the function, it clearly states that the\nreference to `cfile` should be dropped after calling this function.\n2. Every control flow path would check and drop the reference to\n`cfile`, except the patched one.\n3. Existing callers would not handle refcount update of `cfile` if\n-ENOMEM is returned.\n\nTo fix the bug, an extra goto label \u0026quot;out\u0026quot; is added, to make sure that the\ncleanup logic would always be respected. As the problem is caused by the\nallocation failure of `vars`, the cleanup logic between label \u0026quot;finished\u0026quot;\nand \u0026quot;out\u0026quot; can be safely ignored. According to the definition of function\n`is_replayable_error`, the error code of \u0026quot;-ENOMEM\u0026quot; is not recoverable.\nTherefore, the replay logic also gets ignored.(CVE-2025-39819)\n\nA use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: move page table sync declarations to linux/pgtable.h\n\nDuring our internal testing, we started observing intermittent boot\nfailures when the machine uses 4-level paging and has a large amount of\npersistent memory:\n\n BUG: unable to handle page fault for address: ffffe70000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0 \n Oops: 0002 [#1] SMP NOPTI\n RIP: 0010:__init_single_page+0x9/0x6d\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __init_zone_device_page+0x17/0x5d\n memmap_init_zone_device+0x154/0x1bb\n pagemap_range+0x2e0/0x40f\n memremap_pages+0x10b/0x2f0\n devm_memremap_pages+0x1e/0x60\n dev_dax_probe+0xce/0x2ec [device_dax]\n dax_bus_probe+0x6d/0xc9\n [... snip ...]\n \u0026lt;/TASK\u0026gt;\n\nIt turns out that the kernel panics while initializing vmemmap (struct\npage array) when the vmemmap region spans two PGD entries, because the new\nPGD entry is only installed in init_mm.pgd, but not in the page tables of\nother tasks.\n\nAnd looking at __populate_section_memmap():\n if (vmemmap_can_optimize(altmap, pgmap)) \n // does not sync top level page tables\n r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);\n else \n // sync top level page tables in x86\n r = vmemmap_populate(start, end, nid, altmap);\n\nIn the normal path, vmemmap_populate() in arch/x86/mm/init_64.c\nsynchronizes the top level page table (See commit 9b861528a801 (\u0026quot;x86-64,\nmem: Update all PGDs for direct mapping and vmemmap mapping changes\u0026quot;)) so\nthat all tasks in the system can see the new vmemmap area.\n\nHowever, when vmemmap_can_optimize() returns true, the optimized path\nskips synchronization of top-level page tables. This is because\nvmemmap_populate_compound_pages() is implemented in core MM code, which\ndoes not handle synchronization of the top-level page tables. Instead,\nthe core MM has historically relied on each architecture to perform this\nsynchronization manually.\n\nWe\u0026apos;re not the first party to encounter a crash caused by not-sync\u0026apos;d top\nlevel page tables: earlier this year, Gwan-gyeong Mun attempted to address\nthe issue [1] [2] after hitting a kernel panic when x86 code accessed the\nvmemmap area before the corresponding top-level entries were synced. At\nthat time, the issue was believed to be triggered only when struct page\nwas enlarged for debugging purposes, and the patch did not get further\nupdates.\n\nIt turns out that current approach of relying on each arch to handle the\npage table sync manually is fragile because 1) it\u0026apos;s easy to forget to sync\nthe top level page table, and 2) it\u0026apos;s also easy to overlook that the\nkernel should not access the vmemmap and direct mapping areas before the\nsync.\n\n# The solution: Make page table sync more code robust and harder to miss\n\nTo address this, Dave Hansen suggested [3] [4] introducing\n{pgd,p4d}_populate_kernel() for updating kernel portion of the page tables\nand allow each architecture to explicitly perform synchronization when\ninstalling top-level entries. With this approach, we no longer need to\nworry about missing the sync step, reducing the risk of future\nregressions.\n\nThe new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,\nPGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by\nvmalloc and ioremap to synchronize page tables.\n\npgd_populate_kernel() looks like this:\nstatic inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,\n p4d_t *p4d)\n{\n pgd_populate(\u0026amp;init_mm, pgd, p4d);\n if (ARCH_PAGE_TABLE_SYNC_MASK \u0026amp; PGTBL_PGD_MODIFIED)\n arch_sync_kernel_mappings(addr, addr);\n}\n\nIt is worth noting that vmalloc() and apply_to_range() carefully\nsynchronizes page tables by calling p*d_alloc_track() and\narch_sync_kernel_mappings(), and thus they are not affected by\n---truncated---(CVE-2025-39844)\n\nIn the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the \u0026quot;proxy\u0026quot; option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the \u0026quot;any\u0026quot; remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor\u0026apos;s MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)\n\nA NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)\n\nA vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()\n\nCurrently, calling bpf_map_kmalloc_node() from __bpf_async_init() can\ncause various locking issues; see the following stack trace (edited for\nstyle) as one example:\n\n...\n [10.011566] do_raw_spin_lock.cold\n [10.011570] try_to_wake_up (5) double-acquiring the same\n [10.011575] kick_pool rq_lock, causing a hardlockup\n [10.011579] __queue_work\n [10.011582] queue_work_on\n [10.011585] kernfs_notify\n [10.011589] cgroup_file_notify\n [10.011593] try_charge_memcg (4) memcg accounting raises an\n [10.011597] obj_cgroup_charge_pages MEMCG_MAX event\n [10.011599] obj_cgroup_charge_account\n [10.011600] __memcg_slab_post_alloc_hook\n [10.011603] __kmalloc_node_noprof\n...\n [10.011611] bpf_map_kmalloc_node\n [10.011612] __bpf_async_init\n [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()\n [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable\n [10.011619] bpf__sched_ext_ops_runnable\n [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held\n [10.011622] enqueue_task\n [10.011626] ttwu_do_activate\n [10.011629] sched_ttwu_pending (1) grabs rq_lock\n...\n\nThe above was reproduced on bpf-next (b338cf849ec8) by modifying\n./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during\nops.runnable(), and hacking the memcg accounting code a bit to make\na bpf_timer_init() call more likely to raise an MEMCG_MAX event.\n\nWe have also run into other similar variants (both internally and on\nbpf-next), including double-acquiring cgroup_file_kn_lock, the same\nworker_pool::lock, etc.\n\nAs suggested by Shakeel, fix this by using __GFP_HIGH instead of\nGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()\nraises an MEMCG_MAX event, we call __memcg_memory_event() with\n@allow_spinning=false and avoid calling cgroup_file_notify() there.\n\nDepends on mm patch\n\u0026quot;memcg: skip cgroup_file_notify if spinning is not allowed\u0026quot;:\nhttps://lore.kernel.org/bpf/(CVE-2025-39886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix sched_numa_find_nth_cpu() if mask offline\n\nsched_numa_find_nth_cpu() uses a bsearch to look for the \u0026apos;closest\u0026apos;\nCPU in sched_domains_numa_masks and given cpus mask. However they\nmight not intersect if all CPUs in the cpus mask are offline. bsearch\nwill return NULL in that case, bail out instead of dereferencing a\nbogus pointer.\n\nThe previous behaviour lead to this bug when using maxcpus=4 on an\nrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):\n\n[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000\n[ 1.423635] Mem abort info:\n[ 1.423889] ESR = 0x0000000096000006\n[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 1.424715] SET = 0, FnV = 0\n[ 1.424995] EA = 0, S1PTW = 0\n[ 1.425279] FSC = 0x06: level 2 translation fault\n[ 1.425735] Data abort info:\n[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000\n[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000\n[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP\n[ 1.429525] Modules linked in:\n[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT\n[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)\n[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488\n[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488\n[ 1.432543] sp : ffffffc084e1b960\n[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0\n[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378\n[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff\n[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7\n[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372\n[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860\n[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000\n[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000\n[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68\n[ 1.439332] Call trace:\n[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)\n[ 1.440016] smp_call_function_any+0xc8/0xd0\n[ 1.440416] armv8_pmu_init+0x58/0x27c\n[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c\n[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8\n[ 1.441603] armv8_pmu_device_probe+0x1c/0x28\n[ 1.442007] platform_probe+0x5c/0xac\n[ 1.442347] really_probe+0xbc/0x298\n[ 1.442683] __driver_probe_device+0x78/0x12c\n[ 1.443087] driver_probe_device+0xdc/0x160\n[ 1.443475] __driver_attach+0x94/0x19c\n[ 1.443833] bus_for_each_dev+0x74/0xd4\n[ 1.444190] driver_attach+0x24/0x30\n[ 1.444525] bus_add_driver+0xe4/0x208\n[ 1.444874] driver_register+0x60/0x128\n[ 1.445233] __platform_driver_register+0x24/0x30\n[ 1.445662] armv8_pmu_driver_init+0x28/0x4c\n[ 1.446059] do_one_initcall+0x44/0x25c\n[ 1.446416] kernel_init_freeable+0x1dc/0x3bc\n[ 1.446820] kernel_init+0x20/0x1d8\n[ 1.447151] ret_from_fork+0x10/0x20\n[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)\n[ 1.448040] ---[ end trace 0000000000000000 ]---\n[ 1.448483] note: swapper/0[1] exited with preempt_count 1\n[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n[ 1.449741] SMP: stopping secondary CPUs\n[ 1.450105] Kernel Offset: disabled\n[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b\n[ \n---truncated---(CVE-2025-39895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Silence warning when chunk allocation fails in trace_pid_write\n\nSyzkaller trigger a fault injection warning:\n\nWARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0\nModules linked in:\nCPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0\nTainted: [U]=USER\nHardware name: Google Compute Engine/Google Compute Engine\nRIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294\nCode: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff\nRSP: 0018:ffffc9000414fb48 EFLAGS: 00010283\nRAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000\nRDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0\nFS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464\n register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]\n register_pid_events kernel/trace/trace_events.c:2354 [inline]\n event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425\n vfs_write+0x24c/0x1150 fs/read_write.c:677\n ksys_write+0x12b/0x250 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe can reproduce the warning by following the steps below:\n1. echo 8 \u0026gt;\u0026gt; set_event_notrace_pid. Let tr-\u0026gt;filtered_pids owns one pid\n and register sched_switch tracepoint.\n2. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid, and perform fault injection during chunk\n allocation of trace_pid_list_alloc. Let pid_list with no pid and\nassign to tr-\u0026gt;filtered_pids.\n3. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid. Let pid_list is NULL and assign to\n tr-\u0026gt;filtered_pids.\n4. echo 9 \u0026gt;\u0026gt; set_event_pid, will trigger the double register\n sched_switch tracepoint warning.\n\nThe reason is that syzkaller injects a fault into the chunk allocation\nin trace_pid_list_alloc, causing a failure in trace_pid_list_set, which\nmay trigger double register of the same tracepoint. This only occurs\nwhen the system is about to crash, but to suppress this warning, let\u0026apos;s\nadd failure handling logic to trace_pid_list_set.(CVE-2025-39914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0 CPU1\nmount perf_event umount net_prio\ncgroup1_get_tree cgroup_kill_sb\nrebind_subsystems // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n // one perf_event css A is dying\n // css A offline enqueues cgroup_destroy_wq\n // root destruction will be executed first\n css_free_rwork_fn\n cgroup_destroy_root\n cgroup_lock_and_drain_offline\n // some perf descendants are dying\n // cgroup_destroy_wq max_active = 1\n // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq \u2013 Handles CSS offline operations\ncgroup_release_wq \u2013 Manages resource release\ncgroup_free_wq \u2013 Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)",
"id": "OESA-2025-2465",
"modified": "2026-08-06T11:09:33Z",
"published": "2025-10-17T11:09:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2465"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39953"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56591",
"CVE-2025-22005",
"CVE-2025-22081",
"CVE-2025-37741",
"CVE-2025-38086",
"CVE-2025-38319",
"CVE-2025-39683",
"CVE-2025-39715",
"CVE-2025-39739",
"CVE-2025-39752",
"CVE-2025-39760",
"CVE-2025-39819",
"CVE-2025-39824",
"CVE-2025-39844",
"CVE-2025-39845",
"CVE-2025-39850",
"CVE-2025-39851",
"CVE-2025-39853",
"CVE-2025-39865",
"CVE-2025-39883",
"CVE-2025-39886",
"CVE-2025-39895",
"CVE-2025-39914",
"CVE-2025-39953"
]
}
OESA-2025-2466 (CVE-2024-56591)
Vulnerability from osv_openeuler – Published: 2025-10-17 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Use disable_delayed_work_sync
This makes use of disable_delayed_work_sync instead cancel_delayed_work_sync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.(CVE-2024-56591)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails.
Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.
Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path.
Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.(CVE-2025-22005)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a couple integer overflows on 32bit systems
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---(CVE-2025-37741)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.(CVE-2025-38319)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Limit access to parser->buffer when trace_get_user failed
When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:
BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165
CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0
The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise gateway LWS calls to probe user read access
We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER).
Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.(CVE-2025-39715)
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-qcom: Add SM6115 MDSS compatible
Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot:
arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed)
------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] ERROR could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the fields in the descriptor.(CVE-2025-39760)
In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in smb2_compound_op.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to cfile should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
cfile, except the patched one.
3. Existing callers would not handle refcount update of cfile if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of vars, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
is_replayable_error, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.(CVE-2025-39819)
A use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)
In the Linux kernel, the following vulnerability has been resolved:
mm: move page table sync declarations to linux/pgtable.h
During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:
BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK>
It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks.
And looking at __populate_section_memmap():
if (vmemmap_can_optimize(altmap, pgmap))
// does not sync top level page tables
r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
else
// sync top level page tables in x86
r = vmemmap_populate(start, end, nid, altmap);
In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.
However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.
We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.
It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.
The solution: Make page table sync more code robust and harder to miss
To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.
The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables.
pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t pgd, p4d_t p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); }
It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---(CVE-2025-39844)
In the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).
The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].
Fix by checking that the remote destination exists before dereferencing it.
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo
ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy
ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3
[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77
[4] #!/bin/bash
ip address add 2001:db8:1::1/128 dev lo
ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy
ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix potential invalid access when MAC list is empty
list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.
Fix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)
A NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)
A vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()
Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:
... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ...
The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.
We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.
As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.
Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/(CVE-2025-39886)
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix sched_numa_find_nth_cpu() if mask offline
sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.
The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):
[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[ 1.423635] Mem abort info:
[ 1.423889] ESR = 0x0000000096000006
[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.424715] SET = 0, FnV = 0
[ 1.424995] EA = 0, S1PTW = 0
[ 1.425279] FSC = 0x06: level 2 translation fault
[ 1.425735] Data abort info:
[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP
[ 1.429525] Modules linked in:
[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[ 1.432543] sp : ffffffc084e1b960
[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[ 1.439332] Call trace:
[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[ 1.440016] smp_call_function_any+0xc8/0xd0
[ 1.440416] armv8_pmu_init+0x58/0x27c
[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c
[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8
[ 1.441603] armv8_pmu_device_probe+0x1c/0x28
[ 1.442007] platform_probe+0x5c/0xac
[ 1.442347] really_probe+0xbc/0x298
[ 1.442683] __driver_probe_device+0x78/0x12c
[ 1.443087] driver_probe_device+0xdc/0x160
[ 1.443475] __driver_attach+0x94/0x19c
[ 1.443833] bus_for_each_dev+0x74/0xd4
[ 1.444190] driver_attach+0x24/0x30
[ 1.444525] bus_add_driver+0xe4/0x208
[ 1.444874] driver_register+0x60/0x128
[ 1.445233] __platform_driver_register+0x24/0x30
[ 1.445662] armv8_pmu_driver_init+0x28/0x4c
[ 1.446059] do_one_initcall+0x44/0x25c
[ 1.446416] kernel_init_freeable+0x1dc/0x3bc
[ 1.446820] kernel_init+0x20/0x1d8
[ 1.447151] ret_from_fork+0x10/0x20
[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[ 1.448040] ---[ end trace 0000000000000000 ]---
[ 1.448483] note: swapper/0[1] exited with preempt_count 1
[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.449741] SMP: stopping secondary CPUs
[ 1.450105] Kernel Offset: disabled
[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[
---truncated---(CVE-2025-39895)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Silence warning when chunk allocation fails in trace_pid_write
Syzkaller trigger a fault injection warning:
WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning.
The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.(CVE-2025-39914)
In the Linux kernel, the following vulnerability has been resolved:
cgroup: split cgroup_destroy_wq into 3 workqueues
A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.
Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20
Root Cause:
CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die
Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)
Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation
This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.
[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"perf-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-112.0.0.115.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"perf-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.115.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-112.0.0.115.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_conn: Use disable_delayed_work_sync\n\nThis makes use of disable_delayed_work_sync instead\ncancel_delayed_work_sync as it not only cancel the ongoing work but also\ndisables new submit which is disarable since the object holding the work\nis about to be freed.(CVE-2024-56591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().\n\nfib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything\nwhen it fails.\n\nCommit 7dd73168e273 (\u0026quot;ipv6: Always allocate pcpu memory in a fib6_nh\u0026quot;)\nmoved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()\nbut forgot to add cleanup for fib6_nh-\u0026gt;nh_common.nhc_pcpu_rth_output in\ncase it fails to allocate fib6_nh-\u0026gt;rt6i_pcpu, resulting in memleak.\n\nLet\u0026apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the\nerror path.\n\nNote that we can remove the fib6_nh_release() call in nh_create_ipv6()\nlater in net-next.git.(CVE-2025-22005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix a couple integer overflows on 32bit systems\n\nOn 32bit systems the \u0026quot;off + sizeof(struct NTFS_DE)\u0026quot; addition can\nhave an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling \u0026quot;ioctl$LOOP_SET_STATUS64\u0026quot;, the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---(CVE-2025-37741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table\n\nThe function atomctrl_initialize_mc_reg_table() and\natomctrl_initialize_mc_reg_table_v2_2() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()\nfails to retrieve vram_info, it returns NULL which is later\ndereferenced.(CVE-2025-38319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser-\u0026gt;buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser-\u0026gt;buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release-\u0026gt;\nftrace_process_regex-\u0026gt;strsep-\u0026gt;strpbrk. We can solve this problem by\nlimiting access to parser-\u0026gt;buffer when trace_get_user failed.(CVE-2025-39683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise gateway LWS calls to probe user read access\n\nWe use load and stbys,e instructions to trigger memory reference\ninterruptions without writing to memory. Because of the way read\naccess support is implemented, read access interruptions are only\ntriggered at privilege levels 2 and 3. The kernel and gateway\npage execute at privilege level 0, so this code never triggers\na read access interruption. Thus, it is currently possible for\nuser code to execute a LWS compare and swap operation at an\naddress that is read protected at privilege level 3 (PRIV_USER).\n\nFix this by probing read access rights at privilege level 3 and\nbranching to lws_fault if access isn\u0026apos;t allowed.(CVE-2025-39715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-qcom: Add SM6115 MDSS compatible\n\nAdd the SM6115 MDSS compatible to clients compatible list, as it also\nneeds that workaround.\nWithout this workaround, for example, QRB4210 RB2 which is based on\nSM4250/SM6115 generates a lot of smmu unhandled context faults during\nboot:\n\narm_smmu_context_fault: 116854 callbacks suppressed\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\narm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\n\nand also failed initialisation of lontium lt9611uxc, gpu and dpu is\nobserved:\n(binding MDSS components triggered by lt9611uxc have failed)\n\n ------------[ cut here ]------------\n !aspace\n WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]\n Modules linked in: ... (long list of modules)\n CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT\n Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : msm_gem_vma_init+0x150/0x18c [msm]\n lr : msm_gem_vma_init+0x150/0x18c [msm]\n sp : ffff80008144b280\n \t\t...\n Call trace:\n msm_gem_vma_init+0x150/0x18c [msm] (P)\n get_vma_locked+0xc0/0x194 [msm]\n msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]\n msm_gem_kernel_new+0x48/0x160 [msm]\n msm_gpu_init+0x34c/0x53c [msm]\n adreno_gpu_init+0x1b0/0x2d8 [msm]\n a6xx_gpu_init+0x1e8/0x9e0 [msm]\n adreno_bind+0x2b8/0x348 [msm]\n component_bind_all+0x100/0x230\n msm_drm_bind+0x13c/0x3d0 [msm]\n try_to_bring_up_aggregate_device+0x164/0x1d0\n __component_add+0xa4/0x174\n component_add+0x14/0x20\n dsi_dev_attach+0x20/0x34 [msm]\n dsi_host_attach+0x58/0x98 [msm]\n devm_mipi_dsi_attach+0x34/0x90\n lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]\n lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]\n i2c_device_probe+0x148/0x2a8\n really_probe+0xbc/0x2c0\n __driver_probe_device+0x78/0x120\n driver_probe_device+0x3c/0x154\n __driver_attach+0x90/0x1a0\n bus_for_each_dev+0x68/0xb8\n driver_attach+0x24/0x30\n bus_add_driver+0xe4/0x208\n driver_register+0x68/0x124\n i2c_register_driver+0x48/0xcc\n lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]\n do_one_initcall+0x60/0x1d4\n do_init_module+0x54/0x1fc\n load_module+0x1748/0x1c8c\n init_module_from_file+0x74/0xa0\n __arm64_sys_finit_module+0x130/0x2f8\n invoke_syscall+0x48/0x104\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x2c/0x80\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n ---[ end trace 0000000000000000 ]---\n msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22\n msm_dpu 5e01000.display-controller: failed to load adreno gpu\n platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19\n msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22\n msm_dpu 5e01000.display-controller: adev bind failed: -22\n lt9611uxc 0-002b: failed to attach dsi to host\n lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: config: Prevent OOB read in SS endpoint companion parsing\n\nusb_parse_ss_endpoint_companion() checks descriptor type before length,\nenabling a potentially odd read outside of the buffer size.\n\nFix this up by checking the size first before looking at any of the\nfields in the descriptor.(CVE-2025-39760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb: Fix inconsistent refcnt update\n\nA possible inconsistent update of refcount was identified in `smb2_compound_op`.\nSuch inconsistent update could lead to possible resource leaks.\n\nWhy it is a possible bug:\n1. In the comment section of the function, it clearly states that the\nreference to `cfile` should be dropped after calling this function.\n2. Every control flow path would check and drop the reference to\n`cfile`, except the patched one.\n3. Existing callers would not handle refcount update of `cfile` if\n-ENOMEM is returned.\n\nTo fix the bug, an extra goto label \u0026quot;out\u0026quot; is added, to make sure that the\ncleanup logic would always be respected. As the problem is caused by the\nallocation failure of `vars`, the cleanup logic between label \u0026quot;finished\u0026quot;\nand \u0026quot;out\u0026quot; can be safely ignored. According to the definition of function\n`is_replayable_error`, the error code of \u0026quot;-ENOMEM\u0026quot; is not recoverable.\nTherefore, the replay logic also gets ignored.(CVE-2025-39819)\n\nA use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: move page table sync declarations to linux/pgtable.h\n\nDuring our internal testing, we started observing intermittent boot\nfailures when the machine uses 4-level paging and has a large amount of\npersistent memory:\n\n BUG: unable to handle page fault for address: ffffe70000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0 \n Oops: 0002 [#1] SMP NOPTI\n RIP: 0010:__init_single_page+0x9/0x6d\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __init_zone_device_page+0x17/0x5d\n memmap_init_zone_device+0x154/0x1bb\n pagemap_range+0x2e0/0x40f\n memremap_pages+0x10b/0x2f0\n devm_memremap_pages+0x1e/0x60\n dev_dax_probe+0xce/0x2ec [device_dax]\n dax_bus_probe+0x6d/0xc9\n [... snip ...]\n \u0026lt;/TASK\u0026gt;\n\nIt turns out that the kernel panics while initializing vmemmap (struct\npage array) when the vmemmap region spans two PGD entries, because the new\nPGD entry is only installed in init_mm.pgd, but not in the page tables of\nother tasks.\n\nAnd looking at __populate_section_memmap():\n if (vmemmap_can_optimize(altmap, pgmap)) \n // does not sync top level page tables\n r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);\n else \n // sync top level page tables in x86\n r = vmemmap_populate(start, end, nid, altmap);\n\nIn the normal path, vmemmap_populate() in arch/x86/mm/init_64.c\nsynchronizes the top level page table (See commit 9b861528a801 (\u0026quot;x86-64,\nmem: Update all PGDs for direct mapping and vmemmap mapping changes\u0026quot;)) so\nthat all tasks in the system can see the new vmemmap area.\n\nHowever, when vmemmap_can_optimize() returns true, the optimized path\nskips synchronization of top-level page tables. This is because\nvmemmap_populate_compound_pages() is implemented in core MM code, which\ndoes not handle synchronization of the top-level page tables. Instead,\nthe core MM has historically relied on each architecture to perform this\nsynchronization manually.\n\nWe\u0026apos;re not the first party to encounter a crash caused by not-sync\u0026apos;d top\nlevel page tables: earlier this year, Gwan-gyeong Mun attempted to address\nthe issue [1] [2] after hitting a kernel panic when x86 code accessed the\nvmemmap area before the corresponding top-level entries were synced. At\nthat time, the issue was believed to be triggered only when struct page\nwas enlarged for debugging purposes, and the patch did not get further\nupdates.\n\nIt turns out that current approach of relying on each arch to handle the\npage table sync manually is fragile because 1) it\u0026apos;s easy to forget to sync\nthe top level page table, and 2) it\u0026apos;s also easy to overlook that the\nkernel should not access the vmemmap and direct mapping areas before the\nsync.\n\n# The solution: Make page table sync more code robust and harder to miss\n\nTo address this, Dave Hansen suggested [3] [4] introducing\n{pgd,p4d}_populate_kernel() for updating kernel portion of the page tables\nand allow each architecture to explicitly perform synchronization when\ninstalling top-level entries. With this approach, we no longer need to\nworry about missing the sync step, reducing the risk of future\nregressions.\n\nThe new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,\nPGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by\nvmalloc and ioremap to synchronize page tables.\n\npgd_populate_kernel() looks like this:\nstatic inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,\n p4d_t *p4d)\n{\n pgd_populate(\u0026amp;init_mm, pgd, p4d);\n if (ARCH_PAGE_TABLE_SYNC_MASK \u0026amp; PGTBL_PGD_MODIFIED)\n arch_sync_kernel_mappings(addr, addr);\n}\n\nIt is worth noting that vmalloc() and apply_to_range() carefully\nsynchronizes page tables by calling p*d_alloc_track() and\narch_sync_kernel_mappings(), and thus they are not affected by\n---truncated---(CVE-2025-39844)\n\nIn the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the \u0026quot;proxy\u0026quot; option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the \u0026quot;any\u0026quot; remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor\u0026apos;s MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)\n\nA NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)\n\nA vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()\n\nCurrently, calling bpf_map_kmalloc_node() from __bpf_async_init() can\ncause various locking issues; see the following stack trace (edited for\nstyle) as one example:\n\n...\n [10.011566] do_raw_spin_lock.cold\n [10.011570] try_to_wake_up (5) double-acquiring the same\n [10.011575] kick_pool rq_lock, causing a hardlockup\n [10.011579] __queue_work\n [10.011582] queue_work_on\n [10.011585] kernfs_notify\n [10.011589] cgroup_file_notify\n [10.011593] try_charge_memcg (4) memcg accounting raises an\n [10.011597] obj_cgroup_charge_pages MEMCG_MAX event\n [10.011599] obj_cgroup_charge_account\n [10.011600] __memcg_slab_post_alloc_hook\n [10.011603] __kmalloc_node_noprof\n...\n [10.011611] bpf_map_kmalloc_node\n [10.011612] __bpf_async_init\n [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()\n [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable\n [10.011619] bpf__sched_ext_ops_runnable\n [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held\n [10.011622] enqueue_task\n [10.011626] ttwu_do_activate\n [10.011629] sched_ttwu_pending (1) grabs rq_lock\n...\n\nThe above was reproduced on bpf-next (b338cf849ec8) by modifying\n./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during\nops.runnable(), and hacking the memcg accounting code a bit to make\na bpf_timer_init() call more likely to raise an MEMCG_MAX event.\n\nWe have also run into other similar variants (both internally and on\nbpf-next), including double-acquiring cgroup_file_kn_lock, the same\nworker_pool::lock, etc.\n\nAs suggested by Shakeel, fix this by using __GFP_HIGH instead of\nGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()\nraises an MEMCG_MAX event, we call __memcg_memory_event() with\n@allow_spinning=false and avoid calling cgroup_file_notify() there.\n\nDepends on mm patch\n\u0026quot;memcg: skip cgroup_file_notify if spinning is not allowed\u0026quot;:\nhttps://lore.kernel.org/bpf/(CVE-2025-39886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix sched_numa_find_nth_cpu() if mask offline\n\nsched_numa_find_nth_cpu() uses a bsearch to look for the \u0026apos;closest\u0026apos;\nCPU in sched_domains_numa_masks and given cpus mask. However they\nmight not intersect if all CPUs in the cpus mask are offline. bsearch\nwill return NULL in that case, bail out instead of dereferencing a\nbogus pointer.\n\nThe previous behaviour lead to this bug when using maxcpus=4 on an\nrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):\n\n[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000\n[ 1.423635] Mem abort info:\n[ 1.423889] ESR = 0x0000000096000006\n[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 1.424715] SET = 0, FnV = 0\n[ 1.424995] EA = 0, S1PTW = 0\n[ 1.425279] FSC = 0x06: level 2 translation fault\n[ 1.425735] Data abort info:\n[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000\n[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000\n[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP\n[ 1.429525] Modules linked in:\n[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT\n[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)\n[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488\n[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488\n[ 1.432543] sp : ffffffc084e1b960\n[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0\n[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378\n[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff\n[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7\n[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372\n[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860\n[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000\n[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000\n[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68\n[ 1.439332] Call trace:\n[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)\n[ 1.440016] smp_call_function_any+0xc8/0xd0\n[ 1.440416] armv8_pmu_init+0x58/0x27c\n[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c\n[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8\n[ 1.441603] armv8_pmu_device_probe+0x1c/0x28\n[ 1.442007] platform_probe+0x5c/0xac\n[ 1.442347] really_probe+0xbc/0x298\n[ 1.442683] __driver_probe_device+0x78/0x12c\n[ 1.443087] driver_probe_device+0xdc/0x160\n[ 1.443475] __driver_attach+0x94/0x19c\n[ 1.443833] bus_for_each_dev+0x74/0xd4\n[ 1.444190] driver_attach+0x24/0x30\n[ 1.444525] bus_add_driver+0xe4/0x208\n[ 1.444874] driver_register+0x60/0x128\n[ 1.445233] __platform_driver_register+0x24/0x30\n[ 1.445662] armv8_pmu_driver_init+0x28/0x4c\n[ 1.446059] do_one_initcall+0x44/0x25c\n[ 1.446416] kernel_init_freeable+0x1dc/0x3bc\n[ 1.446820] kernel_init+0x20/0x1d8\n[ 1.447151] ret_from_fork+0x10/0x20\n[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)\n[ 1.448040] ---[ end trace 0000000000000000 ]---\n[ 1.448483] note: swapper/0[1] exited with preempt_count 1\n[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n[ 1.449741] SMP: stopping secondary CPUs\n[ 1.450105] Kernel Offset: disabled\n[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b\n[ \n---truncated---(CVE-2025-39895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Silence warning when chunk allocation fails in trace_pid_write\n\nSyzkaller trigger a fault injection warning:\n\nWARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0\nModules linked in:\nCPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0\nTainted: [U]=USER\nHardware name: Google Compute Engine/Google Compute Engine\nRIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294\nCode: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff\nRSP: 0018:ffffc9000414fb48 EFLAGS: 00010283\nRAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000\nRDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0\nFS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464\n register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]\n register_pid_events kernel/trace/trace_events.c:2354 [inline]\n event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425\n vfs_write+0x24c/0x1150 fs/read_write.c:677\n ksys_write+0x12b/0x250 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe can reproduce the warning by following the steps below:\n1. echo 8 \u0026gt;\u0026gt; set_event_notrace_pid. Let tr-\u0026gt;filtered_pids owns one pid\n and register sched_switch tracepoint.\n2. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid, and perform fault injection during chunk\n allocation of trace_pid_list_alloc. Let pid_list with no pid and\nassign to tr-\u0026gt;filtered_pids.\n3. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid. Let pid_list is NULL and assign to\n tr-\u0026gt;filtered_pids.\n4. echo 9 \u0026gt;\u0026gt; set_event_pid, will trigger the double register\n sched_switch tracepoint warning.\n\nThe reason is that syzkaller injects a fault into the chunk allocation\nin trace_pid_list_alloc, causing a failure in trace_pid_list_set, which\nmay trigger double register of the same tracepoint. This only occurs\nwhen the system is about to crash, but to suppress this warning, let\u0026apos;s\nadd failure handling logic to trace_pid_list_set.(CVE-2025-39914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0 CPU1\nmount perf_event umount net_prio\ncgroup1_get_tree cgroup_kill_sb\nrebind_subsystems // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n // one perf_event css A is dying\n // css A offline enqueues cgroup_destroy_wq\n // root destruction will be executed first\n css_free_rwork_fn\n cgroup_destroy_root\n cgroup_lock_and_drain_offline\n // some perf descendants are dying\n // cgroup_destroy_wq max_active = 1\n // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq \u2013 Handles CSS offline operations\ncgroup_release_wq \u2013 Manages resource release\ncgroup_free_wq \u2013 Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)",
"id": "OESA-2025-2466",
"modified": "2026-08-06T11:09:33Z",
"published": "2025-10-17T11:09:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2466"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39953"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56591",
"CVE-2025-22005",
"CVE-2025-22081",
"CVE-2025-37741",
"CVE-2025-38086",
"CVE-2025-38319",
"CVE-2025-39683",
"CVE-2025-39715",
"CVE-2025-39739",
"CVE-2025-39752",
"CVE-2025-39760",
"CVE-2025-39819",
"CVE-2025-39824",
"CVE-2025-39844",
"CVE-2025-39845",
"CVE-2025-39850",
"CVE-2025-39851",
"CVE-2025-39853",
"CVE-2025-39865",
"CVE-2025-39883",
"CVE-2025-39886",
"CVE-2025-39895",
"CVE-2025-39914",
"CVE-2025-39953"
]
}
OESA-2025-2467 (CVE-2024-56591)
Vulnerability from osv_openeuler – Published: 2025-10-17 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_conn: Use disable_delayed_work_sync
This makes use of disable_delayed_work_sync instead cancel_delayed_work_sync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.(CVE-2024-56591)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().
fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything when it fails.
Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh") moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init() but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output in case it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.
Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in the error path.
Note that we can remove the fib6_nh_release() call in nh_create_ipv6() later in net-next.git.(CVE-2025-22005)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix a couple integer overflows on 32bit systems
On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)
In the Linux kernel, the following vulnerability has been resolved:
jfs: Prevent copying of nlink with value 0 from disk inode
syzbot report a deadlock in diFree. [1]
When calling "ioctl$LOOP_SET_STATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.
When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in read_metapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copy_from_dinode(), which ultimately causes a deadlock when entering diFree().
To avoid this, first check the nlink value of dinode before setting iag inode.
[1] WARNING: possible recursive locking detected 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted
syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889
but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630
other info that might help us debug this: Possible unsafe locking scenario:
CPU0
----
lock(&(imap->im_aglock[index])); lock(&(imap->im_aglock[index]));
*** DEADLOCK ***
May be due to missing lock nesting notation
5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #3: ffff888044548890 (&imap->im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669 #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline] #4: ffff88804755a618 (&jfs_ip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669
stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037 check_deadlock kernel/locking/lockdep.c:3089 [inline] validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __mutex_lock_common kernel/locking/mutex.c:608 [inline] __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889 jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfs_imap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022 diNewIAG fs/jfs/jfs_imap.c:2597 [inline] diAllocExt fs/jfs/jfs_imap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/en ---truncated---(CVE-2025-37741)
In the Linux kernel, the following vulnerability has been resolved:
net: ch9200: fix uninitialised access during mii_nway_restart
In mii_nway_restart() the code attempts to call mii->mdio_read which is ch9200_mdio_read(). ch9200_mdio_read() utilises a local buffer called "buff", which is initialised with control_read(). However "buff" is conditionally initialised inside control_read():
if (err == size) {
memcpy(data, buf, size);
}
If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200_mdio_read():
return (buff[0] | buff[1] << 8);
The problem stems from the fact that ch9200_mdio_read() ignores the return value of control_read(), leading to uinit-access of "buff".
To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table
The function atomctrl_initialize_mc_reg_table() and atomctrl_initialize_mc_reg_table_v2_2() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve vram_info, it returns NULL which is later dereferenced.(CVE-2025-38319)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Limit access to parser->buffer when trace_get_user failed
When the length of the string written to set_ftrace_filter exceeds FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:
BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165
CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0
The reason is that trace_get_user will fail when processing a string longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftrace_regex_release-> ftrace_process_regex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when trace_get_user failed.(CVE-2025-39683)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Revise gateway LWS calls to probe user read access
We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER).
Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.(CVE-2025-39715)
In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-qcom: Add SM6115 MDSS compatible
Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot:
arm_smmu_context_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420
and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed)
------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msm_gem_vma_init+0x150/0x18c [msm] lr : msm_gem_vma_init+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msm_gem_vma_init+0x150/0x18c [msm] (P) get_vma_locked+0xc0/0x194 [msm] msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm] msm_gem_kernel_new+0x48/0x160 [msm] msm_gpu_init+0x34c/0x53c [msm] adreno_gpu_init+0x1b0/0x2d8 [msm] a6xx_gpu_init+0x1e8/0x9e0 [msm] adreno_bind+0x2b8/0x348 [msm] component_bind_all+0x100/0x230 msm_drm_bind+0x13c/0x3d0 [msm] try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa4/0x174 component_add+0x14/0x20 dsi_dev_attach+0x20/0x34 [msm] dsi_host_attach+0x58/0x98 [msm] devm_mipi_dsi_attach+0x34/0x90 lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc] lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc] i2c_device_probe+0x148/0x2a8 really_probe+0xbc/0x2c0 __driver_probe_device+0x78/0x120 driver_probe_device+0x3c/0x154 __driver_attach+0x90/0x1a0 bus_for_each_dev+0x68/0xb8 driver_attach+0x24/0x30 bus_add_driver+0xe4/0x208 driver_register+0x68/0x124 i2c_register_driver+0x48/0xcc lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc] do_one_initcall+0x60/0x1d4 do_init_module+0x54/0x1fc load_module+0x1748/0x1c8c init_module_from_file+0x74/0xa0 __arm64_sys_finit_module+0x130/0x2f8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x2c/0x80 el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] ERROR could not allocate memptrs: -22 msm_dpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22 msm_dpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)
In the Linux kernel, the following vulnerability has been resolved:
ARM: rockchip: fix kernel hang during smp initialization
In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.
The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.
That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)
In the Linux kernel, the following vulnerability has been resolved:
usb: core: config: Prevent OOB read in SS endpoint companion parsing
usb_parse_ss_endpoint_companion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.
Fix this up by checking the size first before looking at any of the fields in the descriptor.(CVE-2025-39760)
In the Linux kernel, the following vulnerability has been resolved:
fs/smb: Fix inconsistent refcnt update
A possible inconsistent update of refcount was identified in smb2_compound_op.
Such inconsistent update could lead to possible resource leaks.
Why it is a possible bug:
1. In the comment section of the function, it clearly states that the
reference to cfile should be dropped after calling this function.
2. Every control flow path would check and drop the reference to
cfile, except the patched one.
3. Existing callers would not handle refcount update of cfile if
-ENOMEM is returned.
To fix the bug, an extra goto label "out" is added, to make sure that the
cleanup logic would always be respected. As the problem is caused by the
allocation failure of vars, the cleanup logic between label "finished"
and "out" can be safely ignored. According to the definition of function
is_replayable_error, the error code of "-ENOMEM" is not recoverable.
Therefore, the replay logic also gets ignored.(CVE-2025-39819)
A use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)
In the Linux kernel, the following vulnerability has been resolved:
mm: move page table sync declarations to linux/pgtable.h
During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:
BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: <TASK> __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] </TASK>
It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks.
And looking at __populate_section_memmap():
if (vmemmap_can_optimize(altmap, pgmap))
// does not sync top level page tables
r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);
else
// sync top level page tables in x86
r = vmemmap_populate(start, end, nid, altmap);
In the normal path, vmemmap_populate() in arch/x86/mm/init_64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.
However, when vmemmap_can_optimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmap_populate_compound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.
We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.
It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.
The solution: Make page table sync more code robust and harder to miss
To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}_populate_kernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.
The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK, PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by vmalloc and ioremap to synchronize page tables.
pgd_populate_kernel() looks like this: static inline void pgd_populate_kernel(unsigned long addr, pgd_t pgd, p4d_t p4d) { pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr); }
It is worth noting that vmalloc() and apply_to_range() carefully synchronizes page tables by calling p*d_alloc_track() and arch_sync_kernel_mappings(), and thus they are not affected by ---truncated---(CVE-2025-39844)
In the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects
When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).
The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].
Fix by checking that the remote destination exists before dereferencing it.
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo
ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy
ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3
[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace: <TASK> dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77
[4] #!/bin/bash
ip address add 2001:db8:1::1/128 dev lo
ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy
ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0
bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10
ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix NPD when refreshing an FDB entry with a nexthop object
VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.
However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].
Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53
[2] #!/bin/bash
ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo
ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb
ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning
bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10
mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix potential invalid access when MAC list is empty
list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.
Fix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)
A NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)
A vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()
Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:
... [10.011566] do_raw_spin_lock.cold [10.011570] try_to_wake_up (5) double-acquiring the same [10.011575] kick_pool rq_lock, causing a hardlockup [10.011579] __queue_work [10.011582] queue_work_on [10.011585] kernfs_notify [10.011589] cgroup_file_notify [10.011593] try_charge_memcg (4) memcg accounting raises an [10.011597] obj_cgroup_charge_pages MEMCG_MAX event [10.011599] obj_cgroup_charge_account [10.011600] __memcg_slab_post_alloc_hook [10.011603] __kmalloc_node_noprof ... [10.011611] bpf_map_kmalloc_node [10.011612] __bpf_async_init [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init() [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable [10.011619] bpf__sched_ext_ops_runnable [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held [10.011622] enqueue_task [10.011626] ttwu_do_activate [10.011629] sched_ttwu_pending (1) grabs rq_lock ...
The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.
We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.
As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.
Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/(CVE-2025-39886)
In the Linux kernel, the following vulnerability has been resolved:
sched: Fix sched_numa_find_nth_cpu() if mask offline
sched_numa_find_nth_cpu() uses a bsearch to look for the 'closest' CPU in sched_domains_numa_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.
The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):
[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000
[ 1.423635] Mem abort info:
[ 1.423889] ESR = 0x0000000096000006
[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.424715] SET = 0, FnV = 0
[ 1.424995] EA = 0, S1PTW = 0
[ 1.425279] FSC = 0x06: level 2 translation fault
[ 1.425735] Data abort info:
[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000
[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000
[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000
[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP
[ 1.429525] Modules linked in:
[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT
[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)
[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488
[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488
[ 1.432543] sp : ffffffc084e1b960
[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0
[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378
[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff
[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7
[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372
[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860
[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000
[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000
[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68
[ 1.439332] Call trace:
[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)
[ 1.440016] smp_call_function_any+0xc8/0xd0
[ 1.440416] armv8_pmu_init+0x58/0x27c
[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c
[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8
[ 1.441603] armv8_pmu_device_probe+0x1c/0x28
[ 1.442007] platform_probe+0x5c/0xac
[ 1.442347] really_probe+0xbc/0x298
[ 1.442683] __driver_probe_device+0x78/0x12c
[ 1.443087] driver_probe_device+0xdc/0x160
[ 1.443475] __driver_attach+0x94/0x19c
[ 1.443833] bus_for_each_dev+0x74/0xd4
[ 1.444190] driver_attach+0x24/0x30
[ 1.444525] bus_add_driver+0xe4/0x208
[ 1.444874] driver_register+0x60/0x128
[ 1.445233] __platform_driver_register+0x24/0x30
[ 1.445662] armv8_pmu_driver_init+0x28/0x4c
[ 1.446059] do_one_initcall+0x44/0x25c
[ 1.446416] kernel_init_freeable+0x1dc/0x3bc
[ 1.446820] kernel_init+0x20/0x1d8
[ 1.447151] ret_from_fork+0x10/0x20
[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)
[ 1.448040] ---[ end trace 0000000000000000 ]---
[ 1.448483] note: swapper/0[1] exited with preempt_count 1
[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.449741] SMP: stopping secondary CPUs
[ 1.450105] Kernel Offset: disabled
[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b
[
---truncated---(CVE-2025-39895)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Silence warning when chunk allocation fails in trace_pid_write
Syzkaller trigger a fault injection warning:
WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464 register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline] register_pid_events kernel/trace/trace_events.c:2354 [inline] event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425 vfs_write+0x24c/0x1150 fs/read_write.c:677 ksys_write+0x12b/0x250 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f
We can reproduce the warning by following the steps below: 1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid and register sched_switch tracepoint. 2. echo ' ' >> set_event_pid, and perform fault injection during chunk allocation of trace_pid_list_alloc. Let pid_list with no pid and assign to tr->filtered_pids. 3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to tr->filtered_pids. 4. echo 9 >> set_event_pid, will trigger the double register sched_switch tracepoint warning.
The reason is that syzkaller injects a fault into the chunk allocation in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to trace_pid_list_set.(CVE-2025-39914)
In the Linux kernel, the following vulnerability has been resolved:
cgroup: split cgroup_destroy_wq into 3 workqueues
A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perf_event and net_prio controllers with systemd.unified_cgroup_hierarchy=1. The hang manifests in cgroup_lock_and_drain_offline() during root destruction.
Related case: cgroup_fj_function_perf_event cgroup_fj_function.sh perf_event cgroup_fj_function_net_prio cgroup_fj_function.sh net_prio
Call Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20
Root Cause:
CPU0 CPU1 mount perf_event umount net_prio cgroup1_get_tree cgroup_kill_sb rebind_subsystems // root destruction enqueues // cgroup_destroy_wq // kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to die
Problem scenario: 1. CPU0 mounts perf_event (rebind_subsystems) 2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work 3. A dying perf_event CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)
Solution: Split cgroup_destroy_wq into three dedicated workqueues: cgroup_offline_wq – Handles CSS offline operations cgroup_release_wq – Manages resource release cgroup_free_wq – Performs final memory deallocation
This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.
[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"perf-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.118.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-112.0.0.118.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"perf-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-112.0.0.118.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-112.0.0.118.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-112.0.0.118.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\nBluetooth: hci_conn: Use disable_delayed_work_sync\n\nThis makes use of disable_delayed_work_sync instead\ncancel_delayed_work_sync as it not only cancel the ongoing work but also\ndisables new submit which is disarable since the object holding the work\nis about to be freed.(CVE-2024-56591)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().\n\nfib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everything\nwhen it fails.\n\nCommit 7dd73168e273 (\u0026quot;ipv6: Always allocate pcpu memory in a fib6_nh\u0026quot;)\nmoved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()\nbut forgot to add cleanup for fib6_nh-\u0026gt;nh_common.nhc_pcpu_rth_output in\ncase it fails to allocate fib6_nh-\u0026gt;rt6i_pcpu, resulting in memleak.\n\nLet\u0026apos;s call fib_nh_common_release() and clear nhc_pcpu_rth_output in the\nerror path.\n\nNote that we can remove the fib6_nh_release() call in nh_create_ipv6()\nlater in net-next.git.(CVE-2025-22005)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix a couple integer overflows on 32bit systems\n\nOn 32bit systems the \u0026quot;off + sizeof(struct NTFS_DE)\u0026quot; addition can\nhave an integer wrapping issue. Fix it by using size_add().(CVE-2025-22081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: Prevent copying of nlink with value 0 from disk inode\n\nsyzbot report a deadlock in diFree. [1]\n\nWhen calling \u0026quot;ioctl$LOOP_SET_STATUS64\u0026quot;, the offset value passed in is 4,\nwhich does not match the mounted loop device, causing the mapping of the\nmounted loop device to be invalidated.\n\nWhen creating the directory and creating the inode of iag in diReadSpecial(),\nread the page of fixed disk inode (AIT) in raw mode in read_metapage(), the\nmetapage data it returns is corrupted, which causes the nlink value of 0 to be\nassigned to the iag inode when executing copy_from_dinode(), which ultimately\ncauses a deadlock when entering diFree().\n\nTo avoid this, first check the nlink value of dinode before setting iag inode.\n\n[1]\nWARNING: possible recursive locking detected\n6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted\n--------------------------------------------\nsyz-executor301/5309 is trying to acquire lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n\nbut task is already holding lock:\nffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n\nother info that might help us debug this:\n Possible unsafe locking scenario:\n\n CPU0\n ----\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n lock(\u0026amp;(imap-\u0026gt;im_aglock[index]));\n\n *** DEADLOCK ***\n\n May be due to missing lock nesting notation\n\n5 locks held by syz-executor301/5309:\n #0: ffff8880422a4420 (sb_writers#9){.+.+}-{0:0}, at: mnt_want_write+0x3f/0x90 fs/namespace.c:515\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: inode_lock_nested include/linux/fs.h:850 [inline]\n #1: ffff88804755b390 (\u0026amp;type-\u0026gt;i_mutex_dir_key#6/1){+.+.}-{3:3}, at: filename_create+0x260/0x540 fs/namei.c:4026\n #2: ffff888044548920 (\u0026amp;(imap-\u0026gt;im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2460 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #3: ffff888044548890 (\u0026amp;imap-\u0026gt;im_freelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfs_imap.c:1669\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfs_imap.c:2477 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n #4: ffff88804755a618 (\u0026amp;jfs_ip-\u0026gt;rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_deadlock_bug+0x483/0x620 kernel/locking/lockdep.c:3037\n check_deadlock kernel/locking/lockdep.c:3089 [inline]\n validate_chain+0x15e2/0x5920 kernel/locking/lockdep.c:3891\n __lock_acquire+0x1384/0x2050 kernel/locking/lockdep.c:5202\n lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825\n __mutex_lock_common kernel/locking/mutex.c:608 [inline]\n __mutex_lock+0x136/0xd70 kernel/locking/mutex.c:752\n diFree+0x37c/0x2fb0 fs/jfs/jfs_imap.c:889\n jfs_evict_inode+0x32d/0x440 fs/jfs/inode.c:156\n evict+0x4e8/0x9b0 fs/inode.c:725\n diFreeSpecial fs/jfs/jfs_imap.c:552 [inline]\n duplicateIXtree+0x3c6/0x550 fs/jfs/jfs_imap.c:3022\n diNewIAG fs/jfs/jfs_imap.c:2597 [inline]\n diAllocExt fs/jfs/jfs_imap.c:1905 [inline]\n diAllocAG+0x17dc/0x1e50 fs/jfs/jfs_imap.c:1669\n diAlloc+0x1d2/0x1630 fs/jfs/jfs_imap.c:1590\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xba0 fs/jfs/namei.c:225\n vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257\n do_mkdirat+0x264/0x3a0 fs/namei.c:4280\n __do_sys_mkdirat fs/namei.c:4295 [inline]\n __se_sys_mkdirat fs/namei.c:4293 [inline]\n __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293\n do_syscall_x64 arch/x86/en\n---truncated---(CVE-2025-37741)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ch9200: fix uninitialised access during mii_nway_restart\n\nIn mii_nway_restart() the code attempts to call\nmii-\u0026gt;mdio_read which is ch9200_mdio_read(). ch9200_mdio_read()\nutilises a local buffer called \u0026quot;buff\u0026quot;, which is initialised\nwith control_read(). However \u0026quot;buff\u0026quot; is conditionally\ninitialised inside control_read():\n\n if (err == size) {\n memcpy(data, buf, size);\n }\n\nIf the condition of \u0026quot;err == size\u0026quot; is not met, then\n\u0026quot;buff\u0026quot; remains uninitialised. Once this happens the\nuninitialised \u0026quot;buff\u0026quot; is accessed and returned during\nch9200_mdio_read():\n\n return (buff[0] | buff[1] \u0026lt;\u0026lt; 8);\n\nThe problem stems from the fact that ch9200_mdio_read()\nignores the return value of control_read(), leading to\nuinit-access of \u0026quot;buff\u0026quot;.\n\nTo fix this we should check the return value of\ncontrol_read() and return early on error.(CVE-2025-38086)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table\n\nThe function atomctrl_initialize_mc_reg_table() and\natomctrl_initialize_mc_reg_table_v2_2() does not check the return\nvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()\nfails to retrieve vram_info, it returns NULL which is later\ndereferenced.(CVE-2025-38319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Limit access to parser-\u0026gt;buffer when trace_get_user failed\n\nWhen the length of the string written to set_ftrace_filter exceeds\nFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:\n\nBUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0\nRead of size 1 at addr ffff0000d00bd5ba by task ash/165\n\nCPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty\nHardware name: linux,dummy-virt (DT)\nCall trace:\n show_stack+0x34/0x50 (C)\n dump_stack_lvl+0xa0/0x158\n print_address_description.constprop.0+0x88/0x398\n print_report+0xb0/0x280\n kasan_report+0xa4/0xf0\n __asan_report_load1_noabort+0x20/0x30\n strsep+0x18c/0x1b0\n ftrace_process_regex.isra.0+0x100/0x2d8\n ftrace_regex_release+0x484/0x618\n __fput+0x364/0xa58\n ____fput+0x28/0x40\n task_work_run+0x154/0x278\n do_notify_resume+0x1f0/0x220\n el0_svc+0xec/0xf0\n el0t_64_sync_handler+0xa0/0xe8\n el0t_64_sync+0x1ac/0x1b0\n\nThe reason is that trace_get_user will fail when processing a string\nlonger than FTRACE_BUFF_MAX, but not set the end of parser-\u0026gt;buffer to 0.\nThen an OOB access will be triggered in ftrace_regex_release-\u0026gt;\nftrace_process_regex-\u0026gt;strsep-\u0026gt;strpbrk. We can solve this problem by\nlimiting access to parser-\u0026gt;buffer when trace_get_user failed.(CVE-2025-39683)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Revise gateway LWS calls to probe user read access\n\nWe use load and stbys,e instructions to trigger memory reference\ninterruptions without writing to memory. Because of the way read\naccess support is implemented, read access interruptions are only\ntriggered at privilege levels 2 and 3. The kernel and gateway\npage execute at privilege level 0, so this code never triggers\na read access interruption. Thus, it is currently possible for\nuser code to execute a LWS compare and swap operation at an\naddress that is read protected at privilege level 3 (PRIV_USER).\n\nFix this by probing read access rights at privilege level 3 and\nbranching to lws_fault if access isn\u0026apos;t allowed.(CVE-2025-39715)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu-qcom: Add SM6115 MDSS compatible\n\nAdd the SM6115 MDSS compatible to clients compatible list, as it also\nneeds that workaround.\nWithout this workaround, for example, QRB4210 RB2 which is based on\nSM4250/SM6115 generates a lot of smmu unhandled context faults during\nboot:\n\narm_smmu_context_fault: 116854 callbacks suppressed\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\narm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1]\narm-smmu c600000.iommu: Unhandled context fault: fsr=0x402,\niova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5\narm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420\n\nand also failed initialisation of lontium lt9611uxc, gpu and dpu is\nobserved:\n(binding MDSS components triggered by lt9611uxc have failed)\n\n ------------[ cut here ]------------\n !aspace\n WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msm_gem_vma.c:130 msm_gem_vma_init+0x150/0x18c [msm]\n Modules linked in: ... (long list of modules)\n CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT\n Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT)\n pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : msm_gem_vma_init+0x150/0x18c [msm]\n lr : msm_gem_vma_init+0x150/0x18c [msm]\n sp : ffff80008144b280\n \t\t...\n Call trace:\n msm_gem_vma_init+0x150/0x18c [msm] (P)\n get_vma_locked+0xc0/0x194 [msm]\n msm_gem_get_and_pin_iova_range+0x4c/0xdc [msm]\n msm_gem_kernel_new+0x48/0x160 [msm]\n msm_gpu_init+0x34c/0x53c [msm]\n adreno_gpu_init+0x1b0/0x2d8 [msm]\n a6xx_gpu_init+0x1e8/0x9e0 [msm]\n adreno_bind+0x2b8/0x348 [msm]\n component_bind_all+0x100/0x230\n msm_drm_bind+0x13c/0x3d0 [msm]\n try_to_bring_up_aggregate_device+0x164/0x1d0\n __component_add+0xa4/0x174\n component_add+0x14/0x20\n dsi_dev_attach+0x20/0x34 [msm]\n dsi_host_attach+0x58/0x98 [msm]\n devm_mipi_dsi_attach+0x34/0x90\n lt9611uxc_attach_dsi.isra.0+0x94/0x124 [lontium_lt9611uxc]\n lt9611uxc_probe+0x540/0x5fc [lontium_lt9611uxc]\n i2c_device_probe+0x148/0x2a8\n really_probe+0xbc/0x2c0\n __driver_probe_device+0x78/0x120\n driver_probe_device+0x3c/0x154\n __driver_attach+0x90/0x1a0\n bus_for_each_dev+0x68/0xb8\n driver_attach+0x24/0x30\n bus_add_driver+0xe4/0x208\n driver_register+0x68/0x124\n i2c_register_driver+0x48/0xcc\n lt9611uxc_driver_init+0x20/0x1000 [lontium_lt9611uxc]\n do_one_initcall+0x60/0x1d4\n do_init_module+0x54/0x1fc\n load_module+0x1748/0x1c8c\n init_module_from_file+0x74/0xa0\n __arm64_sys_finit_module+0x130/0x2f8\n invoke_syscall+0x48/0x104\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x2c/0x80\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n ---[ end trace 0000000000000000 ]---\n msm_dpu 5e01000.display-controller: [drm:msm_gpu_init [msm]] *ERROR* could not allocate memptrs: -22\n msm_dpu 5e01000.display-controller: failed to load adreno gpu\n platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19\n msm_dpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xx_ops [msm]): -22\n msm_dpu 5e01000.display-controller: adev bind failed: -22\n lt9611uxc 0-002b: failed to attach dsi to host\n lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: rockchip: fix kernel hang during smp initialization\n\nIn order to bring up secondary CPUs main CPU write trampoline\ncode to SRAM. The trampoline code is written while secondary\nCPUs are powered on (at least that true for RK3188 CPU).\nSometimes that leads to kernel hang. Probably because secondary\nCPU execute trampoline code while kernel doesn\u0026apos;t expect.\n\nThe patch moves SRAM initialization step to the point where all\nsecondary CPUs are powered down.\n\nThat fixes rarely hangs on RK3188:\n[ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000\n[ 0.091996] rockchip_smp_prepare_cpus: ncores 4(CVE-2025-39752)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: core: config: Prevent OOB read in SS endpoint companion parsing\n\nusb_parse_ss_endpoint_companion() checks descriptor type before length,\nenabling a potentially odd read outside of the buffer size.\n\nFix this up by checking the size first before looking at any of the\nfields in the descriptor.(CVE-2025-39760)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/smb: Fix inconsistent refcnt update\n\nA possible inconsistent update of refcount was identified in `smb2_compound_op`.\nSuch inconsistent update could lead to possible resource leaks.\n\nWhy it is a possible bug:\n1. In the comment section of the function, it clearly states that the\nreference to `cfile` should be dropped after calling this function.\n2. Every control flow path would check and drop the reference to\n`cfile`, except the patched one.\n3. Existing callers would not handle refcount update of `cfile` if\n-ENOMEM is returned.\n\nTo fix the bug, an extra goto label \u0026quot;out\u0026quot; is added, to make sure that the\ncleanup logic would always be respected. As the problem is caused by the\nallocation failure of `vars`, the cleanup logic between label \u0026quot;finished\u0026quot;\nand \u0026quot;out\u0026quot; can be safely ignored. According to the definition of function\n`is_replayable_error`, the error code of \u0026quot;-ENOMEM\u0026quot; is not recoverable.\nTherefore, the replay logic also gets ignored.(CVE-2025-39819)\n\nA use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hid_hw_start() is called, hidinput_connect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinput_has_been_populated() check fails, leading to the freeing of hid_input and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hid_hw_start().(CVE-2025-39824)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: move page table sync declarations to linux/pgtable.h\n\nDuring our internal testing, we started observing intermittent boot\nfailures when the machine uses 4-level paging and has a large amount of\npersistent memory:\n\n BUG: unable to handle page fault for address: ffffe70000000034\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0 \n Oops: 0002 [#1] SMP NOPTI\n RIP: 0010:__init_single_page+0x9/0x6d\n Call Trace:\n \u0026lt;TASK\u0026gt;\n __init_zone_device_page+0x17/0x5d\n memmap_init_zone_device+0x154/0x1bb\n pagemap_range+0x2e0/0x40f\n memremap_pages+0x10b/0x2f0\n devm_memremap_pages+0x1e/0x60\n dev_dax_probe+0xce/0x2ec [device_dax]\n dax_bus_probe+0x6d/0xc9\n [... snip ...]\n \u0026lt;/TASK\u0026gt;\n\nIt turns out that the kernel panics while initializing vmemmap (struct\npage array) when the vmemmap region spans two PGD entries, because the new\nPGD entry is only installed in init_mm.pgd, but not in the page tables of\nother tasks.\n\nAnd looking at __populate_section_memmap():\n if (vmemmap_can_optimize(altmap, pgmap)) \n // does not sync top level page tables\n r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap);\n else \n // sync top level page tables in x86\n r = vmemmap_populate(start, end, nid, altmap);\n\nIn the normal path, vmemmap_populate() in arch/x86/mm/init_64.c\nsynchronizes the top level page table (See commit 9b861528a801 (\u0026quot;x86-64,\nmem: Update all PGDs for direct mapping and vmemmap mapping changes\u0026quot;)) so\nthat all tasks in the system can see the new vmemmap area.\n\nHowever, when vmemmap_can_optimize() returns true, the optimized path\nskips synchronization of top-level page tables. This is because\nvmemmap_populate_compound_pages() is implemented in core MM code, which\ndoes not handle synchronization of the top-level page tables. Instead,\nthe core MM has historically relied on each architecture to perform this\nsynchronization manually.\n\nWe\u0026apos;re not the first party to encounter a crash caused by not-sync\u0026apos;d top\nlevel page tables: earlier this year, Gwan-gyeong Mun attempted to address\nthe issue [1] [2] after hitting a kernel panic when x86 code accessed the\nvmemmap area before the corresponding top-level entries were synced. At\nthat time, the issue was believed to be triggered only when struct page\nwas enlarged for debugging purposes, and the patch did not get further\nupdates.\n\nIt turns out that current approach of relying on each arch to handle the\npage table sync manually is fragile because 1) it\u0026apos;s easy to forget to sync\nthe top level page table, and 2) it\u0026apos;s also easy to overlook that the\nkernel should not access the vmemmap and direct mapping areas before the\nsync.\n\n# The solution: Make page table sync more code robust and harder to miss\n\nTo address this, Dave Hansen suggested [3] [4] introducing\n{pgd,p4d}_populate_kernel() for updating kernel portion of the page tables\nand allow each architecture to explicitly perform synchronization when\ninstalling top-level entries. With this approach, we no longer need to\nworry about missing the sync step, reducing the risk of future\nregressions.\n\nThe new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,\nPGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used by\nvmalloc and ioremap to synchronize page tables.\n\npgd_populate_kernel() looks like this:\nstatic inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd,\n p4d_t *p4d)\n{\n pgd_populate(\u0026amp;init_mm, pgd, p4d);\n if (ARCH_PAGE_TABLE_SYNC_MASK \u0026amp; PGTBL_PGD_MODIFIED)\n arch_sync_kernel_mappings(addr, addr);\n}\n\nIt is worth noting that vmalloc() and apply_to_range() carefully\nsynchronizes page tables by calling p*d_alloc_track() and\narch_sync_kernel_mappings(), and thus they are not affected by\n---truncated---(CVE-2025-39844)\n\nIn the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() to ensure proper page table synchronization when calling p*d_populate_kernel(). For 5-level paging, synchronization is performed via pgd_populate_kernel(). In 4-level paging, pgd_populate() is a no-op, so synchronization is instead performed at the P4D level via p4d_populate_kernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmap_set_pmd() caused by accessing vmemmap before sync_global_pgds().(CVE-2025-39845)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the \u0026quot;proxy\u0026quot; option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the \u0026quot;any\u0026quot; remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor\u0026apos;s MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD when refreshing an FDB entry with a nexthop object\n\nVXLAN FDB entries can point to either a remote destination or an FDB\nnexthop group. The latter is usually used in EVPN deployments where\nlearning is disabled.\n\nHowever, when learning is enabled, an incoming packet might try to\nrefresh an FDB entry that points to an FDB nexthop group and therefore\ndoes not have a remote. Such packets should be dropped, but they are\nonly dropped after dereferencing the non-existent remote, resulting in a\nNPD [1] which can be reproduced using [2].\n\nFix by dropping such packets earlier. Remove the misleading comment from\nfirst_remote_rcu().\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_snoop+0x98/0x1e0\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vxlan_encap_bypass+0x209/0x240\n encap_bypass_if_local+0xb1/0x100\n vxlan_xmit_one+0x1375/0x17e0\n vxlan_xmit+0x6b4/0x15f0\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n ip address add 192.0.2.2/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.3 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass\n ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020\n bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10\n\n mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)\n\nA NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The tee_shm_put function has a NULL pointer dereference issue: in the __optee_disable_shm_cache function, reg_pair_to_ptr may return a NULL pointer, but when tee_shm_free calls tee_shm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)\n\nA vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoison_memory function of the mm/memory-failure module, where it tries to check the PG_HWPoison flags of an uninitialized page, triggering VM_BUG_ON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()\n\nCurrently, calling bpf_map_kmalloc_node() from __bpf_async_init() can\ncause various locking issues; see the following stack trace (edited for\nstyle) as one example:\n\n...\n [10.011566] do_raw_spin_lock.cold\n [10.011570] try_to_wake_up (5) double-acquiring the same\n [10.011575] kick_pool rq_lock, causing a hardlockup\n [10.011579] __queue_work\n [10.011582] queue_work_on\n [10.011585] kernfs_notify\n [10.011589] cgroup_file_notify\n [10.011593] try_charge_memcg (4) memcg accounting raises an\n [10.011597] obj_cgroup_charge_pages MEMCG_MAX event\n [10.011599] obj_cgroup_charge_account\n [10.011600] __memcg_slab_post_alloc_hook\n [10.011603] __kmalloc_node_noprof\n...\n [10.011611] bpf_map_kmalloc_node\n [10.011612] __bpf_async_init\n [10.011615] bpf_timer_init (3) BPF calls bpf_timer_init()\n [10.011617] bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable\n [10.011619] bpf__sched_ext_ops_runnable\n [10.011620] enqueue_task_scx (2) BPF runs with rq_lock held\n [10.011622] enqueue_task\n [10.011626] ttwu_do_activate\n [10.011629] sched_ttwu_pending (1) grabs rq_lock\n...\n\nThe above was reproduced on bpf-next (b338cf849ec8) by modifying\n./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during\nops.runnable(), and hacking the memcg accounting code a bit to make\na bpf_timer_init() call more likely to raise an MEMCG_MAX event.\n\nWe have also run into other similar variants (both internally and on\nbpf-next), including double-acquiring cgroup_file_kn_lock, the same\nworker_pool::lock, etc.\n\nAs suggested by Shakeel, fix this by using __GFP_HIGH instead of\nGFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg()\nraises an MEMCG_MAX event, we call __memcg_memory_event() with\n@allow_spinning=false and avoid calling cgroup_file_notify() there.\n\nDepends on mm patch\n\u0026quot;memcg: skip cgroup_file_notify if spinning is not allowed\u0026quot;:\nhttps://lore.kernel.org/bpf/(CVE-2025-39886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched: Fix sched_numa_find_nth_cpu() if mask offline\n\nsched_numa_find_nth_cpu() uses a bsearch to look for the \u0026apos;closest\u0026apos;\nCPU in sched_domains_numa_masks and given cpus mask. However they\nmight not intersect if all CPUs in the cpus mask are offline. bsearch\nwill return NULL in that case, bail out instead of dereferencing a\nbogus pointer.\n\nThe previous behaviour lead to this bug when using maxcpus=4 on an\nrk3399 (LLLLbb) (i.e. booting with all big CPUs offline):\n\n[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000\n[ 1.423635] Mem abort info:\n[ 1.423889] ESR = 0x0000000096000006\n[ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits\n[ 1.424715] SET = 0, FnV = 0\n[ 1.424995] EA = 0, S1PTW = 0\n[ 1.425279] FSC = 0x06: level 2 translation fault\n[ 1.425735] Data abort info:\n[ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000\n[ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000\n[ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000\n[ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP\n[ 1.429525] Modules linked in:\n[ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT\n[ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT)\n[ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1.431634] pc : sched_numa_find_nth_cpu+0x2a0/0x488\n[ 1.432094] lr : sched_numa_find_nth_cpu+0x284/0x488\n[ 1.432543] sp : ffffffc084e1b960\n[ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0\n[ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n[ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378\n[ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff\n[ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7\n[ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372\n[ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860\n[ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000\n[ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000\n[ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68\n[ 1.439332] Call trace:\n[ 1.439559] sched_numa_find_nth_cpu+0x2a0/0x488 (P)\n[ 1.440016] smp_call_function_any+0xc8/0xd0\n[ 1.440416] armv8_pmu_init+0x58/0x27c\n[ 1.440770] armv8_cortex_a72_pmu_init+0x20/0x2c\n[ 1.441199] arm_pmu_device_probe+0x1e4/0x5e8\n[ 1.441603] armv8_pmu_device_probe+0x1c/0x28\n[ 1.442007] platform_probe+0x5c/0xac\n[ 1.442347] really_probe+0xbc/0x298\n[ 1.442683] __driver_probe_device+0x78/0x12c\n[ 1.443087] driver_probe_device+0xdc/0x160\n[ 1.443475] __driver_attach+0x94/0x19c\n[ 1.443833] bus_for_each_dev+0x74/0xd4\n[ 1.444190] driver_attach+0x24/0x30\n[ 1.444525] bus_add_driver+0xe4/0x208\n[ 1.444874] driver_register+0x60/0x128\n[ 1.445233] __platform_driver_register+0x24/0x30\n[ 1.445662] armv8_pmu_driver_init+0x28/0x4c\n[ 1.446059] do_one_initcall+0x44/0x25c\n[ 1.446416] kernel_init_freeable+0x1dc/0x3bc\n[ 1.446820] kernel_init+0x20/0x1d8\n[ 1.447151] ret_from_fork+0x10/0x20\n[ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803)\n[ 1.448040] ---[ end trace 0000000000000000 ]---\n[ 1.448483] note: swapper/0[1] exited with preempt_count 1\n[ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\n[ 1.449741] SMP: stopping secondary CPUs\n[ 1.450105] Kernel Offset: disabled\n[ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b\n[ \n---truncated---(CVE-2025-39895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Silence warning when chunk allocation fails in trace_pid_write\n\nSyzkaller trigger a fault injection warning:\n\nWARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0\nModules linked in:\nCPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0\nTainted: [U]=USER\nHardware name: Google Compute Engine/Google Compute Engine\nRIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294\nCode: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff\nRSP: 0018:ffffc9000414fb48 EFLAGS: 00010283\nRAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000\nRDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0\nFS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464\n register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]\n register_pid_events kernel/trace/trace_events.c:2354 [inline]\n event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425\n vfs_write+0x24c/0x1150 fs/read_write.c:677\n ksys_write+0x12b/0x250 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe can reproduce the warning by following the steps below:\n1. echo 8 \u0026gt;\u0026gt; set_event_notrace_pid. Let tr-\u0026gt;filtered_pids owns one pid\n and register sched_switch tracepoint.\n2. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid, and perform fault injection during chunk\n allocation of trace_pid_list_alloc. Let pid_list with no pid and\nassign to tr-\u0026gt;filtered_pids.\n3. echo \u0026apos; \u0026apos; \u0026gt;\u0026gt; set_event_pid. Let pid_list is NULL and assign to\n tr-\u0026gt;filtered_pids.\n4. echo 9 \u0026gt;\u0026gt; set_event_pid, will trigger the double register\n sched_switch tracepoint warning.\n\nThe reason is that syzkaller injects a fault into the chunk allocation\nin trace_pid_list_alloc, causing a failure in trace_pid_list_set, which\nmay trigger double register of the same tracepoint. This only occurs\nwhen the system is about to crash, but to suppress this warning, let\u0026apos;s\nadd failure handling logic to trace_pid_list_set.(CVE-2025-39914)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0 CPU1\nmount perf_event umount net_prio\ncgroup1_get_tree cgroup_kill_sb\nrebind_subsystems // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n // one perf_event css A is dying\n // css A offline enqueues cgroup_destroy_wq\n // root destruction will be executed first\n css_free_rwork_fn\n cgroup_destroy_root\n cgroup_lock_and_drain_offline\n // some perf descendants are dying\n // cgroup_destroy_wq max_active = 1\n // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq \u2013 Handles CSS offline operations\ncgroup_release_wq \u2013 Manages resource release\ncgroup_free_wq \u2013 Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)",
"id": "OESA-2025-2467",
"modified": "2026-08-06T11:09:33Z",
"published": "2025-10-17T11:09:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2467"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56591"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22005"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37741"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38086"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38319"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39683"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39715"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39752"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39760"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39844"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39845"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39865"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39886"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39895"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39914"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39953"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-56591",
"CVE-2025-22005",
"CVE-2025-22081",
"CVE-2025-37741",
"CVE-2025-38086",
"CVE-2025-38319",
"CVE-2025-39683",
"CVE-2025-39715",
"CVE-2025-39739",
"CVE-2025-39752",
"CVE-2025-39760",
"CVE-2025-39819",
"CVE-2025-39824",
"CVE-2025-39844",
"CVE-2025-39845",
"CVE-2025-39850",
"CVE-2025-39851",
"CVE-2025-39853",
"CVE-2025-39865",
"CVE-2025-39883",
"CVE-2025-39886",
"CVE-2025-39895",
"CVE-2025-39914",
"CVE-2025-39953"
]
}
OESA-2026-1341 (CVE-2022-49190)
Vulnerability from osv_openeuler – Published: 2026-02-13 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource(). And it s required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)
In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below: (Thread 1) | (Thread 2) | _set_timer()rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ...We hold pmlmepriv->lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv->lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obtainthe needed lock. What`s more, we change spin_lock_bh() inrtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,spin_lock_bh() will also cause deadlock() in timer handler.(CVE-2022-49309)
In the Linux kernel, the following vulnerability has been resolved:
drm/scheduler: fix fence ref counting
We leaked dependency fences when processes were beeing killed.
Additional to that grab a reference to the last scheduled fence.(CVE-2022-49829)
In the Linux kernel, the following vulnerability has been resolved:
usb: cdns3: fix random warning message when driver load
Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dump_backtrace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4.179613] kmalloc_fix_flags+0x60/0x88 [ 4.183550] new_slab+0x334/0x370 [ 4.186878] slaballoc.part.108+0x4d4/0x748 [ 4.191419] slab_alloc.isra.109+0x30/0x78 [ 4.195702] kmem_cache_alloc+0x40c/0x420 [ 4.199725] dma_pool_alloc+0xac/0x1f8 [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0
pool_alloc_page(struct dma_pool pool, gfp_t mem_flags) { ... page = kmalloc(sizeof(page), mem_flags); page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... }
kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_DMA32 flags. kmall_fix_flags() report warning.
GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle DMA memory region correctly by pool->dev. GFP_DMA32 can be removed safely.(CVE-2022-50151)
In the Linux kernel, the following vulnerability has been resolved:
of: check previous kernel's ima-kexec-buffer against memory bounds
Presently ima_get_kexec_buffer() doesn't check if the previous kernel's ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with 'mem=X' arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below:
$ sudo kexec --initrd initrd vmlinux --append='mem=16G'
<snip> BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] <snip> NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 <a1240000> 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]---
Fix this issue by checking returned PFN range of previous kernel's ima-kexec-buffer with page_is_ram() to ensure correct memory bounds.(CVE-2022-50159)
In the Linux kernel, the following vulnerability has been resolved:
regulator: core: Use different devices for resource allocation and DT lookup
Following by the below discussion, there's the potential UAF issue between regulator and mfd. https://lore.kernel.org/all/(CVE-2022-50616)
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: do not run mt76u_status_worker if the device is not running
Fix the following NULL pointer dereference avoiding to run mt76u_status_worker thread if the device is not running yet.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: mt76 mt76u_tx_status_data RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: mt76x02_send_tx_status+0x1d2/0xeb0 mt76x02_tx_status_data+0x8e/0xd0 mt76u_tx_status_data+0xe1/0x240 process_one_work+0x92b/0x1460 worker_thread+0x95/0xe00 kthread+0x3a1/0x480 ret_from_fork+0x1f/0x30 Modules linked in: --[ end trace 8df5d20fc5040f65 ]-- RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0 Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7 RSP: 0018:ffffc900005af988 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a RBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c R10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8 R13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28 FS: 0000000000000000(0000) GS:ffff88811aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0 PKRU: 55555554
Moreover move stat_work schedule out of the for loop.(CVE-2022-50735)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: allow exp not to be removed in nf_ct_find_expectation
Currently nf_conntrack_in() calling nf_ct_find_expectation() will remove the exp from the hash table. However, in some scenario, we expect the exp not to be removed when the created ct will not be confirmed, like in OVS and TC conntrack in the following patches.
This patch allows exp not to be removed by setting IPS_CONFIRMED in the status of the tmpl.(CVE-2023-52927)
In the Linux kernel, the following vulnerability has been resolved:
firmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle
KASAN reported a null-ptr-deref error:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 1373 Comm: modprobe Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:dmi_sysfs_entry_release ... Call Trace: <TASK> kobject_put dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs dmi_decode_table (drivers/firmware/dmi_scan.c:133) dmi_walk (drivers/firmware/dmi_scan.c:1115) dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs do_one_initcall (init/main.c:1296) ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x4000000 from 0xffffffff81000000 ---[ end Kernel panic - not syncing: Fatal exception ]---
It is because previous patch added kobject_put() to release the memory which will call dmi_sysfs_entry_release() and list_del().
However, list_add_tail(entry->list) is called after the error block, so the list_head is uninitialized and cannot be deleted.
Move error handling to after list_add_tail to fix this.(CVE-2023-53250)
In the Linux kernel, the following vulnerability has been resolved:
cacheinfo: Fix shared_cpu_map to handle shared caches at different levels
The cacheinfo sets up the shared_cpu_map by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched shared_cpu_map when the shared cache does not have the same index between CPUs.
CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3
This patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)
In the Linux kernel, the following vulnerability has been resolved:
scsi: ses: Fix slab-out-of-bounds in ses_intf_remove()
A fix for:
BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses] Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013
When edev->components is zero, accessing edev->component[0] members is wrong.(CVE-2023-53521)
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix resource leak in device_add()
When calling kobject_add() failed in device_add(), it will call cleanup_glue_dir() to free resource. But in kobject_add(), dev->kobj.parent has been set to NULL. This will cause resource leak.
The process is as follows: device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto //"Error" label ... cleanup_glue_dir() //becaues glue_dir is NULL, not call //kobject_put()
The preceding problem may cause insmod mac80211_hwsim.ko to failed. sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim' Call Trace: <TASK> dump_stack_lvl+0x8e/0xd1 sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x224/0x280 kobject_add_internal+0x2aa/0x880 kobject_add+0x135/0x1a0 get_device_parent+0x3d7/0x590 device_add+0x2aa/0x1cb0 device_create_groups_vargs+0x1eb/0x260 device_create+0xdc/0x110 mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim] init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim] do_one_initcall+0x10f/0x630 do_init_module+0x19f/0x5e0 load_module+0x64b7/0x6eb0 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try to register things with the same name in the same directory.(CVE-2023-53594)
In the Linux kernel, the following vulnerability has been resolved:
ARM: 9317/1: kexec: Make smp stop calls asynchronous
If a panic is triggered by a hrtimer interrupt all online cpus will be notified and set offline. But as highlighted by commit 19dbdcb8039c ("smp: Warn on function calls from softirq context") this call should not be made synchronous with disabled interrupts:
softdog: Initiating panic Kernel panic - not syncing: Software Watchdog Timer expired WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond unwind_backtrace: show_stack dump_stack_lvl __warn warn_slowpath_fmt smp_call_function_many_cond smp_call_function crash_smp_send_stop.part.0 machine_crash_shutdown __crash_kexec panic softdog_fire __hrtimer_run_queues hrtimer_interrupt
Make the smp call for machine_crash_nonpanic_core() asynchronous.(CVE-2023-53712)
In the Linux kernel, the following vulnerability has been resolved:
usb: early: xhci-dbc: Fix a potential out-of-bound memory access
If xdbc_bulk_write() fails, the values in 'buf' can be anything. So the string is not guaranteed to be NULL terminated when xdbc_trace() is called.
Reserve an extra byte, which will be zeroed automatically because 'buf' is a static variable, in order to avoid troubles, should it happen.(CVE-2023-53840)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxt_re: Prevent handling any completions after qp destroy
HW may generate completions that indicates QP is destroyed. Driver should not be scheduling any more completion handlers for this QP, after the QP is destroyed. Since CQs are active during the QP destroy, driver may still schedule completion handlers. This can cause a race where the destroy_cq and poll_cq running simultaneously.
Snippet of kernel panic while doing bnxt_re driver load unload in loop. This indicates a poll after the CQ is freed.
[77786.481636] Call Trace: [77786.481640] <TASK> [77786.481644] bnxt_re_poll_cq+0x14a/0x620 [bnxt_re] [77786.481658] ? kvm_clock_read+0x14/0x30 [77786.481693] __ib_process_cq+0x57/0x190 [ib_core] [77786.481728] ib_cq_poll_work+0x26/0x80 [ib_core] [77786.481761] process_one_work+0x1e5/0x3f0 [77786.481768] worker_thread+0x50/0x3a0 [77786.481785] ? __pfx_worker_thread+0x10/0x10 [77786.481790] kthread+0xe2/0x110 [77786.481794] ? __pfx_kthread+0x10/0x10 [77786.481797] ret_from_fork+0x2c/0x50
To avoid this, complete all completion handlers before returning the destroy QP. If free_cq is called soon after destroy_qp, IB stack will cancel the CQ work before invoking the destroy_cq verb and this will prevent any race mentioned.(CVE-2023-54048)
In the Linux kernel, the following vulnerability has been resolved:
bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log
It's trivial for user to trigger "verifier log line truncated" warning, as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at least two pieces of user-provided information that can be output through this buffer, and both can be arbitrarily sized by user: - BTF names; - BTF.ext source code lines strings.
Verifier log buffer should be properly sized for typical verifier state output. But it's sort-of expected that this buffer won't be long enough in some circumstances. So let's drop the check. In any case code will work correctly, at worst truncating a part of a single line output.(CVE-2023-54145)
In the Linux kernel, the following vulnerability has been resolved:
driver core: fix potential null-ptr-deref in device_add()
I got the following null-ptr-deref report while doing fault injection test:
BUG: kernel NULL pointer dereference, address: 0000000000000058 CPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+ RIP: 0010:klist_put+0x2d/0xd0 Call Trace: <TASK> klist_remove+0xf1/0x1c0 device_release_driver_internal+0x196/0x210 bus_remove_device+0x1bd/0x240 device_add+0xd3d/0x1100 w1_add_master_device+0x476/0x490 [wire] ds2482_probe+0x303/0x3e0 [ds2482]
This is how it happened:
w1_alloc_dev() // The dev->driver is set to w1_master_driver. memcpy(&dev->dev, device, sizeof(struct device)); device_add() bus_add_device() dpm_sysfs_add() // It fails, calls bus_remove_device.
// error path
bus_remove_device()
// The dev->driver is not null, but driver is not bound.
__device_release_driver()
klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref.
// normal path
bus_probe_device() // It's not called yet.
device_bind_driver()
If dev->driver is set, in the error path after calling bus_add_device() in device_add(), bus_remove_device() is called, then the device will be detached from driver. But device_bind_driver() is not called yet, so it causes null-ptr-deref while access the 'knode_driver'. To fix this, set dev->driver to null in the error path before calling bus_remove_device().(CVE-2023-54321)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free of signing key
Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race:
task A task B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() UAF
Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING.(CVE-2024-53179)
In the Linux kernel, the following vulnerability has been resolved:
ice: fix memory leak in aRFS after reset
Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling
However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature:
[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340 [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice] [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice] [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice] [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0 [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20 [<ffffffff98f0b6d9>] process_one_work+0x179/0x390 [<ffffffff98f0c1e9>] worker_thread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50 [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30 ...(CVE-2025-21981)
In the Linux kernel, the following vulnerability has been resolved:
watch_queue: fix pipe accounting mismatch
Currently, watch_queue_set_size() modifies the pipe buffers charged to user->pipe_bufs without updating the pipe->nr_accounted on the pipe itself, due to the if (!pipe_has_watch_queue()) test in pipe_resize_ring(). This means that when the pipe is ultimately freed, we decrement user->pipe_bufs by something other than what than we had charged to it, potentially leading to an underflow. This in turn can cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.
To remedy this, explicitly account for the pipe usage in watch_queue_set_size() to match the number set via account_pipe_buffers()
(It's unclear why watch_queue_set_size() does not update nr_accounted; it may be due to intentional overprovisioning in watch_queue_set_size()?)(CVE-2025-23138)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Prevent division by zero
The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37766)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Prevent division by zero
The user can set any speed value. If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37770)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: prevent out-of-bounds stream writes by validating *pos
ksmbd_vfs_stream_write() did not validate whether the write offset (pos) was within the bounds of the existing stream data length (v_len). If pos was greater than or equal to v_len, this could lead to an out-of-bounds memory write.
This patch adds a check to ensure *pos is less than v_len before proceeding. If the condition fails, -EINVAL is returned.(CVE-2025-37947)
In the Linux kernel, the following vulnerability has been resolved:
crypto: lzo - Fix compression buffer overrun
Unlike the decompression code, the compression code in LZO never checked for output overruns. It instead assumes that the caller always provides enough buffer space, disregarding the buffer length provided by the caller.
Add a safe compression interface that checks for the end of buffer before each write. Use the safe interface in crypto/lzo.(CVE-2025-38068)
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Avoid using sk_socket after free when sending
The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected.
Race conditions: ''' CPU0 CPU1
backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''
The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } '''
Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.
With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.
If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync().
In summary, we require synchronization to coordinate the backlog thread and close() thread.
The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''(CVE-2025-38154)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix use-after-free in vhci_flush()
syzbot reported use-after-free in vhci_flush() without repro. [0]
From the splat, a thread close()d a vhci file descriptor while its device was being used by iotcl() on another thread.
Once the last fd refcnt is released, vhci_release() calls hci_unregister_dev(), hci_free_dev(), and kfree() for struct vhci_data, which is set to hci_dev->dev->driver_data.
The problem is that there is no synchronisation after unlinking hdev from hci_dev_list in hci_unregister_dev(). There might be another thread still accessing the hdev which was fetched before the unlink operation.
We can use SRCU for such synchronisation.
Let's run hci_dev_reset() under SRCU and wait for its completion in hci_unregister_dev().
Another option would be to restore hci_dev->destruct(), which was removed in commit 587ae086f6e4 ("Bluetooth: Remove unused hci-destruct cb"). However, this would not be a good solution, as we should not run hci_unregister_dev() while there are in-flight ioctl() requests, which could lead to another data-race KCSAN splat.
Note that other drivers seem to have the same problem, for exmaple, virtbt_remove().
[0]: BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718
CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fcf5b98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929 RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009 RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 </TASK>
Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name ---truncated---(CVE-2025-38250)
In the Linux kernel, the following vulnerability has been resolved:
comedi: Fix use of uninitialized data in insn_rw_emulate_bits()
For Comedi INSN_READ and INSN_WRITE instructions on "digital"
subdevices (subdevice types COMEDI_SUBD_DI, COMEDI_SUBD_DO, and
COMEDI_SUBD_DIO), it is common for the subdevice driver not to have
insn_read and insn_write handler functions, but to have an
insn_bits handler function for handling Comedi INSN_BITS
instructions. In that case, the subdevice's insn_read and/or
insn_write function handler pointers are set to point to the
insn_rw_emulate_bits() function by __comedi_device_postconfig().
For INSN_WRITE, insn_rw_emulate_bits() currently assumes that the
supplied data[0] value is a valid copy from user memory. It will at
least exist because do_insnlist_ioctl() and do_insn_ioctl() in
"comedi_fops.c" ensure at lease MIN_SAMPLES (16) elements are
allocated. However, if insn->n is 0 (which is allowable for
INSN_READ and INSN_WRITE instructions, then data[0] may contain
uninitialized data, and certainly contains invalid data, possibly from a
different instruction in the array of instructions handled by
do_insnlist_ioctl(). This will result in an incorrect value being
written to the digital output channel (or to the digital input/output
channel if configured as an output), and may be reflected in the
internal saved state of the channel.
Fix it by returning 0 early if insn->n is 0, before reaching the code
that accesses data[0]. Previously, the function always returned 1 on
success, but it is supposed to be the number of data samples actually
read or written up to insn->n, which is 0 in this case.(CVE-2025-38480)
In the Linux kernel, the following vulnerability has been resolved:
HID: core: Harden s32ton() against conversion to 0 bits
Testing by the syzbot fuzzer showed that the HID core gets a shift-out-of-bounds exception when it tries to convert a 32-bit quantity to a 0-bit quantity. Ideally this should never occur, but there are buggy devices and some might have a report field with size set to zero; we shouldn't reject the report or the device just because of that.
Instead, harden the s32ton() routine so that it returns a reasonable result instead of crashing when it is called with the number of bits set to 0 -- the same as what snto32() does.(CVE-2025-38556)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: reject malicious packets in ipv6_gso_segment()
syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header.
This 16bit field has a limited range.
Add skb_reset_transport_header_careful() helper and use it from ipv6_gso_segment()
WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151 Call Trace: <TASK> skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110 skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53 __skb_gso_segment+0x342/0x510 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950 validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000 sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329 __dev_xmit_skb net/core/dev.c:4102 [inline] __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)
In the Linux kernel, the following vulnerability has been resolved:
pptp: ensure minimal skb length in pptp_xmit()
Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on ppp_sync_txmung") fixed ppp_sync_txmunge()
We need a similar fix in pptp_xmit(), otherwise we might read uninit data as reported by syzbot.
BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 _syssendmsg+0x893/0xd80 net/socket.c:2566 _sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)
In the Linux kernel, the following vulnerability has been resolved:
vsock: Do not allow binding to VMADDR_PORT_ANY
It is possible for a vsock to autobind to VMADDR_PORT_ANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDR_PORT_ANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction).
Modify the check in __vsock_bind_connectible() to also prevent binding to VMADDR_PORT_ANY.(CVE-2025-38618)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Avoid stack buffer overflow from kernel cmdline
While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix for slab out of bounds on mount to ksmbd
With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parse_server_interfaces() (see below):
BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827
CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 cifs
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla4xxx: Prevent a potential error pointer dereference
The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error, but qla4xxx_ep_connect() returns error pointers. Propagating the error pointers will lead to an Oops in the caller, so change the error pointers to NULL.(CVE-2025-39676)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: Fix MAC comparison to be constant-time
To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.(CVE-2025-39702)
In the Linux kernel, the following vulnerability has been resolved:
rcu: Fix rcu_read_unlock() deadloop due to IRQ work
During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.
This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.
irq_exit() __irq_exit_rcu() / in_hardirq() returns false after this / preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() / a bpf prog is hooked on this trace point / __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() / will send a IPI to itself / irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);
A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch:
static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +
neeraj: Apply Frederic's suggested fix for PREEMPT_RT
In the Linux kernel, the following vulnerability has been resolved:
rcu: Protect ->defer_qs_iw_pending from data race
On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.
In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.
The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat:
BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special
read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30
no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0
The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field.
This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: Duplicate SPI Handling
The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses.
This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops.
According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol.
Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable.
Current implementation: xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI
Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.(CVE-2025-39797)
In the Linux kernel, the following vulnerability has been resolved:
atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().
syzbot reported the splat below. [0]
When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.
The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.
The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.
struct atmtcp_control { struct atmtcp_hdr hdr; / must be first / ... atm_kptr_t vcc; / both directions / ... } __ATM_API_ALIGN;
typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;
The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().
atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:
- .ndo_start_xmit() (vcc->send() == atm_send_aal0())
- vcc_sendmsg()
The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.
Let's add a new ->pre_send() hook to validate messages from sendmsg().
[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 _syssendmsg+0x505/0x830 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> Modules linked in:(CVE-2025-39828)
In the Linux kernel, the following vulnerability has been resolved:
i40e: Fix potential invalid access when MAC list is empty
list_first_entry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.
Fix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()
syzbot reported the splat below without a repro.
In the splat, a single thread calling bt_accept_dequeue() freed sk and touched it after that.
The root cause would be the racy l2cap_sock_cleanup_listen() call added by the cited commit.
bt_accept_dequeue() is called under lock_sock() except for l2cap_sock_release().
Two threads could see the same socket during the list iteration in bt_accept_dequeue():
CPU1 CPU2 (close()) ---- ---- sock_hold(sk) sock_hold(sk); lock_sock(sk) <-- block close() sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- refcnt by bt_accept_enqueue() release_sock(sk) lock_sock(sk) sock_put(sk) bt_accept_unlink(sk) sock_put(sk) <-- last refcnt bt_accept_unlink(sk) <-- UAF
Depending on the timing, the other thread could show up in the "Freed by task" part.
Let's call l2cap_sock_cleanup_listen() under lock_sock() in l2cap_sock_release().
[0]: BUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 Read of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995 CPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcd/0x630 mm/kasan/report.c:482 kasan_report+0xe0/0x110 mm/kasan/report.c:595 debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline] do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115 spin_lock_bh include/linux/spinlock.h:356 [inline] release_sock+0x21/0x220 net/core/sock.c:3746 bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312 l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451 l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425 __sock_release+0xb3/0x270 net/socket.c:649 sock_close+0x1c/0x30 net/socket.c:1439 __fput+0x3ff/0xb70 fs/file_table.c:468 task_work_run+0x14d/0x240 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2accf8ebe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4 RAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f R10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c R13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490 </TASK>
Allocated by task 5326: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4365 [inline] __kmalloc_nopro ---truncated---(CVE-2025-39860)
In the Linux kernel, the following vulnerability has been resolved:
tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.
syzbot reported the splat below. [0]
The repro does the following:
- Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)
- Attach the prog to a SOCKMAP
- Add a socket to the SOCKMAP
- Activate fault injection
- Send data less than cork_bytes
At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes().
Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN.
If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc().
Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork.
The "copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "copied" to 0.
[0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>(CVE-2025-39913)
In the Linux kernel, the following vulnerability has been resolved:
cnic: Fix use-after-free bugs in cnic_delete_task
The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task().
A typical race condition is illustrated below:
CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | / the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed.
This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug.(CVE-2025-39945)
In the Linux kernel, the following vulnerability has been resolved:
ipvs: Defer ip_vs_ftp unregister during netns cleanup
On the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp before connections with valid cp->app pointers are flushed, leading to a use-after-free.
Fix this by introducing a global exiting_module flag, set to true in
ip_vs_ftp_exit() before unregistering the pernet subsystem. In
__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns
cleanup (when exiting_module is false) and defer it to
__ip_vs_cleanup_batch(), which unregisters all apps after all connections
are flushed. If called during module exit, unregister ip_vs_ftp
immediately.(CVE-2025-40018)
In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't leak disconnected dentries on umount
When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: delete x->tunnel as we delete x
The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete.
We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state.
Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped.
A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked.(CVE-2025-40215)
In the Linux kernel, the following vulnerability has been resolved:
fs/proc: fix uaf in proc_readdir_de()
Pde is erased from subdir rbtree through rb_erase(), but not set the node to EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE() set the erased node to EMPTY, then pde_subdir_next() will return NULL to avoid uaf access.
We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:
1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;
2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;
3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.
CPU 0 | CPU 1
traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2 sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |
rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free in tipc_mon_reinit_self().
syzbot reported use-after-free of tipc_net(net)->monitors[] in tipc_mon_reinit_self(). [0]
The array is protected by RTNL, but tipc_mon_reinit_self() iterates over it without RTNL.
tipc_mon_reinit_self() is called from tipc_net_finalize(), which is always under RTNL except for tipc_net_finalize_work().
Let's hold RTNL in tipc_net_finalize_work().
[0]: BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989
CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)} Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Workqueue: events tipc_net_finalize_work Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 _syssendmsg+0x508/0x820 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/ ---truncated---(CVE-2025-40280)
In the Linux kernel, the following vulnerability has been resolved:
nvme-fc: use lock accessing port_state and rport state
nvme_fc_unregister_remote removes the remote port on a lport object at any point in time when there is no active association. This races with with the reconnect logic, because nvme_fc_create_association is not taking a lock to check the port_state and atomically increase the active count on the rport.(CVE-2025-40342)
In the Linux kernel, the following vulnerability has been resolved:
arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity() which causes the code to proceed with NULL clock pointers. The current logic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both valid pointers and NULL, leading to potential NULL pointer dereference in clk_get_rate().
Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns: "The error code within @ptr if it is an error pointer; 0 otherwise."
This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL pointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed) when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be called when of_clk_get() returns NULL.
Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid pointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup
Raw IP packets have no MAC header, leaving skb->mac_header uninitialized. This can trigger kernel panics on ARM64 when xfrm or other subsystems access the offset due to strict alignment checks.
Initialize the MAC header to prevent such crashes.
This can trigger kernel panics on ARM when running IPsec over the qmimux0 interface.
Example trace:
Internal error: Oops: 000000009600004f [#1] SMP
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1
Hardware name: LS1028A RDB Board (DT)
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xfrm_input+0xde8/0x1318
lr : xfrm_input+0x61c/0x1318
sp : ffff800080003b20
Call trace:
xfrm_input+0xde8/0x1318
xfrm6_rcv+0x38/0x44
xfrm6_esp_rcv+0x48/0xa8
ip6_protocol_deliver_rcu+0x94/0x4b0
ip6_input_finish+0x44/0x70
ip6_input+0x44/0xc0
ipv6_rcv+0x6c/0x114
__netif_receive_skb_one_core+0x5c/0x8c
__netif_receive_skb+0x18/0x60
process_backlog+0x78/0x17c
__napi_poll+0x38/0x180
net_rx_action+0x168/0x2f0(CVE-2025-68192)
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix potential use-after-free in have_mon_and_osd_map()
The wait loop in __ceph_open_session() can race with the client receiving a new monmap or osdmap shortly after the initial map is received. Both ceph_monc_handle_map() and handle_one_map() install a new map immediately after freeing the old one
kfree(monc->monmap);
monc->monmap = monmap;
ceph_osdmap_destroy(osdc->osdmap);
osdc->osdmap = newmap;
under client->monc.mutex and client->osdc.lock respectively, but because neither is taken in have_mon_and_osd_map() it's possible for client->monc.monmap->epoch and client->osdc.osdmap->epoch arms in
client->monc.monmap && client->monc.monmap->epoch &&
client->osdc.osdmap && client->osdc.osdmap->epoch;
condition to dereference an already freed map. This happens to be reproducible with generic/395 and generic/397 with KASAN enabled:
BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70
Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305
CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266
...
Call Trace:
<TASK>
have_mon_and_osd_map+0x56/0x70
ceph_open_session+0x182/0x290
ceph_get_tree+0x333/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Allocated by task 13305:
ceph_osdmap_alloc+0x16/0x130
ceph_osdc_init+0x27a/0x4c0
ceph_create_client+0x153/0x190
create_fs_client+0x50/0x2a0
ceph_get_tree+0xff/0x680
vfs_get_tree+0x49/0x180
do_new_mount+0x1a3/0x2d0
path_mount+0x6dd/0x730
do_mount+0x99/0xe0
__do_sys_mount+0x141/0x180
do_syscall_64+0x9f/0x100
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 9475:
kfree+0x212/0x290
handle_one_map+0x23c/0x3b0
ceph_osdc_handle_map+0x3c9/0x590
mon_dispatch+0x655/0x6f0
ceph_con_process_message+0xc3/0xe0
ceph_con_v1_try_read+0x614/0x760
ceph_con_workfn+0x2de/0x650
process_one_work+0x486/0x7c0
process_scheduled_works+0x73/0x90
worker_thread+0x1c8/0x2a0
kthread+0x2ec/0x300
ret_from_fork+0x24/0x40
ret_from_fork_asm+0x1a/0x30
Rewrite the wait loop to check the above condition directly with client->monc.mutex and client->osdc.lock taken as appropriate. While at it, improve the timeout handling (previously mount_timeout could be exceeded in case wait_event_interruptible_timeout() slept more than once) and access client->auth_err under client->monc.mutex to match how it's set in finish_auth().
monmap_show() and osdmap_show() now take the respective lock before accessing the map as well.(CVE-2025-68285)
In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()
rlen value is a user-controlled value, but dtv5100_i2c_msg() does not check the size of the rlen value. Therefore, if it is set to a value larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.
Therefore, we need to add proper range checking to prevent this vuln.(CVE-2025-68819)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cm: Fix leaking the multicast GID table reference
If the CM ID is destroyed while the CM event for multicast creating is still queued the cancel_work_sync() will prevent the work from running which also prevents destroying the ah_attr. This leaks a refcount and triggers a WARN:
GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886
Destroy the ah_attr after canceling the work, it is safe to call this twice.(CVE-2025-71084)
In the Linux kernel, the following vulnerability has been resolved:
team: fix check for port enabled in team_queue_override_port_prio_changed()
There has been a syzkaller bug reported recently with the following trace:
list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:59! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59 Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff RSP: 0018:ffffc9000d49f370 EFLAGS: 00010286 RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000 RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005 RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230 R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480 FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0 Call Trace: <TASK> __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] _syssendmsg+0xa98/0xc70 net/socket.c:2630 _sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
The problem is in this flow: 1) Port is enabled, queue_id != 0, in qom_list 2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list) 3) Port is disabled, queue_id != 0, not in any list 4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed already
To fix this, change the check in team_queue_override_port_prio_changed() so it returns early if port is not enabled.(CVE-2025-71091)
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf
A zero length gss_token results in pages == 0 and in_token->pages[0] is NULL. The code unconditionally evaluates page_address(in_token->pages[0]) for the initial memcpy, which can dereference NULL even when the copy length is 0. Guard the first memcpy so it only runs when length > 0.(CVE-2025-71120)
In the Linux kernel, the following vulnerability has been resolved:
nvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec
Commit efa56305908b ("nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length") added ttag bounds checking and data_offset validation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate whether the command's data structures (cmd->req.sg and cmd->iov) have been properly initialized before processing H2C_DATA PDUs.
The nvmet_tcp_build_pdu_iovec() function dereferences these pointers without NULL checks. This can be triggered by sending H2C_DATA PDU immediately after the ICREQ/ICRESP handshake, before sending a CONNECT command or NVMe write command.
Attack vectors that trigger NULL pointer dereferences: 1. H2C_DATA PDU sent before CONNECT → both pointers NULL 2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL 3. H2C_DATA PDU for uninitialized command slot → both pointers NULL
The fix validates both cmd->req.sg and cmd->iov before calling nvmet_tcp_build_pdu_iovec(). Both checks are required because: - Uninitialized commands: both NULL - READ commands: cmd->req.sg allocated, cmd->iov NULL - WRITE commands: both allocated(CVE-2026-22998)
In the Linux kernel, the following vulnerability has been resolved:
pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()
In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails, the function jumps to the out_scratch label without freeing the already allocated dsaddrs list, leading to a memory leak.
Fix this by jumping to the out_err_drain_dsaddrs label, which properly frees the dsaddrs list before cleaning up other resources.(CVE-2026-23038)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"perf-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-301.0.0.204.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-301.0.0.204.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"perf-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-301.0.0.204.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-301.0.0.204.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-301.0.0.204.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:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource(). And it s required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)\n\nIn the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below: (Thread 1) | (Thread 2) | _set_timer()rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ...We hold pmlmepriv-\u0026gt;lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv-\u0026gt;lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obtainthe needed lock. What`s more, we change spin_lock_bh() inrtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,spin_lock_bh() will also cause deadlock() in timer handler.(CVE-2022-49309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/scheduler: fix fence ref counting\n\nWe leaked dependency fences when processes were beeing killed.\n\nAdditional to that grab a reference to the last scheduled fence.(CVE-2022-49829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix random warning message when driver load\n\nWarning log:\n[ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code!\n[ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20\n[ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT)\n[ 4.163155] Call trace:\n[ 4.165600] dump_backtrace+0x0/0x1b0\n[ 4.169286] show_stack+0x18/0x68\n[ 4.172611] dump_stack_lvl+0x68/0x84\n[ 4.176286] dump_stack+0x18/0x34\n[ 4.179613] kmalloc_fix_flags+0x60/0x88\n[ 4.183550] new_slab+0x334/0x370\n[ 4.186878] ___slab_alloc.part.108+0x4d4/0x748\n[ 4.191419] __slab_alloc.isra.109+0x30/0x78\n[ 4.195702] kmem_cache_alloc+0x40c/0x420\n[ 4.199725] dma_pool_alloc+0xac/0x1f8\n[ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0\n\npool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)\n{\n\t...\n\tpage = kmalloc(sizeof(*page), mem_flags);\n\tpage-\u0026gt;vaddr = dma_alloc_coherent(pool-\u0026gt;dev, pool-\u0026gt;allocation,\n\t\t\t\t\t \u0026amp;page-\u0026gt;dma, mem_flags);\n\t...\n}\n\nkmalloc was called with mem_flags, which is passed down in\ncdns3_allocate_trb_pool() and have GFP_DMA32 flags.\nkmall_fix_flags() report warning.\n\nGFP_DMA32 is not useful at all. dma_alloc_coherent() will handle\nDMA memory region correctly by pool-\u0026gt;dev. GFP_DMA32 can be removed\nsafely.(CVE-2022-50151)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nof: check previous kernel\u0026apos;s ima-kexec-buffer against memory bounds\n\nPresently ima_get_kexec_buffer() doesn\u0026apos;t check if the previous kernel\u0026apos;s\nima-kexec-buffer lies outside the addressable memory range. This can result\nin a kernel panic if the new kernel is booted with \u0026apos;mem=X\u0026apos; arg and the\nima-kexec-buffer was allocated beyond that range by the previous kernel.\nThe panic is usually of the form below:\n\n$ sudo kexec --initrd initrd vmlinux --append=\u0026apos;mem=16G\u0026apos;\n\n\u0026lt;snip\u0026gt;\n BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000\n Faulting instruction address: 0xc000000000837974\n Oops: Kernel access of bad area, sig: 11 [#1]\n\u0026lt;snip\u0026gt;\n NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0\n LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160\n Call Trace:\n [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160\n [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108\n [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120\n [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0\n [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec\n [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0\n [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64\n Instruction dump:\n f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330\n 7c0802a6 fb610198 7c9b2378 f80101d0 \u0026lt;a1240000\u0026gt; 2c090001 40820614 e9240010\n ---[ end trace 0000000000000000 ]---\n\nFix this issue by checking returned PFN range of previous kernel\u0026apos;s\nima-kexec-buffer with page_is_ram() to ensure correct memory bounds.(CVE-2022-50159)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Use different devices for resource allocation and DT lookup\n\nFollowing by the below discussion, there\u0026apos;s the potential UAF issue\nbetween regulator and mfd.\nhttps://lore.kernel.org/all/(CVE-2022-50616)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: do not run mt76u_status_worker if the device is not running\n\nFix the following NULL pointer dereference avoiding to run\nmt76u_status_worker thread if the device is not running yet.\n\nKASAN: null-ptr-deref in range\n[0x0000000000000000-0x0000000000000007]\nCPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware\nname: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\nWorkqueue: mt76 mt76u_tx_status_data\nRIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0\nCode: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00\n48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 \u0026lt;0f\u0026gt;\nb6\n04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7\nRSP: 0018:ffffc900005af988 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a\nRBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c\nR10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8\nR13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28\nFS: 0000000000000000(0000) GS:ffff88811aa00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n mt76x02_send_tx_status+0x1d2/0xeb0\n mt76x02_tx_status_data+0x8e/0xd0\n mt76u_tx_status_data+0xe1/0x240\n process_one_work+0x92b/0x1460\n worker_thread+0x95/0xe00\n kthread+0x3a1/0x480\n ret_from_fork+0x1f/0x30\nModules linked in:\n--[ end trace 8df5d20fc5040f65 ]--\nRIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0\nCode: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00\n48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 \u0026lt;0f\u0026gt;\nb6\n04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7\nRSP: 0018:ffffc900005af988 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffffc900005afae8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff832fc661 RDI: ffffc900005afc2a\nRBP: ffffc900005afae0 R08: 0000000000000001 R09: fffff520000b5f3c\nR10: 0000000000000003 R11: fffff520000b5f3b R12: ffff88810b6132d8\nR13: 000000000000ffff R14: 0000000000000000 R15: ffffc900005afc28\nFS: 0000000000000000(0000) GS:ffff88811aa00000(0000)\nknlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa0eda6a000 CR3: 0000000118f17000 CR4: 0000000000750ef0\nPKRU: 55555554\n\nMoreover move stat_work schedule out of the for loop.(CVE-2022-50735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: allow exp not to be removed in nf_ct_find_expectation\n\nCurrently nf_conntrack_in() calling nf_ct_find_expectation() will\nremove the exp from the hash table. However, in some scenario, we\nexpect the exp not to be removed when the created ct will not be\nconfirmed, like in OVS and TC conntrack in the following patches.\n\nThis patch allows exp not to be removed by setting IPS_CONFIRMED\nin the status of the tmpl.(CVE-2023-52927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle\n\nKASAN reported a null-ptr-deref error:\n\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 1373 Comm: modprobe\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:dmi_sysfs_entry_release\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n kobject_put\n dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs\n dmi_decode_table (drivers/firmware/dmi_scan.c:133)\n dmi_walk (drivers/firmware/dmi_scan.c:1115)\n dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs\n do_one_initcall (init/main.c:1296)\n ...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x4000000 from 0xffffffff81000000\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nIt is because previous patch added kobject_put() to release the memory\nwhich will call dmi_sysfs_entry_release() and list_del().\n\nHowever, list_add_tail(entry-\u0026gt;list) is called after the error block,\nso the list_head is uninitialized and cannot be deleted.\n\nMove error handling to after list_add_tail to fix this.(CVE-2023-53250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncacheinfo: Fix shared_cpu_map to handle shared caches at different levels\n\nThe cacheinfo sets up the shared_cpu_map by checking whether the caches\nwith the same index are shared between CPUs. However, this will trigger\nslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.\nAnother problem is the mismatched shared_cpu_map when the shared cache does\nnot have the same index between CPUs.\n\nCPU0\tI\tD\tL3\nindex\t0\t1\t2\tx\n\t^\t^\t^\t^\nindex\t0\t1\t2\t3\nCPU1\tI\tD\tL2\tL3\n\nThis patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Fix slab-out-of-bounds in ses_intf_remove()\n\nA fix for:\n\nBUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]\nRead of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013\n\nWhen edev-\u0026gt;components is zero, accessing edev-\u0026gt;component[0] members is\nwrong.(CVE-2023-53521)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix resource leak in device_add()\n\nWhen calling kobject_add() failed in device_add(), it will call\ncleanup_glue_dir() to free resource. But in kobject_add(),\ndev-\u0026gt;kobj.parent has been set to NULL. This will cause resource leak.\n\nThe process is as follows:\ndevice_add()\n\tget_device_parent()\n\t\tclass_dir_create_and_add()\n\t\t\tkobject_add()\t\t//kobject_get()\n\t...\n\tdev-\u0026gt;kobj.parent = kobj;\n\t...\n\tkobject_add()\t\t//failed, but set dev-\u0026gt;kobj.parent = NULL\n\t...\n\tglue_dir = get_glue_dir(dev)\t//glue_dir = NULL, and goto\n\t\t\t\t\t//\u0026quot;Error\u0026quot; label\n\t...\n\tcleanup_glue_dir()\t//becaues glue_dir is NULL, not call\n\t\t\t\t//kobject_put()\n\nThe preceding problem may cause insmod mac80211_hwsim.ko to failed.\nsysfs: cannot create duplicate filename \u0026apos;/devices/virtual/mac80211_hwsim\u0026apos;\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x8e/0xd1\nsysfs_warn_dup.cold+0x1c/0x29\nsysfs_create_dir_ns+0x224/0x280\nkobject_add_internal+0x2aa/0x880\nkobject_add+0x135/0x1a0\nget_device_parent+0x3d7/0x590\ndevice_add+0x2aa/0x1cb0\ndevice_create_groups_vargs+0x1eb/0x260\ndevice_create+0xdc/0x110\nmac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]\ninit_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]\ndo_one_initcall+0x10f/0x630\ndo_init_module+0x19f/0x5e0\nload_module+0x64b7/0x6eb0\n__do_sys_finit_module+0x140/0x200\ndo_syscall_64+0x35/0x80\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\n\u0026lt;/TASK\u0026gt;\nkobject_add_internal failed for mac80211_hwsim with -EEXIST, don\u0026apos;t try to\nregister things with the same name in the same directory.(CVE-2023-53594)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nARM: 9317/1: kexec: Make smp stop calls asynchronous\n\nIf a panic is triggered by a hrtimer interrupt all online cpus will be\nnotified and set offline. But as highlighted by commit 19dbdcb8039c\n(\u0026quot;smp: Warn on function calls from softirq context\u0026quot;) this call should\nnot be made synchronous with disabled interrupts:\n\n softdog: Initiating panic\n Kernel panic - not syncing: Software Watchdog Timer expired\n WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond\n unwind_backtrace:\n show_stack\n dump_stack_lvl\n __warn\n warn_slowpath_fmt\n smp_call_function_many_cond\n smp_call_function\n crash_smp_send_stop.part.0\n machine_crash_shutdown\n __crash_kexec\n panic\n softdog_fire\n __hrtimer_run_queues\n hrtimer_interrupt\n\nMake the smp call for machine_crash_nonpanic_core() asynchronous.(CVE-2023-53712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: early: xhci-dbc: Fix a potential out-of-bound memory access\n\nIf xdbc_bulk_write() fails, the values in \u0026apos;buf\u0026apos; can be anything. So the\nstring is not guaranteed to be NULL terminated when xdbc_trace() is called.\n\nReserve an extra byte, which will be zeroed automatically because \u0026apos;buf\u0026apos; is\na static variable, in order to avoid troubles, should it happen.(CVE-2023-53840)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/bnxt_re: Prevent handling any completions after qp destroy\n\nHW may generate completions that indicates QP is destroyed.\nDriver should not be scheduling any more completion handlers\nfor this QP, after the QP is destroyed. Since CQs are active\nduring the QP destroy, driver may still schedule completion\nhandlers. This can cause a race where the destroy_cq and poll_cq\nrunning simultaneously.\n\nSnippet of kernel panic while doing bnxt_re driver load unload in loop.\nThis indicates a poll after the CQ is freed.\u00a0\n\n[77786.481636] Call Trace:\n[77786.481640] \u00a0\u0026lt;TASK\u0026gt;\n[77786.481644] \u00a0bnxt_re_poll_cq+0x14a/0x620 [bnxt_re]\n[77786.481658] \u00a0? kvm_clock_read+0x14/0x30\n[77786.481693] \u00a0__ib_process_cq+0x57/0x190 [ib_core]\n[77786.481728] \u00a0ib_cq_poll_work+0x26/0x80 [ib_core]\n[77786.481761] \u00a0process_one_work+0x1e5/0x3f0\n[77786.481768] \u00a0worker_thread+0x50/0x3a0\n[77786.481785] \u00a0? __pfx_worker_thread+0x10/0x10\n[77786.481790] \u00a0kthread+0xe2/0x110\n[77786.481794] \u00a0? __pfx_kthread+0x10/0x10\n[77786.481797] \u00a0ret_from_fork+0x2c/0x50\n\nTo avoid this, complete all completion handlers before returning the\ndestroy QP. If free_cq is called soon after destroy_qp, IB stack\nwill cancel the CQ work before invoking the destroy_cq verb and\nthis will prevent any race mentioned.(CVE-2023-54048)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: drop unnecessary user-triggerable WARN_ONCE in verifierl log\n\nIt\u0026apos;s trivial for user to trigger \u0026quot;verifier log line truncated\u0026quot; warning,\nas verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are at\nleast two pieces of user-provided information that can be output through\nthis buffer, and both can be arbitrarily sized by user:\n - BTF names;\n - BTF.ext source code lines strings.\n\nVerifier log buffer should be properly sized for typical verifier state\noutput. But it\u0026apos;s sort-of expected that this buffer won\u0026apos;t be long enough\nin some circumstances. So let\u0026apos;s drop the check. In any case code will\nwork correctly, at worst truncating a part of a single line output.(CVE-2023-54145)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential null-ptr-deref in device_add()\n\nI got the following null-ptr-deref report while doing fault injection test:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000058\nCPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G B W N 6.1.0-rc3+\nRIP: 0010:klist_put+0x2d/0xd0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n klist_remove+0xf1/0x1c0\n device_release_driver_internal+0x196/0x210\n bus_remove_device+0x1bd/0x240\n device_add+0xd3d/0x1100\n w1_add_master_device+0x476/0x490 [wire]\n ds2482_probe+0x303/0x3e0 [ds2482]\n\nThis is how it happened:\n\nw1_alloc_dev()\n // The dev-\u0026gt;driver is set to w1_master_driver.\n memcpy(\u0026amp;dev-\u0026gt;dev, device, sizeof(struct device));\n device_add()\n bus_add_device()\n dpm_sysfs_add() // It fails, calls bus_remove_device.\n\n // error path\n bus_remove_device()\n // The dev-\u0026gt;driver is not null, but driver is not bound.\n __device_release_driver()\n klist_remove(\u0026amp;dev-\u0026gt;p-\u0026gt;knode_driver) \u0026lt;-- It causes null-ptr-deref.\n\n // normal path\n bus_probe_device() // It\u0026apos;s not called yet.\n device_bind_driver()\n\nIf dev-\u0026gt;driver is set, in the error path after calling bus_add_device()\nin device_add(), bus_remove_device() is called, then the device will be\ndetached from driver. But device_bind_driver() is not called yet, so it\ncauses null-ptr-deref while access the \u0026apos;knode_driver\u0026apos;. To fix this, set\ndev-\u0026gt;driver to null in the error path before calling bus_remove_device().(CVE-2023-54321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free of signing key\n\nCustomers have reported use-after-free in @ses-\u0026gt;auth_key.response with\nSMB2.1 + sign mounts which occurs due to following race:\n\ntask A task B\ncifs_mount()\n dfs_mount_share()\n get_session()\n cifs_mount_get_session() cifs_send_recv()\n cifs_get_smb_ses() compound_send_recv()\n cifs_setup_session() smb2_setup_request()\n kfree_sensitive() smb2_calc_signature()\n crypto_shash_setkey() *UAF*\n\nFix this by ensuring that we have a valid @ses-\u0026gt;auth_key.response by\nchecking whether @ses-\u0026gt;ses_status is SES_GOOD or SES_EXITING with\n@ses-\u0026gt;ses_lock held. After commit 24a9799aa8ef (\u0026quot;smb: client: fix UAF\nin smb2_reconnect_server()\u0026quot;), we made sure to call -\u0026gt;logoff() only\nwhen @ses was known to be good (e.g. valid -\u0026gt;auth_key.response), so\nit\u0026apos;s safe to access signing key when @ses-\u0026gt;ses_status == SES_EXITING.(CVE-2024-53179)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: fix memory leak in aRFS after reset\n\nFix aRFS (accelerated Receive Flow Steering) structures memory leak by\nadding a checker to verify if aRFS memory is already allocated while\nconfiguring VSI. aRFS objects are allocated in two cases:\n- as part of VSI initialization (at probe), and\n- as part of reset handling\n\nHowever, VSI reconfiguration executed during reset involves memory\nallocation one more time, without prior releasing already allocated\nresources. This led to the memory leak with the following signature:\n\n[root@os-delivery ~]# cat /sys/kernel/debug/kmemleak\nunreferenced object 0xff3c1ca7252e6000 (size 8192):\n comm \u0026quot;kworker/0:0\u0026quot;, pid 8, jiffies 4296833052\n hex dump (first 32 bytes):\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n backtrace (crc 0):\n [\u0026lt;ffffffff991ec485\u0026gt;] __kmalloc_cache_noprof+0x275/0x340\n [\u0026lt;ffffffffc0a6e06a\u0026gt;] ice_init_arfs+0x3a/0xe0 [ice]\n [\u0026lt;ffffffffc09f1027\u0026gt;] ice_vsi_cfg_def+0x607/0x850 [ice]\n [\u0026lt;ffffffffc09f244b\u0026gt;] ice_vsi_setup+0x5b/0x130 [ice]\n [\u0026lt;ffffffffc09c2131\u0026gt;] ice_init+0x1c1/0x460 [ice]\n [\u0026lt;ffffffffc09c64af\u0026gt;] ice_probe+0x2af/0x520 [ice]\n [\u0026lt;ffffffff994fbcd3\u0026gt;] local_pci_probe+0x43/0xa0\n [\u0026lt;ffffffff98f07103\u0026gt;] work_for_cpu_fn+0x13/0x20\n [\u0026lt;ffffffff98f0b6d9\u0026gt;] process_one_work+0x179/0x390\n [\u0026lt;ffffffff98f0c1e9\u0026gt;] worker_thread+0x239/0x340\n [\u0026lt;ffffffff98f14abc\u0026gt;] kthread+0xcc/0x100\n [\u0026lt;ffffffff98e45a6d\u0026gt;] ret_from_fork+0x2d/0x50\n [\u0026lt;ffffffff98e083ba\u0026gt;] ret_from_fork_asm+0x1a/0x30\n ...(CVE-2025-21981)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: fix pipe accounting mismatch\n\nCurrently, watch_queue_set_size() modifies the pipe buffers charged to\nuser-\u0026gt;pipe_bufs without updating the pipe-\u0026gt;nr_accounted on the pipe\nitself, due to the if (!pipe_has_watch_queue()) test in\npipe_resize_ring(). This means that when the pipe is ultimately freed,\nwe decrement user-\u0026gt;pipe_bufs by something other than what than we had\ncharged to it, potentially leading to an underflow. This in turn can\ncause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.\n\nTo remedy this, explicitly account for the pipe usage in\nwatch_queue_set_size() to match the number set via account_pipe_buffers()\n\n(It\u0026apos;s unclear why watch_queue_set_size() does not update nr_accounted;\nit may be due to intentional overprovisioning in watch_queue_set_size()?)(CVE-2025-23138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37766)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Prevent division by zero\n\nThe user can set any speed value.\nIf speed is greater than UINT_MAX/8, division by zero is possible.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37770)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: prevent out-of-bounds stream writes by validating *pos\n\nksmbd_vfs_stream_write() did not validate whether the write offset\n(*pos) was within the bounds of the existing stream data length (v_len).\nIf *pos was greater than or equal to v_len, this could lead to an\nout-of-bounds memory write.\n\nThis patch adds a check to ensure *pos is less than v_len before\nproceeding. If the condition fails, -EINVAL is returned.(CVE-2025-37947)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: lzo - Fix compression buffer overrun\n\nUnlike the decompression code, the compression code in LZO never\nchecked for output overruns. It instead assumes that the caller\nalways provides enough buffer space, disregarding the buffer length\nprovided by the caller.\n\nAdd a safe compression interface that checks for the end of buffer\nbefore each write. Use the safe interface in crypto/lzo.(CVE-2025-38068)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk-\u0026gt;sk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n\u0026apos;\u0026apos;\u0026apos;\nCPU0 CPU1\n\nbacklog::skb_send_sock\n sendmsg_unlocked\n sock_sendmsg\n sock_sendmsg_nosec\n close(fd):\n ...\n ops-\u0026gt;release() -\u0026gt; sock_map_close()\n sk_socket-\u0026gt;ops = NULL\n free(socket)\n sock-\u0026gt;ops-\u0026gt;sendmsg\n ^\n panic here\n\u0026apos;\u0026apos;\u0026apos;\n\nThe ref of psock become 0 after sock_map_close() executed.\n\u0026apos;\u0026apos;\u0026apos;\nvoid sock_map_close()\n{\n ...\n if (likely(psock)) {\n ...\n // !! here we remove psock and the ref of psock become 0\n sock_map_remove_links(sk, psock)\n psock = sk_psock_get(sk);\n if (unlikely(!psock))\n goto no_psock; \u0026lt;=== Control jumps here via goto\n ...\n cancel_delayed_work_sync(\u0026amp;psock-\u0026gt;work); \u0026lt;=== not executed\n sk_psock_put(sk, psock);\n ...\n}\n\u0026apos;\u0026apos;\u0026apos;\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn\u0026apos;t started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n\u0026apos;\u0026apos;\u0026apos;\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n\u0026apos;\u0026apos;\u0026apos;(CVE-2025-38154)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix use-after-free in vhci_flush()\n\nsyzbot reported use-after-free in vhci_flush() without repro. [0]\n\nFrom the splat, a thread close()d a vhci file descriptor while\nits device was being used by iotcl() on another thread.\n\nOnce the last fd refcnt is released, vhci_release() calls\nhci_unregister_dev(), hci_free_dev(), and kfree() for struct\nvhci_data, which is set to hci_dev-\u0026gt;dev-\u0026gt;driver_data.\n\nThe problem is that there is no synchronisation after unlinking\nhdev from hci_dev_list in hci_unregister_dev(). There might be\nanother thread still accessing the hdev which was fetched before\nthe unlink operation.\n\nWe can use SRCU for such synchronisation.\n\nLet\u0026apos;s run hci_dev_reset() under SRCU and wait for its completion\nin hci_unregister_dev().\n\nAnother option would be to restore hci_dev-\u0026gt;destruct(), which was\nremoved in commit 587ae086f6e4 (\u0026quot;Bluetooth: Remove unused\nhci-destruct cb\u0026quot;). However, this would not be a good solution, as\nwe should not run hci_unregister_dev() while there are in-flight\nioctl() requests, which could lead to another data-race KCSAN splat.\n\nNote that other drivers seem to have the same problem, for exmaple,\nvirtbt_remove().\n\n[0]:\nBUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]\nBUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937\nRead of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718\n\nCPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #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_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xd2/0x2b0 mm/kasan/report.c:521\n kasan_report+0x118/0x150 mm/kasan/report.c:634\n skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]\n skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937\n skb_queue_purge include/linux/skbuff.h:3368 [inline]\n vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69\n hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline]\n hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592\n sock_do_ioctl+0xd9/0x300 net/socket.c:1190\n sock_ioctl+0x576/0x790 net/socket.c:1311\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fcf5b98e929\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929\nRDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009\nRBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 6535:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635\n misc_open+0x2bc/0x330 drivers/char/misc.c:161\n chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414\n do_dentry_open+0xdf0/0x1970 fs/open.c:964\n vfs_open+0x3b/0x340 fs/open.c:1094\n do_open fs/namei.c:3887 [inline]\n path_openat+0x2ee5/0x3830 fs/name\n---truncated---(CVE-2025-38250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: Fix use of uninitialized data in insn_rw_emulate_bits()\n\nFor Comedi `INSN_READ` and `INSN_WRITE` instructions on \u0026quot;digital\u0026quot;\nsubdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and\n`COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have\n`insn_read` and `insn_write` handler functions, but to have an\n`insn_bits` handler function for handling Comedi `INSN_BITS`\ninstructions. In that case, the subdevice\u0026apos;s `insn_read` and/or\n`insn_write` function handler pointers are set to point to the\n`insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.\n\nFor `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that the\nsupplied `data[0]` value is a valid copy from user memory. It will at\nleast exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in\n\u0026quot;comedi_fops.c\u0026quot; ensure at lease `MIN_SAMPLES` (16) elements are\nallocated. However, if `insn-\u0026gt;n` is 0 (which is allowable for\n`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may contain\nuninitialized data, and certainly contains invalid data, possibly from a\ndifferent instruction in the array of instructions handled by\n`do_insnlist_ioctl()`. This will result in an incorrect value being\nwritten to the digital output channel (or to the digital input/output\nchannel if configured as an output), and may be reflected in the\ninternal saved state of the channel.\n\nFix it by returning 0 early if `insn-\u0026gt;n` is 0, before reaching the code\nthat accesses `data[0]`. Previously, the function always returned 1 on\nsuccess, but it is supposed to be the number of data samples actually\nread or written up to `insn-\u0026gt;n`, which is 0 in this case.(CVE-2025-38480)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: Harden s32ton() against conversion to 0 bits\n\nTesting by the syzbot fuzzer showed that the HID core gets a\nshift-out-of-bounds exception when it tries to convert a 32-bit\nquantity to a 0-bit quantity. Ideally this should never occur, but\nthere are buggy devices and some might have a report field with size\nset to zero; we shouldn\u0026apos;t reject the report or the device just because\nof that.\n\nInstead, harden the s32ton() routine so that it returns a reasonable\nresult instead of crashing when it is called with the number of bits\nset to 0 -- the same as what snto32() does.(CVE-2025-38556)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: reject malicious packets in ipv6_gso_segment()\n\nsyzbot was able to craft a packet with very long IPv6 extension headers\nleading to an overflow of skb-\u0026gt;transport_header.\n\nThis 16bit field has a limited range.\n\nAdd skb_reset_transport_header_careful() helper and use it\nfrom ipv6_gso_segment()\n\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\nWARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nModules linked in:\nCPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\n RIP: 0010:skb_reset_transport_header include/linux/skbuff.h:3032 [inline]\n RIP: 0010:ipv6_gso_segment+0x15e2/0x21e0 net/ipv6/ip6_offload.c:151\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n nsh_gso_segment+0x54a/0xe10 net/nsh/nsh.c:110\n skb_mac_gso_segment+0x31c/0x640 net/core/gso.c:53\n __skb_gso_segment+0x342/0x510 net/core/gso.c:124\n skb_gso_segment include/net/gso.h:83 [inline]\n validate_xmit_skb+0x857/0x11b0 net/core/dev.c:3950\n validate_xmit_skb_list+0x84/0x120 net/core/dev.c:4000\n sch_direct_xmit+0xd3/0x4b0 net/sched/sch_generic.c:329\n __dev_xmit_skb net/core/dev.c:4102 [inline]\n __dev_queue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npptp: ensure minimal skb length in pptp_xmit()\n\nCommit aabc6596ffb3 (\u0026quot;net: ppp: Add bound checking for skb data\non ppp_sync_txmung\u0026quot;) fixed ppp_sync_txmunge()\n\nWe need a similar fix in pptp_xmit(), otherwise we might\nread uninit data as reported by syzbot.\n\nBUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193\n ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline]\n ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314\n pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379\n sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n __release_sock+0x1d3/0x330 net/core/sock.c:3213\n release_sock+0x6b/0x270 net/core/sock.c:3767\n pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x330/0x3d0 net/socket.c:727\n ____sys_sendmsg+0x893/0xd80 net/socket.c:2566\n ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620\n __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709(CVE-2025-38574)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Do not allow binding to VMADDR_PORT_ANY\n\nIt is possible for a vsock to autobind to VMADDR_PORT_ANY. This can\ncause a use-after-free when a connection is made to the bound socket.\nThe socket returned by accept() also has port VMADDR_PORT_ANY but is not\non the list of unbound sockets. Binding it will result in an extra\nrefcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep\nthe binding until socket destruction).\n\nModify the check in __vsock_bind_connectible() to also prevent binding\nto VMADDR_PORT_ANY.(CVE-2025-38618)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Avoid stack buffer overflow from kernel cmdline\n\nWhile the kernel command line is considered trusted in most environments,\navoid writing 1 byte past the end of \u0026quot;acpiid\u0026quot; if the \u0026quot;str\u0026quot; argument is\nmaximum length.(CVE-2025-38676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix for slab out of bounds on mount to ksmbd\n\nWith KASAN enabled, it is possible to get a slab out of bounds\nduring mount to ksmbd due to missing check in parse_server_interfaces()\n(see below):\n\n BUG: KASAN: slab-out-of-bounds in\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n Read of size 4 at addr ffff8881433dba98 by task mount/9827\n\n CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G\n OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary)\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: Dell Inc. Precision Tower 3620/0MWYPT,\n BIOS 2.13.1 06/14/2019\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x9f/0xf0\n print_report+0xd1/0x670\n __virt_addr_valid+0x22c/0x430\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? kasan_complete_mode_report_info+0x2a/0x1f0\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n kasan_report+0xd6/0x110\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n __asan_report_load_n_noabort+0x13/0x20\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? __pfx_parse_server_interfaces+0x10/0x10 [cifs]\n ? trace_hardirqs_on+0x51/0x60\n SMB3_request_interfaces+0x1ad/0x3f0 [cifs]\n ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs]\n ? SMB2_tcon+0x23c/0x15d0 [cifs]\n smb3_qfs_tcon+0x173/0x2b0 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n cifs_mount_get_tcon+0x369/0xb90 [cifs]\n ? dfs_cache_find+0xe7/0x150 [cifs]\n dfs_mount_share+0x985/0x2970 [cifs]\n ? check_path.constprop.0+0x28/0x50\n ? save_trace+0x54/0x370\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? __lock_acquire+0xb82/0x2ba0\n ? __kasan_check_write+0x18/0x20\n cifs_mount+0xbc/0x9e0 [cifs]\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_setup_cifs_sb+0x29d/0x810 [cifs]\n cifs_smb3_do_mount+0x263/0x1990 [cifs](CVE-2025-38728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla4xxx: Prevent a potential error pointer dereference\n\nThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,\nbut qla4xxx_ep_connect() returns error pointers. Propagating the error\npointers will lead to an Oops in the caller, so change the error pointers\nto NULL.(CVE-2025-39676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sr: Fix MAC comparison to be constant-time\n\nTo prevent timing attacks, MACs need to be compared in constant time.\nUse the appropriate helper function for this.(CVE-2025-39702)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Fix rcu_read_unlock() deadloop due to IRQ work\n\nDuring rcu_read_unlock_special(), if this happens during irq_exit(), we\ncan lockup if an IPI is issued. This is because the IPI itself triggers\nthe irq_exit() path causing a recursive lock up.\n\nThis is precisely what Xiongfeng found when invoking a BPF program on\nthe trace_tick_stop() tracepoint As shown in the trace below. Fix by\nmanaging the irq_work state correctly.\n\nirq_exit()\n __irq_exit_rcu()\n /* in_hardirq() returns false after this */\n preempt_count_sub(HARDIRQ_OFFSET)\n tick_irq_exit()\n tick_nohz_irq_exit()\n\t tick_nohz_stop_sched_tick()\n\t trace_tick_stop() /* a bpf prog is hooked on this trace point */\n\t\t __bpf_trace_tick_stop()\n\t\t bpf_trace_run2()\n\t\t\t rcu_read_unlock_special()\n /* will send a IPI to itself */\n\t\t\t irq_work_queue_on(\u0026amp;rdp-\u0026gt;defer_qs_iw, rdp-\u0026gt;cpu);\n\nA simple reproducer can also be obtained by doing the following in\ntick_irq_exit(). It will hang on boot without the patch:\n\n static inline void tick_irq_exit(void)\n {\n +\trcu_read_lock();\n +\tWRITE_ONCE(current-\u0026gt;rcu_read_unlock_special.b.need_qs, true);\n +\trcu_read_unlock();\n +\n\n[neeraj: Apply Frederic\u0026apos;s suggested fix for PREEMPT_RT](CVE-2025-39744)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect -\u0026gt;defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won\u0026apos;t happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure\u0026apos;s -\u0026gt;defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special(). This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last enabled at (200272): [\u0026lt;ffffffffb0f56121\u0026gt;] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [\u0026lt;ffffffffb25c7859\u0026gt;] __schedule+0x129/0xd70\nsoftirqs last enabled at (0): [\u0026lt;ffffffffb0ee093f\u0026gt;] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special(). In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe -\u0026gt;defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the -\u0026gt;defer_qs_iw_pending\nfield. This suffices because this handler is not a fast path.(CVE-2025-39749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Duplicate SPI Handling\n\nThe issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI\nNetlink message, which triggers the kernel function xfrm_alloc_spi().\nThis function is expected to ensure uniqueness of the Security Parameter\nIndex (SPI) for inbound Security Associations (SAs). However, it can\nreturn success even when the requested SPI is already in use, leading\nto duplicate SPIs assigned to multiple inbound SAs, differentiated\nonly by their destination addresses.\n\nThis behavior causes inconsistencies during SPI lookups for inbound packets.\nSince the lookup may return an arbitrary SA among those with the same SPI,\npacket processing can fail, resulting in packet drops.\n\nAccording to RFC 4301 section 4.4.2 , for inbound processing a unicast SA\nis uniquely identified by the SPI and optionally protocol.\n\nReproducing the Issue Reliably:\nTo consistently reproduce the problem, restrict the available SPI range in\ncharon.conf : spi_min = 0x10000000 spi_max = 0x10000002\nThis limits the system to only 2 usable SPI values.\nNext, create more than 2 Child SA. each using unique pair of src/dst address.\nAs soon as the 3rd Child SA is initiated, it will be assigned a duplicate\nSPI, since the SPI pool is already exhausted.\nWith a narrow SPI range, the issue is consistently reproducible.\nWith a broader/default range, it becomes rare and unpredictable.\n\nCurrent implementation:\nxfrm_spi_hash() lookup function computes hash using daddr, proto, and family.\nSo if two SAs have the same SPI but different destination addresses, then\nthey will:\na. Hash into different buckets\nb. Be stored in different linked lists (byspi + h)\nc. Not be seen in the same hlist_for_each_entry_rcu() iteration.\nAs a result, the lookup will result in NULL and kernel allows that Duplicate SPI\n\nProposed Change:\nxfrm_state_lookup_spi_proto() does a truly global search - across all states,\nregardless of hash bucket and matches SPI and proto.(CVE-2025-39797)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().\n\nsyzbot reported the splat below. [0]\n\nWhen atmtcp_v_open() or atmtcp_v_close() is called via connect()\nor close(), atmtcp_send_control() is called to send an in-kernel\nspecial message.\n\nThe message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.\nAlso, a pointer of struct atm_vcc is set to atmtcp_control.vcc.\n\nThe notable thing is struct atmtcp_control is uAPI but has a\nspace for an in-kernel pointer.\n\n struct atmtcp_control {\n \tstruct atmtcp_hdr hdr;\t/* must be first */\n ...\n \tatm_kptr_t vcc;\t\t/* both directions */\n ...\n } __ATM_API_ALIGN;\n\n typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;\n\nThe special message is processed in atmtcp_recv_control() called\nfrom atmtcp_c_send().\n\natmtcp_c_send() is vcc-\u0026gt;dev-\u0026gt;ops-\u0026gt;send() and called from 2 paths:\n\n 1. .ndo_start_xmit() (vcc-\u0026gt;send() == atm_send_aal0())\n 2. vcc_sendmsg()\n\nThe problem is sendmsg() does not validate the message length and\nuserspace can abuse atmtcp_recv_control() to overwrite any kptr\nby atmtcp_control.\n\nLet\u0026apos;s add a new -\u0026gt;pre_send() hook to validate messages from sendmsg().\n\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI\nKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]\nCPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]\nRIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297\nCode: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c\nRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203\nRAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c\nRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd\nR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000\nR13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff\nFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n ____sys_sendmsg+0x505/0x830 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f8d7e96a4a9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9\nRDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005\nRBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f\nR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac\nR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250\n \u0026lt;/TASK\u0026gt;\nModules linked in:(CVE-2025-39828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix potential invalid access when MAC list is empty\n\nlist_first_entry() never returns NULL - if the list is empty, it still\nreturns a pointer to an invalid object, leading to potential invalid\nmemory access when dereferenced.\n\nFix this by using list_first_entry_or_null instead of list_first_entry.(CVE-2025-39853)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()\n\nsyzbot reported the splat below without a repro.\n\nIn the splat, a single thread calling bt_accept_dequeue() freed sk\nand touched it after that.\n\nThe root cause would be the racy l2cap_sock_cleanup_listen() call\nadded by the cited commit.\n\nbt_accept_dequeue() is called under lock_sock() except for\nl2cap_sock_release().\n\nTwo threads could see the same socket during the list iteration\nin bt_accept_dequeue():\n\n CPU1 CPU2 (close())\n ---- ----\n sock_hold(sk) sock_hold(sk);\n lock_sock(sk) \u0026lt;-- block close()\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- refcnt by bt_accept_enqueue()\n release_sock(sk)\n lock_sock(sk)\n sock_put(sk)\n bt_accept_unlink(sk)\n sock_put(sk) \u0026lt;-- last refcnt\n bt_accept_unlink(sk) \u0026lt;-- UAF\n\nDepending on the timing, the other thread could show up in the\n\u0026quot;Freed by task\u0026quot; part.\n\nLet\u0026apos;s call l2cap_sock_cleanup_listen() under lock_sock() in\nl2cap_sock_release().\n\n[0]:\nBUG: KASAN: slab-use-after-free in debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\nRead of size 4 at addr ffff88803b7eb1c4 by task syz.5.3276/16995\nCPU: 3 UID: 0 PID: 16995 Comm: syz.5.3276 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n debug_spin_lock_before kernel/locking/spinlock_debug.c:86 [inline]\n do_raw_spin_lock+0x26f/0x2b0 kernel/locking/spinlock_debug.c:115\n spin_lock_bh include/linux/spinlock.h:356 [inline]\n release_sock+0x21/0x220 net/core/sock.c:3746\n bt_accept_dequeue+0x505/0x600 net/bluetooth/af_bluetooth.c:312\n l2cap_sock_cleanup_listen+0x5c/0x2a0 net/bluetooth/l2cap_sock.c:1451\n l2cap_sock_release+0x5c/0x210 net/bluetooth/l2cap_sock.c:1425\n __sock_release+0xb3/0x270 net/socket.c:649\n sock_close+0x1c/0x30 net/socket.c:1439\n __fput+0x3ff/0xb70 fs/file_table.c:468\n task_work_run+0x14d/0x240 kernel/task_work.c:227\n resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n exit_to_user_mode_loop+0xeb/0x110 kernel/entry/common.c:43\n exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline]\n syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline]\n syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline]\n do_syscall_64+0x3f6/0x4c0 arch/x86/entry/syscall_64.c:100\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2accf8ebe9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffdb6cb1378 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4\nRAX: 0000000000000000 RBX: 00000000000426fb RCX: 00007f2accf8ebe9\nRDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003\nRBP: 00007f2acd1b7da0 R08: 0000000000000001 R09: 00000012b6cb166f\nR10: 0000001b30e20000 R11: 0000000000000246 R12: 00007f2acd1b609c\nR13: 00007f2acd1b6090 R14: ffffffffffffffff R15: 00007ffdb6cb1490\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5326:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4365 [inline]\n __kmalloc_nopro\n---truncated---(CVE-2025-39860)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-\u0026gt;cork.\n\nsyzbot reported the splat below. [0]\n\nThe repro does the following:\n\n 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)\n 2. Attach the prog to a SOCKMAP\n 3. Add a socket to the SOCKMAP\n 4. Activate fault injection\n 5. Send data less than cork_bytes\n\nAt 5., the data is carried over to the next sendmsg() as it is\nsmaller than the cork_bytes specified by bpf_msg_cork_bytes().\n\nThen, tcp_bpf_send_verdict() tries to allocate psock-\u0026gt;cork to hold\nthe data, but this fails silently due to fault injection + __GFP_NOWARN.\n\nIf the allocation fails, we need to revert the sk-\u0026gt;sk_forward_alloc\nchange done by sk_msg_alloc().\n\nLet\u0026apos;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate\npsock-\u0026gt;cork.\n\nThe \u0026quot;*copied\u0026quot; also needs to be updated such that a proper error can\nbe returned to the caller, sendmsg. It fails to allocate psock-\u0026gt;cork.\nNothing has been corked so far, so this patch simply sets \u0026quot;*copied\u0026quot;\nto 0.\n\n[0]:\nWARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983\nModules linked in:\nCPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156\nCode: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 \u0026lt;0f\u0026gt; 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc\nRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246\nRAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80\nRDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000\nRBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4\nR10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380\nR13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872\nFS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n __sk_destruct+0x86/0x660 net/core/sock.c:2339\n rcu_do_batch kernel/rcu/tree.c:2605 [inline]\n rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861\n handle_softirqs+0x286/0x870 kernel/softirq.c:579\n __do_softirq kernel/softirq.c:613 [inline]\n invoke_softirq kernel/softirq.c:453 [inline]\n __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:696\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]\n sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052\n \u0026lt;/IRQ\u0026gt;(CVE-2025-39913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncnic: Fix use-after-free bugs in cnic_delete_task\n\nThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),\nwhich does not guarantee that the delayed work item \u0026apos;delete_task\u0026apos; has\nfully completed if it was already running. Additionally, the delayed work\nitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only\nblocks and waits for work items that were already queued to the\nworkqueue prior to its invocation. Any work items submitted after\nflush_workqueue() is called are not included in the set of tasks that the\nflush operation awaits. This means that after the cyclic work items have\nfinished executing, a delayed work item may still exist in the workqueue.\nThis leads to use-after-free scenarios where the cnic_dev is deallocated\nby cnic_free_dev(), while delete_task remains active and attempt to\ndereference cnic_dev in cnic_delete_task().\n\nA typical race condition is illustrated below:\n\nCPU 0 (cleanup) | CPU 1 (delayed work callback)\ncnic_netdev_event() |\n cnic_stop_hw() | cnic_delete_task()\n cnic_cm_stop_bnx2x_hw() | ...\n cancel_delayed_work() | /* the queue_delayed_work()\n flush_workqueue() | executes after flush_workqueue()*/\n | queue_delayed_work()\n cnic_free_dev(dev)//free | cnic_delete_task() //new instance\n | dev = cp-\u0026gt;dev; //use\n\nReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensure\nthat the cyclic delayed work item is properly canceled and that any\nongoing execution of the work item completes before the cnic_dev is\ndeallocated. Furthermore, since cancel_delayed_work_sync() uses\n__flush_work(work, true) to synchronously wait for any currently\nexecuting instance of the work item to finish, the flush_workqueue()\nbecomes redundant and should be removed.\n\nThis bug was identified through static analysis. To reproduce the issue\nand validate the fix, I simulated the cnic PCI device in QEMU and\nintroduced intentional delays \u2014 such as inserting calls to ssleep()\nwithin the cnic_delete_task() function \u2014 to increase the likelihood\nof triggering the bug.(CVE-2025-39945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: Defer ip_vs_ftp unregister during netns cleanup\n\nOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftp\nbefore connections with valid cp-\u0026gt;app pointers are flushed, leading to a\nuse-after-free.\n\nFix this by introducing a global `exiting_module` flag, set to true in\nip_vs_ftp_exit() before unregistering the pernet subsystem. In\n__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netns\ncleanup (when exiting_module is false) and defer it to\n__ip_vs_cleanup_batch(), which unregisters all apps after all connections\nare flushed. If called during module exit, unregister ip_vs_ftp\nimmediately.(CVE-2025-40018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0026apos;t leak disconnected dentries on umount\n\nWhen user calls open_by_handle_at() on some inode that is not cached, we\nwill create disconnected dentry for it. If such dentry is a directory,\nexportfs_decode_fh_raw() will then try to connect this dentry to the\ndentry tree through reconnect_path(). It may happen for various reasons\n(such as corrupted fs or race with rename) that the call to\nlookup_one_unlocked() in reconnect_one() will fail to find the dentry we\nare trying to reconnect and instead create a new dentry under the\nparent. Now this dentry will not be marked as disconnected although the\nparent still may well be disconnected (at least in case this\ninconsistency happened because the fs is corrupted and .. doesn\u0026apos;t point\nto the real parent directory). This creates inconsistency in\ndisconnected flags but AFAICS it was mostly harmless. At least until\ncommit f1ee616214cb (\u0026quot;VFS: don\u0026apos;t keep disconnected dentries on d_anon\u0026quot;)\nwhich removed adding of most disconnected dentries to sb-\u0026gt;s_anon list.\nThus after this commit cleanup of disconnected dentries implicitely\nrelies on the fact that dput() will immediately reclaim such dentries.\nHowever when some leaf dentry isn\u0026apos;t marked as disconnected, as in the\nscenario described above, the reclaim doesn\u0026apos;t happen and the dentries\nare \u0026quot;leaked\u0026quot;. Memory reclaim can eventually reclaim them but otherwise\nthey stay in memory and if umount comes first, we hit infamous \u0026quot;Busy\ninodes after unmount\u0026quot; bug. Make sure all dentries created under a\ndisconnected parent are marked as disconnected as well.(CVE-2025-40105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: delete x-\u0026gt;tunnel as we delete x\n\nThe ipcomp fallback tunnels currently get deleted (from the various\nlists and hashtables) as the last user state that needed that fallback\nis destroyed (not deleted). If a reference to that user state still\nexists, the fallback state will remain on the hashtables/lists,\ntriggering the WARN in xfrm_state_fini. Because of those remaining\nreferences, the fix in commit f75a2804da39 (\u0026quot;xfrm: destroy xfrm_state\nsynchronously on net exit path\u0026quot;) is not complete.\n\nWe recently fixed one such situation in TCP due to defered freeing of\nskbs (commit 9b6412e6979f (\u0026quot;tcp: drop secpath at the same time as we\ncurrently drop dst\u0026quot;)). This can also happen due to IP reassembly: skbs\nwith a secpath remain on the reassembly queue until netns\ndestruction. If we can\u0026apos;t guarantee that the queues are flushed by the\ntime xfrm_state_fini runs, there may still be references to a (user)\nxfrm_state, preventing the timely deletion of the corresponding\nfallback state.\n\nInstead of chasing each instance of skbs holding a secpath one by one,\nthis patch fixes the issue directly within xfrm, by deleting the\nfallback state as soon as the last user state depending on it has been\ndeleted. Destruction will still happen when the final reference is\ndropped.\n\nA separate lockdep class for the fallback state is required since\nwe\u0026apos;re going to lock x-\u0026gt;tunnel while x is locked.(CVE-2025-40215)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/proc: fix uaf in proc_readdir_de()\n\nPde is erased from subdir rbtree through rb_erase(), but not set the node\nto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()\nset the erased node to EMPTY, then pde_subdir_next() will return NULL to\navoid uaf access.\n\nWe found an uaf issue while using stress-ng testing, need to run testcase\ngetdent and tun in the same time. The steps of the issue is as follows:\n\n1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current\n pde is tun3;\n\n2) in the [time windows] unregister netdevice tun3 and tun2, and erase\n them from rbtree. erase tun3 first, and then erase tun2. the\n pde(tun2) will be released to slab;\n\n3) continue to getdent process, then pde_subdir_next() will return\n pde(tun2) which is released, it will case uaf access.\n\nCPU 0 | CPU 1\n-------------------------------------------------------------------------\ntraverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun-\u0026gt;dev) //tun3 tun2\nsys_getdents64() |\n iterate_dir() |\n proc_readdir() |\n proc_readdir_de() | snmp6_unregister_dev()\n pde_get(de); | proc_remove()\n read_unlock(\u0026amp;proc_subdir_lock); | remove_proc_subtree()\n | write_lock(\u0026amp;proc_subdir_lock);\n [time window] | rb_erase(\u0026amp;root-\u0026gt;subdir_node, \u0026amp;parent-\u0026gt;subdir);\n | write_unlock(\u0026amp;proc_subdir_lock);\n read_lock(\u0026amp;proc_subdir_lock); |\n next = pde_subdir_next(de); |\n pde_put(de); |\n de = next; //UAF |\n\nrbtree of dev_snmp6\n |\n pde(tun3)\n / \\\n NULL pde(tun2)(CVE-2025-40271)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free in tipc_mon_reinit_self().\n\nsyzbot reported use-after-free of tipc_net(net)-\u0026gt;monitors[]\nin tipc_mon_reinit_self(). [0]\n\nThe array is protected by RTNL, but tipc_mon_reinit_self()\niterates over it without RTNL.\n\ntipc_mon_reinit_self() is called from tipc_net_finalize(),\nwhich is always under RTNL except for tipc_net_finalize_work().\n\nLet\u0026apos;s hold RTNL in tipc_net_finalize_work().\n\n[0]:\nBUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\nBUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162\nRead of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989\n\nCPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025\nWorkqueue: events tipc_net_finalize_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568\n kasan_check_byte include/linux/kasan.h:399 [inline]\n lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162\n rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline]\n rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline]\n rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244\n rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243\n write_lock_bh include/linux/rwlock_rt.h:99 [inline]\n tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718\n tipc_net_finalize+0x115/0x190 net/tipc/net.c:140\n process_one_work kernel/workqueue.c:3236 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400\n kthread+0x70e/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 6089:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:388 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657\n tipc_enable_bearer net/tipc/bearer.c:357 [inline]\n __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047\n __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline]\n tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393\n tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline]\n tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321\n genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:729\n ____sys_sendmsg+0x508/0x820 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/\n---truncated---(CVE-2025-40280)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: use lock accessing port_state and rport state\n\nnvme_fc_unregister_remote removes the remote port on a lport object at\nany point in time when there is no active association. This races with\nwith the reconnect logic, because nvme_fc_create_association is not\ntaking a lock to check the port_state and atomically increase the\nactive count on the rport.(CVE-2025-40342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narch_topology: Fix incorrect error check in topology_parse_cpu_capacity()\n\nFix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()\nwhich causes the code to proceed with NULL clock pointers. The current\nlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for both\nvalid pointers and NULL, leading to potential NULL pointer dereference\nin clk_get_rate().\n\nPer include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:\n\u0026quot;The error code within @ptr if it is an error pointer; 0 otherwise.\u0026quot;\n\nThis means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULL\npointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)\nwhen cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to be\ncalled when of_clk_get() returns NULL.\n\nReplace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for valid\npointers, preventing potential NULL pointer dereference in clk_get_rate().(CVE-2025-40346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixup\n\nRaw IP packets have no MAC header, leaving skb-\u0026gt;mac_header uninitialized.\nThis can trigger kernel panics on ARM64 when xfrm or other subsystems\naccess the offset due to strict alignment checks.\n\nInitialize the MAC header to prevent such crashes.\n\nThis can trigger kernel panics on ARM when running IPsec over the\nqmimux0 interface.\n\nExample trace:\n\n Internal error: Oops: 000000009600004f [#1] SMP\n CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1\n Hardware name: LS1028A RDB Board (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : xfrm_input+0xde8/0x1318\n lr : xfrm_input+0x61c/0x1318\n sp : ffff800080003b20\n Call trace:\n xfrm_input+0xde8/0x1318\n xfrm6_rcv+0x38/0x44\n xfrm6_esp_rcv+0x48/0xa8\n ip6_protocol_deliver_rcu+0x94/0x4b0\n ip6_input_finish+0x44/0x70\n ip6_input+0x44/0xc0\n ipv6_rcv+0x6c/0x114\n __netif_receive_skb_one_core+0x5c/0x8c\n __netif_receive_skb+0x18/0x60\n process_backlog+0x78/0x17c\n __napi_poll+0x38/0x180\n net_rx_action+0x168/0x2f0(CVE-2025-68192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: fix potential use-after-free in have_mon_and_osd_map()\n\nThe wait loop in __ceph_open_session() can race with the client\nreceiving a new monmap or osdmap shortly after the initial map is\nreceived. Both ceph_monc_handle_map() and handle_one_map() install\na new map immediately after freeing the old one\n\n kfree(monc-\u0026gt;monmap);\n monc-\u0026gt;monmap = monmap;\n\n ceph_osdmap_destroy(osdc-\u0026gt;osdmap);\n osdc-\u0026gt;osdmap = newmap;\n\nunder client-\u0026gt;monc.mutex and client-\u0026gt;osdc.lock respectively, but\nbecause neither is taken in have_mon_and_osd_map() it\u0026apos;s possible for\nclient-\u0026gt;monc.monmap-\u0026gt;epoch and client-\u0026gt;osdc.osdmap-\u0026gt;epoch arms in\n\n client-\u0026gt;monc.monmap \u0026amp;\u0026amp; client-\u0026gt;monc.monmap-\u0026gt;epoch \u0026amp;\u0026amp;\n client-\u0026gt;osdc.osdmap \u0026amp;\u0026amp; client-\u0026gt;osdc.osdmap-\u0026gt;epoch;\n\ncondition to dereference an already freed map. This happens to be\nreproducible with generic/395 and generic/397 with KASAN enabled:\n\n BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70\n Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305\n CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n have_mon_and_osd_map+0x56/0x70\n ceph_open_session+0x182/0x290\n ceph_get_tree+0x333/0x680\n vfs_get_tree+0x49/0x180\n do_new_mount+0x1a3/0x2d0\n path_mount+0x6dd/0x730\n do_mount+0x99/0xe0\n __do_sys_mount+0x141/0x180\n do_syscall_64+0x9f/0x100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 13305:\n ceph_osdmap_alloc+0x16/0x130\n ceph_osdc_init+0x27a/0x4c0\n ceph_create_client+0x153/0x190\n create_fs_client+0x50/0x2a0\n ceph_get_tree+0xff/0x680\n vfs_get_tree+0x49/0x180\n do_new_mount+0x1a3/0x2d0\n path_mount+0x6dd/0x730\n do_mount+0x99/0xe0\n __do_sys_mount+0x141/0x180\n do_syscall_64+0x9f/0x100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n Freed by task 9475:\n kfree+0x212/0x290\n handle_one_map+0x23c/0x3b0\n ceph_osdc_handle_map+0x3c9/0x590\n mon_dispatch+0x655/0x6f0\n ceph_con_process_message+0xc3/0xe0\n ceph_con_v1_try_read+0x614/0x760\n ceph_con_workfn+0x2de/0x650\n process_one_work+0x486/0x7c0\n process_scheduled_works+0x73/0x90\n worker_thread+0x1c8/0x2a0\n kthread+0x2ec/0x300\n ret_from_fork+0x24/0x40\n ret_from_fork_asm+0x1a/0x30\n\nRewrite the wait loop to check the above condition directly with\nclient-\u0026gt;monc.mutex and client-\u0026gt;osdc.lock taken as appropriate. While\nat it, improve the timeout handling (previously mount_timeout could be\nexceeded in case wait_event_interruptible_timeout() slept more than\nonce) and access client-\u0026gt;auth_err under client-\u0026gt;monc.mutex to match\nhow it\u0026apos;s set in finish_auth().\n\nmonmap_show() and osdmap_show() now take the respective lock before\naccessing the map as well.(CVE-2025-68285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()\n\nrlen value is a user-controlled value, but dtv5100_i2c_msg() does not\ncheck the size of the rlen value. Therefore, if it is set to a value\nlarger than sizeof(st-\u0026gt;data), an out-of-bounds vuln occurs for st-\u0026gt;data.\n\nTherefore, we need to add proper range checking to prevent this vuln.(CVE-2025-68819)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cm: Fix leaking the multicast GID table reference\n\nIf the CM ID is destroyed while the CM event for multicast creating is\nstill queued the cancel_work_sync() will prevent the work from running\nwhich also prevents destroying the ah_attr. This leaks a refcount and\ntriggers a WARN:\n\n GID entry ref leak for dev syz1 index 2 ref=573\n WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline]\n WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886\n\nDestroy the ah_attr after canceling the work, it is safe to call this\ntwice.(CVE-2025-71084)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nteam: fix check for port enabled in team_queue_override_port_prio_changed()\n\nThere has been a syzkaller bug reported recently with the following\ntrace:\n\nlist_del corruption, ffff888058bea080-\u0026gt;prev is LIST_POISON2 (dead000000000122)\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:59!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nCPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59\nCode: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 \u0026lt;0f\u0026gt; 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286\nRAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000\nRDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005\nRBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230\nR13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480\nFS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __list_del_entry_valid include/linux/list.h:132 [inline]\n __list_del_entry include/linux/list.h:223 [inline]\n list_del_rcu include/linux/rculist.h:178 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline]\n team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline]\n team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534\n team_option_set drivers/net/team/team_core.c:376 [inline]\n team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653\n genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg net/socket.c:742 [inline]\n ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684\n __sys_sendmsg+0x16d/0x220 net/socket.c:2716\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe problem is in this flow:\n1) Port is enabled, queue_id != 0, in qom_list\n2) Port gets disabled\n -\u0026gt; team_port_disable()\n -\u0026gt; team_queue_override_port_del()\n -\u0026gt; del (removed from list)\n3) Port is disabled, queue_id != 0, not in any list\n4) Priority changes\n -\u0026gt; team_queue_override_port_prio_changed()\n -\u0026gt; checks: port disabled \u0026amp;\u0026amp; queue_id != 0\n -\u0026gt; calls del - hits the BUG as it is removed already\n\nTo fix this, change the check in team_queue_override_port_prio_changed()\nso it returns early if port is not enabled.(CVE-2025-71091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: svcauth_gss: avoid NULL deref on zero length gss_token in gss_read_proxy_verf\n\nA zero length gss_token results in pages == 0 and in_token-\u0026gt;pages[0]\nis NULL. The code unconditionally evaluates\npage_address(in_token-\u0026gt;pages[0]) for the initial memcpy, which can\ndereference NULL even when the copy length is 0. Guard the first\nmemcpy so it only runs when length \u0026gt; 0.(CVE-2025-71120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec\n\nCommit efa56305908b (\u0026quot;nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\u0026quot;)\nadded ttag bounds checking and data_offset\nvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate\nwhether the command\u0026apos;s data structures (cmd-\u0026gt;req.sg and cmd-\u0026gt;iov) have\nbeen properly initialized before processing H2C_DATA PDUs.\n\nThe nvmet_tcp_build_pdu_iovec() function dereferences these pointers\nwithout NULL checks. This can be triggered by sending H2C_DATA PDU\nimmediately after the ICREQ/ICRESP handshake, before\nsending a CONNECT command or NVMe write command.\n\nAttack vectors that trigger NULL pointer dereferences:\n1. H2C_DATA PDU sent before CONNECT \u2192 both pointers NULL\n2. H2C_DATA PDU for READ command \u2192 cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n3. H2C_DATA PDU for uninitialized command slot \u2192 both pointers NULL\n\nThe fix validates both cmd-\u0026gt;req.sg and cmd-\u0026gt;iov before calling\nnvmet_tcp_build_pdu_iovec(). Both checks are required because:\n- Uninitialized commands: both NULL\n- READ commands: cmd-\u0026gt;req.sg allocated, cmd-\u0026gt;iov NULL\n- WRITE commands: both allocated(CVE-2026-22998)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()\n\nIn nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,\nthe function jumps to the out_scratch label without freeing the already\nallocated dsaddrs list, leading to a memory leak.\n\nFix this by jumping to the out_err_drain_dsaddrs label, which properly\nfrees the dsaddrs list before cleaning up other resources.(CVE-2026-23038)",
"id": "OESA-2026-1341",
"modified": "2026-08-06T11:10:22Z",
"published": "2026-02-13T11:10:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1341"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49309"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49829"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50151"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50159"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50616"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53254"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53521"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53594"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53712"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53840"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54048"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54145"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-54321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53179"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21981"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23138"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37766"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37770"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38250"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38480"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38556"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38572"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38574"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38618"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38728"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39676"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39702"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39744"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39797"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39828"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39853"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39860"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40105"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40215"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40342"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40346"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68819"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71084"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71120"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22998"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23038"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49190",
"CVE-2022-49309",
"CVE-2022-49829",
"CVE-2022-50151",
"CVE-2022-50159",
"CVE-2022-50616",
"CVE-2022-50735",
"CVE-2023-52927",
"CVE-2023-53250",
"CVE-2023-53254",
"CVE-2023-53521",
"CVE-2023-53594",
"CVE-2023-53712",
"CVE-2023-53840",
"CVE-2023-54048",
"CVE-2023-54145",
"CVE-2023-54321",
"CVE-2024-53179",
"CVE-2025-21981",
"CVE-2025-23138",
"CVE-2025-37766",
"CVE-2025-37770",
"CVE-2025-37947",
"CVE-2025-38068",
"CVE-2025-38154",
"CVE-2025-38250",
"CVE-2025-38480",
"CVE-2025-38556",
"CVE-2025-38572",
"CVE-2025-38574",
"CVE-2025-38618",
"CVE-2025-38676",
"CVE-2025-38728",
"CVE-2025-39676",
"CVE-2025-39702",
"CVE-2025-39744",
"CVE-2025-39749",
"CVE-2025-39797",
"CVE-2025-39828",
"CVE-2025-39853",
"CVE-2025-39860",
"CVE-2025-39913",
"CVE-2025-39945",
"CVE-2025-40018",
"CVE-2025-40105",
"CVE-2025-40215",
"CVE-2025-40271",
"CVE-2025-40280",
"CVE-2025-40342",
"CVE-2025-40346",
"CVE-2025-68192",
"CVE-2025-68285",
"CVE-2025-68819",
"CVE-2025-71084",
"CVE-2025-71091",
"CVE-2025-71120",
"CVE-2026-22998",
"CVE-2026-23038"
]
}
OPENSUSE-SU-2025:20081-1
Vulnerability from csaf_opensuse - Published: 2025-11-25 07:35 - Updated: 2026-09-20 21:47SSA-032379
Vulnerability from csaf_siemens - Published: 2026-05-12 00:00 - Updated: 2026-05-12 00:00SSA-089022
Vulnerability from csaf_siemens - Published: 2026-01-28 00:00 - Updated: 2026-02-24 00:00Sightings
| 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.