Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-21905 (GCVE-0-2025-21905)
Vulnerability from cvelistv5 – Published: 2025-04-01 15:40 – Updated: 2026-05-11 21:08- CWE-125 - Out-of-bounds Read
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
aee1b6385e29e472ae5592b9652b750a29bf702e , < 38f0d398b6d7640d223db69df022c4a232f24774
(git)
Affected: aee1b6385e29e472ae5592b9652b750a29bf702e , < c0e626f2b2390472afac52dfe72b29daf9ed8e1d (git) Affected: aee1b6385e29e472ae5592b9652b750a29bf702e , < 47616b82f2d42ea2060334746fed9a2988d845c9 (git) Affected: aee1b6385e29e472ae5592b9652b750a29bf702e , < 88ed69f924638c7503644e1f8eed1e976f3ffa7a (git) Affected: aee1b6385e29e472ae5592b9652b750a29bf702e , < b02f8d5a71c8571ccf77f285737c566db73ef5e5 (git) Affected: aee1b6385e29e472ae5592b9652b750a29bf702e , < f265e6031d0bc4fc40c4619cb42466722b46eaa9 (git) Affected: aee1b6385e29e472ae5592b9652b750a29bf702e , < 59cdda202829d1d6a095d233386870a59aff986f (git) Affected: aee1b6385e29e472ae5592b9652b750a29bf702e , < e0dc2c1bef722cbf16ae557690861e5f91208129 (git) |
guessed | |
| Linux | Linux |
Affected:
5.2
Unaffected: 0 , < 5.2 (semver) Unaffected: 5.4.291 , ≤ 5.4.* (semver) Unaffected: 5.10.235 , ≤ 5.10.* (semver) Unaffected: 5.15.179 , ≤ 5.15.* (semver) Unaffected: 6.1.131 , ≤ 6.1.* (semver) Unaffected: 6.6.83 , ≤ 6.6.* (semver) Unaffected: 6.12.19 , ≤ 6.12.* (semver) Unaffected: 6.13.7 , ≤ 6.13.* (semver) Unaffected: 6.14 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2025-21905",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:24:24.171530Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "CWE-125 Out-of-bounds Read",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T19:26:34.820Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T19:38:51.433Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/iwl-drv.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "38f0d398b6d7640d223db69df022c4a232f24774",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "c0e626f2b2390472afac52dfe72b29daf9ed8e1d",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "47616b82f2d42ea2060334746fed9a2988d845c9",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "88ed69f924638c7503644e1f8eed1e976f3ffa7a",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "b02f8d5a71c8571ccf77f285737c566db73ef5e5",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "f265e6031d0bc4fc40c4619cb42466722b46eaa9",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "59cdda202829d1d6a095d233386870a59aff986f",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "e0dc2c1bef722cbf16ae557690861e5f91208129",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/iwl-drv.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.131",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.83",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.19",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.291",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.131",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.83",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.19",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.7",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14",
"versionStartIncluding": "5.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0027s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0027s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:08:47.751Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/38f0d398b6d7640d223db69df022c4a232f24774"
},
{
"url": "https://git.kernel.org/stable/c/c0e626f2b2390472afac52dfe72b29daf9ed8e1d"
},
{
"url": "https://git.kernel.org/stable/c/47616b82f2d42ea2060334746fed9a2988d845c9"
},
{
"url": "https://git.kernel.org/stable/c/88ed69f924638c7503644e1f8eed1e976f3ffa7a"
},
{
"url": "https://git.kernel.org/stable/c/b02f8d5a71c8571ccf77f285737c566db73ef5e5"
},
{
"url": "https://git.kernel.org/stable/c/f265e6031d0bc4fc40c4619cb42466722b46eaa9"
},
{
"url": "https://git.kernel.org/stable/c/59cdda202829d1d6a095d233386870a59aff986f"
},
{
"url": "https://git.kernel.org/stable/c/e0dc2c1bef722cbf16ae557690861e5f91208129"
}
],
"title": "wifi: iwlwifi: limit printed string from FW file",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-21905",
"datePublished": "2025-04-01T15:40:46.465Z",
"dateReserved": "2024-12-29T08:45:45.785Z",
"dateUpdated": "2026-05-11T21:08:47.751Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-21905",
"date": "2026-09-28",
"epss": "0.00235",
"percentile": "0.13001"
},
"microsoft_vex": {
"current_release_date": "2026-02-21T02:43:05.000Z",
"cve": "CVE-2025-21905",
"id": "msrc_CVE-2025-21905",
"initial_release_date": "2025-04-02T00:00:00.000Z",
"product_status:fixed": "5",
"product_status:known_affected": "5",
"source": "Microsoft CSAF VEX",
"status": "final",
"title": "wifi: iwlwifi: limit printed string from FW file",
"url": "https://msrc.microsoft.com/csaf/vex/2025/msrc_cve-2025-21905.json",
"version": "2"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/iwl-drv.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "38f0d398b6d7640d223db69df022c4a232f24774",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "c0e626f2b2390472afac52dfe72b29daf9ed8e1d",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "47616b82f2d42ea2060334746fed9a2988d845c9",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "88ed69f924638c7503644e1f8eed1e976f3ffa7a",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "b02f8d5a71c8571ccf77f285737c566db73ef5e5",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "f265e6031d0bc4fc40c4619cb42466722b46eaa9",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "59cdda202829d1d6a095d233386870a59aff986f",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "e0dc2c1bef722cbf16ae557690861e5f91208129",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/iwl-drv.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.131",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.83",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.19",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "18F68456-FFB3-4E0E-A802-F3E41C67B10E",
"versionEndExcluding": "5.4.291",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "545121FA-DE31-4154-9446-C2000FB4104D",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C708062C-4E1B-465F-AE6D-C09C46400875",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BA9C2DE3-D37C-46C6-8DCD-2EE509456E0B",
"versionEndExcluding": "6.1.131",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "7D9F642F-6E05-4926-B0FE-62F95B7266BC",
"versionEndExcluding": "6.6.83",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "32865E5C-8AE1-4D3D-A64D-299039694A88",
"versionEndExcluding": "6.12.19",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "842F5A44-3E71-4546-B4FD-43B0ACE3F32B",
"versionEndExcluding": "6.13.7",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*",
"matchCriteriaId": "186716B6-2B66-4BD0-852E-D48E71C0C85F",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*",
"matchCriteriaId": "0D3E781C-403A-498F-9DA9-ECEE50F41E75",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:*",
"matchCriteriaId": "66619FB8-0AAF-4166-B2CF-67B24143261D",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:*",
"matchCriteriaId": "D3D6550E-6679-4560-902D-AF52DCFE905B",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:*",
"matchCriteriaId": "45B90F6B-BEC7-4D4E-883A-9DBADE021750",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0027s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0027s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: limitar la cadena impresa del archivo FW. No se garantiza que el archivo siempre tenga una terminaci\u00f3n NUL, por lo que al leer la cadena, se podr\u00eda leer m\u00e1s all\u00e1 del final del TLV. Si ese es el \u00faltimo TLV del archivo, es posible que incluso pueda leer m\u00e1s all\u00e1 del final del b\u00fafer del archivo. Para solucionar esto, limite el formato de impresi\u00f3n al tama\u00f1o del b\u00fafer disponible."
}
],
"id": "CVE-2025-21905",
"lastModified": "2026-06-17T08:44:34.570",
"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"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-21905",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:24:24.171530Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-04-01T16:15:20.980",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/38f0d398b6d7640d223db69df022c4a232f24774"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/47616b82f2d42ea2060334746fed9a2988d845c9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/59cdda202829d1d6a095d233386870a59aff986f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/88ed69f924638c7503644e1f8eed1e976f3ffa7a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b02f8d5a71c8571ccf77f285737c566db73ef5e5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c0e626f2b2390472afac52dfe72b29daf9ed8e1d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e0dc2c1bef722cbf16ae557690861e5f91208129"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f265e6031d0bc4fc40c4619cb42466722b46eaa9"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-30T00:05:02+00:00",
"cve": "CVE-2025-21905",
"id": "CVE-2025-21905",
"initial_release_date": "2025-04-01T00:00:00+00:00",
"product_status:fixed": "1699",
"product_status:known_affected": "22",
"product_status:known_not_affected": "42",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: wifi: iwlwifi: limit printed string from FW file",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-21905.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T19:38:51.433Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2025-21905",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:24:24.171530Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-125",
"description": "CWE-125 Out-of-bounds Read",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T14:37:29.281Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/iwl-drv.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "38f0d398b6d7640d223db69df022c4a232f24774",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "c0e626f2b2390472afac52dfe72b29daf9ed8e1d",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "47616b82f2d42ea2060334746fed9a2988d845c9",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "88ed69f924638c7503644e1f8eed1e976f3ffa7a",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "b02f8d5a71c8571ccf77f285737c566db73ef5e5",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "f265e6031d0bc4fc40c4619cb42466722b46eaa9",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "59cdda202829d1d6a095d233386870a59aff986f",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "e0dc2c1bef722cbf16ae557690861e5f91208129",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/iwl-drv.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.131",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.83",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.19",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.291",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.131",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.83",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.19",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.7",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14",
"versionStartIncluding": "5.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0027s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0027s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:08:47.751Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/38f0d398b6d7640d223db69df022c4a232f24774"
},
{
"url": "https://git.kernel.org/stable/c/c0e626f2b2390472afac52dfe72b29daf9ed8e1d"
},
{
"url": "https://git.kernel.org/stable/c/47616b82f2d42ea2060334746fed9a2988d845c9"
},
{
"url": "https://git.kernel.org/stable/c/88ed69f924638c7503644e1f8eed1e976f3ffa7a"
},
{
"url": "https://git.kernel.org/stable/c/b02f8d5a71c8571ccf77f285737c566db73ef5e5"
},
{
"url": "https://git.kernel.org/stable/c/f265e6031d0bc4fc40c4619cb42466722b46eaa9"
},
{
"url": "https://git.kernel.org/stable/c/59cdda202829d1d6a095d233386870a59aff986f"
},
{
"url": "https://git.kernel.org/stable/c/e0dc2c1bef722cbf16ae557690861e5f91208129"
}
],
"title": "wifi: iwlwifi: limit printed string from FW file",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-21905",
"datePublished": "2025-04-01T15:40:46.465Z",
"dateReserved": "2024-12-29T08:45:45.785Z",
"dateUpdated": "2026-05-11T21:08:47.751Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2025-AVI-0859
Vulnerability from certfr_avis - Published: 2025-10-10 - Updated: 2025-10-10
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Elles permettent à un attaquant de provoquer un déni de service et un problème de sécurité non spécifié par l'éditeur.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 16.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.04",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 14.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2024-26775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26775"
},
{
"name": "CVE-2024-26726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26726"
},
{
"name": "CVE-2022-48703",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48703"
},
{
"name": "CVE-2025-38306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38306"
},
{
"name": "CVE-2025-38683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38683"
},
{
"name": "CVE-2025-38029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38029"
},
{
"name": "CVE-2025-38032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38032"
},
{
"name": "CVE-2025-38033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38033"
},
{
"name": "CVE-2025-38036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38036"
},
{
"name": "CVE-2025-38038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38038"
},
{
"name": "CVE-2025-38039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38039"
},
{
"name": "CVE-2025-38041",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38041"
},
{
"name": "CVE-2025-38042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38042"
},
{
"name": "CVE-2025-38050",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38050"
},
{
"name": "CVE-2025-38054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38054"
},
{
"name": "CVE-2025-38069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38069"
},
{
"name": "CVE-2025-38070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38070"
},
{
"name": "CVE-2025-38073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38073"
},
{
"name": "CVE-2025-38076",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38076"
},
{
"name": "CVE-2025-38082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38082"
},
{
"name": "CVE-2025-38092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38092"
},
{
"name": "CVE-2025-38096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38096"
},
{
"name": "CVE-2025-38101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38101"
},
{
"name": "CVE-2025-38116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38116"
},
{
"name": "CVE-2025-38128",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38128"
},
{
"name": "CVE-2025-38130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38130"
},
{
"name": "CVE-2025-38134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38134"
},
{
"name": "CVE-2025-38137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38137"
},
{
"name": "CVE-2025-38139",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38139"
},
{
"name": "CVE-2025-38140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38140"
},
{
"name": "CVE-2025-38141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38141"
},
{
"name": "CVE-2025-38156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38156"
},
{
"name": "CVE-2025-38164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38164"
},
{
"name": "CVE-2025-38168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38168"
},
{
"name": "CVE-2025-38169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38169"
},
{
"name": "CVE-2025-38172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38172"
},
{
"name": "CVE-2025-38175",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38175"
},
{
"name": "CVE-2025-38176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38176"
},
{
"name": "CVE-2025-38237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38237"
},
{
"name": "CVE-2025-38267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38267"
},
{
"name": "CVE-2025-38269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38269"
},
{
"name": "CVE-2025-38270",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38270"
},
{
"name": "CVE-2025-38274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38274"
},
{
"name": "CVE-2025-38278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38278"
},
{
"name": "CVE-2025-38281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38281"
},
{
"name": "CVE-2025-38284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38284"
},
{
"name": "CVE-2025-38294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38294"
},
{
"name": "CVE-2025-38295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38295"
},
{
"name": "CVE-2025-38296",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38296"
},
{
"name": "CVE-2025-38297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38297"
},
{
"name": "CVE-2025-38301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38301"
},
{
"name": "CVE-2025-38302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38302"
},
{
"name": "CVE-2025-38311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38311"
},
{
"name": "CVE-2025-38314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38314"
},
{
"name": "CVE-2025-38316",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38316"
},
{
"name": "CVE-2025-38318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38318"
},
{
"name": "CVE-2025-38514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38514"
},
{
"name": "CVE-2025-38542",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38542"
},
{
"name": "CVE-2025-39890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39890"
},
{
"name": "CVE-2024-44939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44939"
},
{
"name": "CVE-2024-47685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47685"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2024-27407",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27407"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2024-57883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57883"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-21877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21877"
},
{
"name": "CVE-2025-21878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21878"
},
{
"name": "CVE-2025-21883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21883"
},
{
"name": "CVE-2025-21885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21885"
},
{
"name": "CVE-2025-21888",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21888"
},
{
"name": "CVE-2025-21890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21890"
},
{
"name": "CVE-2025-21891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21891"
},
{
"name": "CVE-2025-21892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21892"
},
{
"name": "CVE-2024-58090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58090"
},
{
"name": "CVE-2025-21875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21875"
},
{
"name": "CVE-2025-21881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21881"
},
{
"name": "CVE-2025-21887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21887"
},
{
"name": "CVE-2025-21898",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21898"
},
{
"name": "CVE-2025-21899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21899"
},
{
"name": "CVE-2025-21904",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21904"
},
{
"name": "CVE-2025-21905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21905"
},
{
"name": "CVE-2025-21909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21909"
},
{
"name": "CVE-2025-21910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21910"
},
{
"name": "CVE-2025-21912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21912"
},
{
"name": "CVE-2025-21913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21913"
},
{
"name": "CVE-2025-21914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21914"
},
{
"name": "CVE-2025-21916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21916"
},
{
"name": "CVE-2025-21917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21917"
},
{
"name": "CVE-2025-21918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21918"
},
{
"name": "CVE-2025-21919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21919"
},
{
"name": "CVE-2025-21920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21920"
},
{
"name": "CVE-2025-21922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21922"
},
{
"name": "CVE-2025-21924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21924"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2025-21928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21928"
},
{
"name": "CVE-2025-21934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21934"
},
{
"name": "CVE-2025-21935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21935"
},
{
"name": "CVE-2025-21936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21936"
},
{
"name": "CVE-2025-21937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21937"
},
{
"name": "CVE-2025-21941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21941"
},
{
"name": "CVE-2025-21944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21944"
},
{
"name": "CVE-2025-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21945"
},
{
"name": "CVE-2025-21947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21947"
},
{
"name": "CVE-2025-21948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21948"
},
{
"name": "CVE-2025-21950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21950"
},
{
"name": "CVE-2025-21951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21951"
},
{
"name": "CVE-2025-21956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21956"
},
{
"name": "CVE-2025-21957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21957"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2025-21960",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21960"
},
{
"name": "CVE-2025-21962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21962"
},
{
"name": "CVE-2025-21963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21963"
},
{
"name": "CVE-2025-21964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21964"
},
{
"name": "CVE-2025-21968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21968"
},
{
"name": "CVE-2025-21970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21970"
},
{
"name": "CVE-2025-21975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21975"
},
{
"name": "CVE-2025-21978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21978"
},
{
"name": "CVE-2025-21979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21979"
},
{
"name": "CVE-2025-21980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21980"
},
{
"name": "CVE-2025-21981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21981"
},
{
"name": "CVE-2025-21986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21986"
},
{
"name": "CVE-2025-21991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21991"
},
{
"name": "CVE-2025-21992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21992"
},
{
"name": "CVE-2025-21994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21994"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-21997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21997"
},
{
"name": "CVE-2025-21999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21999"
},
{
"name": "CVE-2025-22004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22004"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2025-22008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22008"
},
{
"name": "CVE-2025-22010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22010"
},
{
"name": "CVE-2025-22014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22014"
},
{
"name": "CVE-2025-22015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22015"
},
{
"name": "CVE-2025-21969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21969"
},
{
"name": "CVE-2025-21927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21927"
},
{
"name": "CVE-2025-22088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22088"
},
{
"name": "CVE-2025-37785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37785"
},
{
"name": "CVE-2025-21873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21873"
},
{
"name": "CVE-2025-21889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21889"
},
{
"name": "CVE-2025-21894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21894"
},
{
"name": "CVE-2025-21895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21895"
},
{
"name": "CVE-2025-21908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21908"
},
{
"name": "CVE-2025-21915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21915"
},
{
"name": "CVE-2025-21930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21930"
},
{
"name": "CVE-2025-21961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21961"
},
{
"name": "CVE-2025-21966",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21966"
},
{
"name": "CVE-2025-21972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21972"
},
{
"name": "CVE-2025-21976",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21976"
},
{
"name": "CVE-2025-21995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21995"
},
{
"name": "CVE-2025-22001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22001"
},
{
"name": "CVE-2025-22003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22003"
},
{
"name": "CVE-2025-22009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22009"
},
{
"name": "CVE-2025-22013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22013"
},
{
"name": "CVE-2025-22016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22016"
},
{
"name": "CVE-2025-22017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22017"
},
{
"name": "CVE-2025-21872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21872"
},
{
"name": "CVE-2025-37752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37752"
},
{
"name": "CVE-2025-37756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37756"
},
{
"name": "CVE-2025-37889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37889"
},
{
"name": "CVE-2025-37948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37948"
},
{
"name": "CVE-2025-37963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37963"
},
{
"name": "CVE-2025-37958",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37958"
},
{
"name": "CVE-2025-21929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21929"
},
{
"name": "CVE-2025-37954",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37954"
},
{
"name": "CVE-2025-21903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21903"
},
{
"name": "CVE-2025-21911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21911"
},
{
"name": "CVE-2025-21946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21946"
},
{
"name": "CVE-2025-21955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21955"
},
{
"name": "CVE-2025-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21967"
},
{
"name": "CVE-2025-21977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21977"
},
{
"name": "CVE-2025-21982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21982"
},
{
"name": "CVE-2025-22011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22011"
},
{
"name": "CVE-2025-21880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21880"
},
{
"name": "CVE-2025-38003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38003"
},
{
"name": "CVE-2025-38004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38004"
},
{
"name": "CVE-2025-38031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38031"
},
{
"name": "CVE-2025-38040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38040"
},
{
"name": "CVE-2025-38043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38043"
},
{
"name": "CVE-2025-38044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38044"
},
{
"name": "CVE-2025-38045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38045"
},
{
"name": "CVE-2025-38053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38053"
},
{
"name": "CVE-2025-38055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38055"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-38059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38059"
},
{
"name": "CVE-2025-38060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38060"
},
{
"name": "CVE-2025-38065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38065"
},
{
"name": "CVE-2025-38068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38068"
},
{
"name": "CVE-2025-38072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38072"
},
{
"name": "CVE-2025-38077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38077"
},
{
"name": "CVE-2025-38078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38078"
},
{
"name": "CVE-2025-38079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38079"
},
{
"name": "CVE-2025-38080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38080"
},
{
"name": "CVE-2025-38081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38081"
},
{
"name": "CVE-2025-38110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38110"
},
{
"name": "CVE-2025-38061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38061"
},
{
"name": "CVE-2025-38086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38086"
},
{
"name": "CVE-2025-38052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38052"
},
{
"name": "CVE-2025-38088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38088"
},
{
"name": "CVE-2025-38181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38181"
},
{
"name": "CVE-2025-38200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38200"
},
{
"name": "CVE-2025-38206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38206"
},
{
"name": "CVE-2025-38212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38212"
},
{
"name": "CVE-2025-38257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38257"
},
{
"name": "CVE-2025-38289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38289"
},
{
"name": "CVE-2025-38047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38047"
},
{
"name": "CVE-2025-38064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38064"
},
{
"name": "CVE-2025-38091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38091"
},
{
"name": "CVE-2025-38098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38098"
},
{
"name": "CVE-2025-38099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38099"
},
{
"name": "CVE-2025-38105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38105"
},
{
"name": "CVE-2025-38106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38106"
},
{
"name": "CVE-2025-38109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38109"
},
{
"name": "CVE-2025-38114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38114"
},
{
"name": "CVE-2025-38117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38117"
},
{
"name": "CVE-2025-38123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38123"
},
{
"name": "CVE-2025-38127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38127"
},
{
"name": "CVE-2025-38034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38034"
},
{
"name": "CVE-2025-38035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38035"
},
{
"name": "CVE-2025-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38037"
},
{
"name": "CVE-2025-38048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38048"
},
{
"name": "CVE-2025-38051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38051"
},
{
"name": "CVE-2025-38058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38058"
},
{
"name": "CVE-2025-38062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38062"
},
{
"name": "CVE-2025-38063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38063"
},
{
"name": "CVE-2025-38066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38066"
},
{
"name": "CVE-2025-38067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38067"
},
{
"name": "CVE-2025-38071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38071"
},
{
"name": "CVE-2025-38074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38074"
},
{
"name": "CVE-2025-38075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38075"
},
{
"name": "CVE-2025-38084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38084"
},
{
"name": "CVE-2025-38085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38085"
},
{
"name": "CVE-2025-38090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38090"
},
{
"name": "CVE-2025-38097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38097"
},
{
"name": "CVE-2025-38100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38100"
},
{
"name": "CVE-2025-38102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38102"
},
{
"name": "CVE-2025-38103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38103"
},
{
"name": "CVE-2025-38107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38107"
},
{
"name": "CVE-2025-38108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38108"
},
{
"name": "CVE-2025-38111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38111"
},
{
"name": "CVE-2025-38112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38112"
},
{
"name": "CVE-2025-38113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38113"
},
{
"name": "CVE-2025-38115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38115"
},
{
"name": "CVE-2025-38118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38118"
},
{
"name": "CVE-2025-38119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38119"
},
{
"name": "CVE-2025-38120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38120"
},
{
"name": "CVE-2025-38122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38122"
},
{
"name": "CVE-2025-38124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38124"
},
{
"name": "CVE-2025-38126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38126"
},
{
"name": "CVE-2025-38131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38131"
},
{
"name": "CVE-2025-38135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38135"
},
{
"name": "CVE-2025-38136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38136"
},
{
"name": "CVE-2025-38138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38138"
},
{
"name": "CVE-2025-38142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38142"
},
{
"name": "CVE-2025-38143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38143"
},
{
"name": "CVE-2025-38145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38145"
},
{
"name": "CVE-2025-38146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38146"
},
{
"name": "CVE-2025-38147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38147"
},
{
"name": "CVE-2025-38148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38148"
},
{
"name": "CVE-2025-38151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38151"
},
{
"name": "CVE-2025-38153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38153"
},
{
"name": "CVE-2025-38154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38154"
},
{
"name": "CVE-2025-38157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38157"
},
{
"name": "CVE-2025-38158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38158"
},
{
"name": "CVE-2025-38159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38159"
},
{
"name": "CVE-2025-38160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38160"
},
{
"name": "CVE-2025-38161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38161"
},
{
"name": "CVE-2025-38163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38163"
},
{
"name": "CVE-2025-38165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38165"
},
{
"name": "CVE-2025-38166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38166"
},
{
"name": "CVE-2025-38167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38167"
},
{
"name": "CVE-2025-38170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38170"
},
{
"name": "CVE-2025-38173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38173"
},
{
"name": "CVE-2025-38174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38174"
},
{
"name": "CVE-2025-38184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38184"
},
{
"name": "CVE-2025-38194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38194"
},
{
"name": "CVE-2025-38197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38197"
},
{
"name": "CVE-2025-38211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38211"
},
{
"name": "CVE-2025-38218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38218"
},
{
"name": "CVE-2025-38219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38219"
},
{
"name": "CVE-2025-38222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38222"
},
{
"name": "CVE-2025-38226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38226"
},
{
"name": "CVE-2025-38227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38227"
},
{
"name": "CVE-2025-38229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38229"
},
{
"name": "CVE-2025-38231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38231"
},
{
"name": "CVE-2025-38245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38245"
},
{
"name": "CVE-2025-38249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38249"
},
{
"name": "CVE-2025-38251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38251"
},
{
"name": "CVE-2025-38262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38262"
},
{
"name": "CVE-2025-38263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38263"
},
{
"name": "CVE-2025-38273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38273"
},
{
"name": "CVE-2025-38275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38275"
},
{
"name": "CVE-2025-38277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38277"
},
{
"name": "CVE-2025-38280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38280"
},
{
"name": "CVE-2025-38282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38282"
},
{
"name": "CVE-2025-38285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38285"
},
{
"name": "CVE-2025-38286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38286"
},
{
"name": "CVE-2025-38293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38293"
},
{
"name": "CVE-2025-38298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38298"
},
{
"name": "CVE-2025-38300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38300"
},
{
"name": "CVE-2025-38304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38304"
},
{
"name": "CVE-2025-38305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38305"
},
{
"name": "CVE-2025-38310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38310"
},
{
"name": "CVE-2025-38312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38312"
},
{
"name": "CVE-2025-38313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38313"
},
{
"name": "CVE-2025-38319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38319"
},
{
"name": "CVE-2025-38320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38320"
},
{
"name": "CVE-2025-38324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38324"
},
{
"name": "CVE-2025-38326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38326"
},
{
"name": "CVE-2025-38328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38328"
},
{
"name": "CVE-2025-38332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38332"
},
{
"name": "CVE-2025-38336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38336"
},
{
"name": "CVE-2025-38337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38337"
},
{
"name": "CVE-2025-38342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38342"
},
{
"name": "CVE-2025-38344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38344"
},
{
"name": "CVE-2025-38345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38345"
},
{
"name": "CVE-2025-38346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38346"
},
{
"name": "CVE-2025-38348",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38348"
},
{
"name": "CVE-2025-38350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38350"
},
{
"name": "CVE-2025-38352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38352"
},
{
"name": "CVE-2025-38362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38362"
},
{
"name": "CVE-2025-38363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38363"
},
{
"name": "CVE-2025-38371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38371"
},
{
"name": "CVE-2025-38375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38375"
},
{
"name": "CVE-2025-38377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38377"
},
{
"name": "CVE-2025-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38384"
},
{
"name": "CVE-2025-38386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38386"
},
{
"name": "CVE-2025-38387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38387"
},
{
"name": "CVE-2025-38389",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38389"
},
{
"name": "CVE-2025-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38391"
},
{
"name": "CVE-2025-38393",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38393"
},
{
"name": "CVE-2025-38395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38395"
},
{
"name": "CVE-2025-38399",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38399"
},
{
"name": "CVE-2025-38400",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38400"
},
{
"name": "CVE-2025-38401",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38401"
},
{
"name": "CVE-2025-38403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38403"
},
{
"name": "CVE-2025-38406",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38406"
},
{
"name": "CVE-2025-38410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38410"
},
{
"name": "CVE-2025-38412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38412"
},
{
"name": "CVE-2025-38415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38415"
},
{
"name": "CVE-2025-38416",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38416"
},
{
"name": "CVE-2025-38418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38418"
},
{
"name": "CVE-2025-38419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38419"
},
{
"name": "CVE-2025-38420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38420"
},
{
"name": "CVE-2025-38424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38424"
},
{
"name": "CVE-2025-38428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38428"
},
{
"name": "CVE-2025-38430",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38430"
},
{
"name": "CVE-2025-38439",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38439"
},
{
"name": "CVE-2025-38441",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38441"
},
{
"name": "CVE-2025-38443",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38443"
},
{
"name": "CVE-2025-38444",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38444"
},
{
"name": "CVE-2025-38445",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38445"
},
{
"name": "CVE-2025-38448",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38448"
},
{
"name": "CVE-2025-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38457"
},
{
"name": "CVE-2025-38458",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38458"
},
{
"name": "CVE-2025-38459",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38459"
},
{
"name": "CVE-2025-38460",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38460"
},
{
"name": "CVE-2025-38461",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38461"
},
{
"name": "CVE-2025-38462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38462"
},
{
"name": "CVE-2025-38464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38464"
},
{
"name": "CVE-2025-38465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38465"
},
{
"name": "CVE-2025-38466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38466"
},
{
"name": "CVE-2025-38467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38467"
},
{
"name": "CVE-2025-38477",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38477"
},
{
"name": "CVE-2025-38498",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38498"
},
{
"name": "CVE-2025-38499",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38499"
},
{
"name": "CVE-2025-38500",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38500"
},
{
"name": "CVE-2025-38292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38292"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2025-38132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38132"
},
{
"name": "CVE-2025-38149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38149"
},
{
"name": "CVE-2025-38155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38155"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2025-38203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38203"
},
{
"name": "CVE-2025-38204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38204"
},
{
"name": "CVE-2025-38244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38244"
},
{
"name": "CVE-2025-38265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38265"
},
{
"name": "CVE-2025-38268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38268"
},
{
"name": "CVE-2025-38272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38272"
},
{
"name": "CVE-2025-38279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38279"
},
{
"name": "CVE-2025-38283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38283"
},
{
"name": "CVE-2025-38287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38287"
},
{
"name": "CVE-2025-38288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38288"
},
{
"name": "CVE-2025-38290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38290"
},
{
"name": "CVE-2025-38291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38291"
},
{
"name": "CVE-2025-38299",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38299"
},
{
"name": "CVE-2025-38303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38303"
},
{
"name": "CVE-2025-38307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38307"
},
{
"name": "CVE-2025-38315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38315"
},
{
"name": "CVE-2025-38317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38317"
},
{
"name": "CVE-2025-38414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38414"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-38513",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38513"
},
{
"name": "CVE-2025-38515",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38515"
},
{
"name": "CVE-2025-38516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38516"
},
{
"name": "CVE-2025-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38540"
},
{
"name": "CVE-2025-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38617"
},
{
"name": "CVE-2025-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38618"
}
],
"initial_release_date": "2025-10-10T00:00:00",
"last_revision_date": "2025-10-10T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0859",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-10-10T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Elles permettent \u00e0 un attaquant de provoquer un d\u00e9ni de service et un probl\u00e8me de s\u00e9curit\u00e9 non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2025-10-06",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7801-2",
"url": "https://ubuntu.com/security/notices/USN-7801-2"
},
{
"published_at": "2025-10-06",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7774-5",
"url": "https://ubuntu.com/security/notices/USN-7774-5"
},
{
"published_at": "2025-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7810-1",
"url": "https://ubuntu.com/security/notices/USN-7810-1"
},
{
"published_at": "2025-10-06",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7791-3",
"url": "https://ubuntu.com/security/notices/USN-7791-3"
},
{
"published_at": "2025-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7809-1",
"url": "https://ubuntu.com/security/notices/USN-7809-1"
},
{
"published_at": "2025-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7789-2",
"url": "https://ubuntu.com/security/notices/USN-7789-2"
},
{
"published_at": "2025-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7811-1",
"url": "https://ubuntu.com/security/notices/USN-7811-1"
},
{
"published_at": "2025-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7792-3",
"url": "https://ubuntu.com/security/notices/USN-7792-3"
},
{
"published_at": "2025-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7793-5",
"url": "https://ubuntu.com/security/notices/USN-7793-5"
},
{
"published_at": "2025-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7795-3",
"url": "https://ubuntu.com/security/notices/USN-7795-3"
},
{
"published_at": "2025-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu LSN-0115-1",
"url": "https://ubuntu.com/security/notices/LSN-0115-1"
},
{
"published_at": "2025-10-08",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7808-1",
"url": "https://ubuntu.com/security/notices/USN-7808-1"
}
]
}
CERTFR-2025-AVI-0892
Vulnerability from certfr_avis - Published: 2025-10-17 - Updated: 2025-10-17
De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une atteinte à la confidentialité des données, une atteinte à l'intégrité des données et un contournement de la politique de sécurité.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Title | Publication Time | Tags | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Ubuntu 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.04",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2025-22003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22003"
},
{
"name": "CVE-2025-21975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21975"
},
{
"name": "CVE-2025-21980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21980"
},
{
"name": "CVE-2025-21889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21889"
},
{
"name": "CVE-2025-21937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21937"
},
{
"name": "CVE-2025-22017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22017"
},
{
"name": "CVE-2025-21881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21881"
},
{
"name": "CVE-2025-21951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21951"
},
{
"name": "CVE-2025-21941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21941"
},
{
"name": "CVE-2025-21872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21872"
},
{
"name": "CVE-2025-21922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21922"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2024-49950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49950"
},
{
"name": "CVE-2024-35849",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35849"
},
{
"name": "CVE-2025-22009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22009"
},
{
"name": "CVE-2025-21904",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21904"
},
{
"name": "CVE-2025-22004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22004"
},
{
"name": "CVE-2025-21929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21929"
},
{
"name": "CVE-2025-38500",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38500"
},
{
"name": "CVE-2025-21977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21977"
},
{
"name": "CVE-2025-21918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21918"
},
{
"name": "CVE-2025-21948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21948"
},
{
"name": "CVE-2025-21914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21914"
},
{
"name": "CVE-2025-21995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21995"
},
{
"name": "CVE-2025-21915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21915"
},
{
"name": "CVE-2024-58090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58090"
},
{
"name": "CVE-2025-21972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21972"
},
{
"name": "CVE-2025-21986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21986"
},
{
"name": "CVE-2025-21961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21961"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2025-21946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21946"
},
{
"name": "CVE-2025-21982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21982"
},
{
"name": "CVE-2025-21936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21936"
},
{
"name": "CVE-2025-21909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21909"
},
{
"name": "CVE-2025-21880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21880"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2025-37889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37889"
},
{
"name": "CVE-2025-21981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21981"
},
{
"name": "CVE-2025-21910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21910"
},
{
"name": "CVE-2025-22014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22014"
},
{
"name": "CVE-2025-21911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21911"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-37785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37785"
},
{
"name": "CVE-2025-21917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21917"
},
{
"name": "CVE-2025-21957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21957"
},
{
"name": "CVE-2025-21999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21999"
},
{
"name": "CVE-2025-21997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21997"
},
{
"name": "CVE-2025-21992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21992"
},
{
"name": "CVE-2025-21978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21978"
},
{
"name": "CVE-2025-21947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21947"
},
{
"name": "CVE-2025-21913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21913"
},
{
"name": "CVE-2025-21966",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21966"
},
{
"name": "CVE-2025-21970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21970"
},
{
"name": "CVE-2025-21890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21890"
},
{
"name": "CVE-2025-21916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21916"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2025-21927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21927"
},
{
"name": "CVE-2025-21883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21883"
},
{
"name": "CVE-2025-21898",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21898"
},
{
"name": "CVE-2025-37797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37797"
},
{
"name": "CVE-2025-21908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21908"
},
{
"name": "CVE-2024-49924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49924"
},
{
"name": "CVE-2025-21895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21895"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2025-21935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21935"
},
{
"name": "CVE-2025-21888",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21888"
},
{
"name": "CVE-2025-22010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22010"
},
{
"name": "CVE-2025-21976",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21976"
},
{
"name": "CVE-2025-21950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21950"
},
{
"name": "CVE-2025-22001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22001"
},
{
"name": "CVE-2025-21899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21899"
},
{
"name": "CVE-2025-21994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21994"
},
{
"name": "CVE-2025-21928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21928"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2025-21934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21934"
},
{
"name": "CVE-2025-22011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22011"
},
{
"name": "CVE-2025-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38617"
},
{
"name": "CVE-2025-38083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38083"
},
{
"name": "CVE-2025-21912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21912"
},
{
"name": "CVE-2025-21903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21903"
},
{
"name": "CVE-2025-21956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21956"
},
{
"name": "CVE-2025-21885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21885"
},
{
"name": "CVE-2025-21877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21877"
},
{
"name": "CVE-2025-38244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38244"
},
{
"name": "CVE-2025-21878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21878"
},
{
"name": "CVE-2025-37752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37752"
},
{
"name": "CVE-2025-21873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21873"
},
{
"name": "CVE-2025-38477",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38477"
},
{
"name": "CVE-2025-38683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38683"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2025-21930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21930"
},
{
"name": "CVE-2025-21892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21892"
},
{
"name": "CVE-2025-21944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21944"
},
{
"name": "CVE-2025-21905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21905"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2025-21920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21920"
},
{
"name": "CVE-2025-22016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22016"
},
{
"name": "CVE-2025-37756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37756"
},
{
"name": "CVE-2025-21955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21955"
},
{
"name": "CVE-2025-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38618"
},
{
"name": "CVE-2025-21891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21891"
},
{
"name": "CVE-2025-22013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22013"
},
{
"name": "CVE-2025-21979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21979"
},
{
"name": "CVE-2025-21963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21963"
},
{
"name": "CVE-2025-38350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38350"
},
{
"name": "CVE-2025-21960",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21960"
},
{
"name": "CVE-2025-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21967"
},
{
"name": "CVE-2024-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50073"
},
{
"name": "CVE-2025-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21945"
},
{
"name": "CVE-2025-22008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22008"
},
{
"name": "CVE-2025-21969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21969"
},
{
"name": "CVE-2025-21894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21894"
},
{
"name": "CVE-2025-21919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21919"
},
{
"name": "CVE-2023-52757",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52757"
},
{
"name": "CVE-2023-52975",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52975"
},
{
"name": "CVE-2025-21968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21968"
},
{
"name": "CVE-2025-21991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21991"
},
{
"name": "CVE-2025-21875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21875"
},
{
"name": "CVE-2025-22015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22015"
},
{
"name": "CVE-2025-21962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21962"
},
{
"name": "CVE-2025-21924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21924"
},
{
"name": "CVE-2025-21964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21964"
}
],
"initial_release_date": "2025-10-17T00:00:00",
"last_revision_date": "2025-10-17T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0892",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-10-17T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans le noyau Linux d\u0027Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es, une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es et un contournement de la politique de s\u00e9curit\u00e9.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2025-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7820-1",
"url": "https://ubuntu.com/security/notices/USN-7820-1"
},
{
"published_at": "2025-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7819-1",
"url": "https://ubuntu.com/security/notices/USN-7819-1"
},
{
"published_at": "2025-10-14",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7821-1",
"url": "https://ubuntu.com/security/notices/USN-7821-1"
},
{
"published_at": "2025-10-15",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7801-3",
"url": "https://ubuntu.com/security/notices/USN-7801-3"
},
{
"published_at": "2025-10-14",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7810-2",
"url": "https://ubuntu.com/security/notices/USN-7810-2"
},
{
"published_at": "2025-10-14",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7810-3",
"url": "https://ubuntu.com/security/notices/USN-7810-3"
},
{
"published_at": "2025-10-13",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7796-4",
"url": "https://ubuntu.com/security/notices/USN-7796-4"
},
{
"published_at": "2025-10-14",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7808-2",
"url": "https://ubuntu.com/security/notices/USN-7808-2"
},
{
"published_at": "2025-10-14",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7791-4",
"url": "https://ubuntu.com/security/notices/USN-7791-4"
}
]
}
CERTFR-2025-AVI-0969
Vulnerability from certfr_avis - Published: 2025-11-06 - Updated: 2025-11-06
De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer un problème de sécurité non spécifié par l'éditeur.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| VMware | Tanzu Kubernetes Runtime | GenAI sur Tanzu Platform pour Cloud Foundry versions antérieures à 10.2.5 | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry versions antérieures à 6.0.20+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Noble) versions antérieures à 1.90.x | ||
| VMware | Tanzu Kubernetes Runtime | NodeJS Buildpack versions antérieures à 1.8.58 | ||
| VMware | Tanzu Kubernetes Runtime | Python Buildpack versions antérieures à 1.8.63 | ||
| VMware | Tanzu Kubernetes Runtime | VMware Tanzu pour MySQL sur Tanzu Platform versions antérieures à 10.1.0 | ||
| VMware | Tanzu Kubernetes Runtime | API Gateway pour VMware Tanzu Platform versions antérieures à 2.4.0 | ||
| VMware | Tanzu Kubernetes Runtime | PHP Buildpack versions antérieures à 4.6.49 | ||
| VMware | Tanzu Kubernetes Runtime | Single Sign-On pour VMware Tanzu Platform versions antérieures à 1.16.14 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy FIPS) versions antérieures à 1.915.x | ||
| VMware | Tanzu Application Service | CredHub Service Broker versions antérieures à 1.6.6 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy FIPS) versions antérieures à 1.943.x | ||
| VMware | Tanzu Kubernetes Runtime | Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions antérieures à 10.2.4+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry Windows versions antérieures à 6.0.20+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy) versions antérieures à 1.915.x | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry Windows versions antérieures à 10.2.3+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Single Sign-On pour VMware Tanzu Application Service versions antérieures à 1.16.13 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy) versions antérieures à 1.943.x | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry isolation segment versions antérieures à 6.0.20+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Noble) versions antérieures à 1.77.x | ||
| VMware | Services Suite | Platform Automation Toolkit versions antérieures à 5.3.2 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy Azure Light) versions antérieures à 1.906.x | ||
| VMware | Tanzu Kubernetes Runtime | Spring Cloud Data Flow pour VMware Tanzu versions antérieures à 1.14.9 | ||
| VMware | Tanzu Kubernetes Runtime | App Autoscaler CLI Plugin pour VMware Tanzu Platform versions antérieures à 250.5.9 | ||
| VMware | Tanzu Kubernetes Runtime | Spring Cloud Services pour VMware Tanzu versions antérieures à 3.3.10 | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry versions antérieures à 10.2.3+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Concourse pour VMware Tanzu versions antérieures à 7.14.1+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry isolation segment versions antérieures à 10.2.3+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Platform Services pour VMware Tanzu Platform versions antérieures à 10.3.0 | ||
| VMware | Tanzu Kubernetes Runtime | Ruby Buildpack versions antérieures à 1.10.46 | ||
| VMware | Tanzu Kubernetes Runtime | Elastic Application Runtime pour VMware Tanzu Platform versions antérieures à 6.0.21+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Telemetry pour VMware Tanzu Platform versions antérieures à 2.3.0 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Noble) versions antérieures à 1.103.x | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Hub versions antérieures à 10.3.0 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy) versions antérieures à 1.906.x |
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "GenAI sur Tanzu Platform pour Cloud Foundry versions ant\u00e9rieures \u00e0 10.2.5",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry versions ant\u00e9rieures \u00e0 6.0.20+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Noble) versions ant\u00e9rieures \u00e0 1.90.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "NodeJS Buildpack versions ant\u00e9rieures \u00e0 1.8.58",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Python Buildpack versions ant\u00e9rieures \u00e0 1.8.63",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "VMware Tanzu pour MySQL sur Tanzu Platform versions ant\u00e9rieures \u00e0 10.1.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "API Gateway pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 2.4.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "PHP Buildpack versions ant\u00e9rieures \u00e0 4.6.49",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Single Sign-On pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 1.16.14",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy FIPS) versions ant\u00e9rieures \u00e0 1.915.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "CredHub Service Broker versions ant\u00e9rieures \u00e0 1.6.6",
"product": {
"name": "Tanzu Application Service",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy FIPS) versions ant\u00e9rieures \u00e0 1.943.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.2.4+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry Windows versions ant\u00e9rieures \u00e0 6.0.20+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy) versions ant\u00e9rieures \u00e0 1.915.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry Windows versions ant\u00e9rieures \u00e0 10.2.3+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Single Sign-On pour VMware Tanzu Application Service versions ant\u00e9rieures \u00e0 1.16.13",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy) versions ant\u00e9rieures \u00e0 1.943.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry isolation segment versions ant\u00e9rieures \u00e0 6.0.20+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Noble) versions ant\u00e9rieures \u00e0 1.77.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Platform Automation Toolkit versions ant\u00e9rieures \u00e0 5.3.2",
"product": {
"name": "Services Suite",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy Azure Light) versions ant\u00e9rieures \u00e0 1.906.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Spring Cloud Data Flow pour VMware Tanzu versions ant\u00e9rieures \u00e0 1.14.9",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "App Autoscaler CLI Plugin pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 250.5.9",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Spring Cloud Services pour VMware Tanzu versions ant\u00e9rieures \u00e0 3.3.10",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry versions ant\u00e9rieures \u00e0 10.2.3+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Concourse pour VMware Tanzu versions ant\u00e9rieures \u00e0 7.14.1+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry isolation segment versions ant\u00e9rieures \u00e0 10.2.3+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Platform Services pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.3.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Ruby Buildpack versions ant\u00e9rieures \u00e0 1.10.46",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Elastic Application Runtime pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 6.0.21+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Telemetry pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 2.3.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Noble) versions ant\u00e9rieures \u00e0 1.103.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Hub versions ant\u00e9rieures \u00e0 10.3.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy) versions ant\u00e9rieures \u00e0 1.906.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2006-3082",
"url": "https://www.cve.org/CVERecord?id=CVE-2006-3082"
},
{
"name": "CVE-2013-2064",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-2064"
},
{
"name": "CVE-2014-8140",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-8140"
},
{
"name": "CVE-2014-8139",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-8139"
},
{
"name": "CVE-2014-8141",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-8141"
},
{
"name": "CVE-2015-4779",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4779"
},
{
"name": "CVE-2015-4780",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4780"
},
{
"name": "CVE-2015-4787",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4787"
},
{
"name": "CVE-2015-4790",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4790"
},
{
"name": "CVE-2015-4778",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4778"
},
{
"name": "CVE-2015-4782",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4782"
},
{
"name": "CVE-2015-4789",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4789"
},
{
"name": "CVE-2015-4764",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4764"
},
{
"name": "CVE-2015-4783",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4783"
},
{
"name": "CVE-2015-2583",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2583"
},
{
"name": "CVE-2015-4781",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4781"
},
{
"name": "CVE-2015-4776",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4776"
},
{
"name": "CVE-2015-4786",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4786"
},
{
"name": "CVE-2015-2656",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2656"
},
{
"name": "CVE-2015-4788",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4788"
},
{
"name": "CVE-2015-4785",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4785"
},
{
"name": "CVE-2015-4754",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4754"
},
{
"name": "CVE-2015-4775",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4775"
},
{
"name": "CVE-2015-4777",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4777"
},
{
"name": "CVE-2015-2640",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2640"
},
{
"name": "CVE-2015-4774",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4774"
},
{
"name": "CVE-2015-2626",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2626"
},
{
"name": "CVE-2015-2624",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2624"
},
{
"name": "CVE-2015-4784",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4784"
},
{
"name": "CVE-2015-2654",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2654"
},
{
"name": "CVE-2017-7244",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7244"
},
{
"name": "CVE-2017-6004",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6004"
},
{
"name": "CVE-2017-7186",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7186"
},
{
"name": "CVE-2017-7246",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7246"
},
{
"name": "CVE-2018-10919",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-10919"
},
{
"name": "CVE-2020-2754",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2754"
},
{
"name": "CVE-2020-2756",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2756"
},
{
"name": "CVE-2020-2805",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2805"
},
{
"name": "CVE-2020-2830",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2830"
},
{
"name": "CVE-2020-2757",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2757"
},
{
"name": "CVE-2020-2800",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2800"
},
{
"name": "CVE-2020-2803",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2803"
},
{
"name": "CVE-2020-2755",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2755"
},
{
"name": "CVE-2020-2781",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2781"
},
{
"name": "CVE-2020-2773",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2773"
},
{
"name": "CVE-2019-13136",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-13136"
},
{
"name": "CVE-2020-14579",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14579"
},
{
"name": "CVE-2020-14577",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14577"
},
{
"name": "CVE-2020-14578",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14578"
},
{
"name": "CVE-2020-14621",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14621"
},
{
"name": "CVE-2020-14583",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14583"
},
{
"name": "CVE-2020-14581",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14581"
},
{
"name": "CVE-2020-14664",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14664"
},
{
"name": "CVE-2020-14593",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14593"
},
{
"name": "CVE-2020-14556",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14556"
},
{
"name": "CVE-2019-19906",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-19906"
},
{
"name": "CVE-2019-12900",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-12900"
},
{
"name": "CVE-2020-14796",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14796"
},
{
"name": "CVE-2020-14803",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14803"
},
{
"name": "CVE-2020-14792",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14792"
},
{
"name": "CVE-2020-14779",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14779"
},
{
"name": "CVE-2020-14798",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14798"
},
{
"name": "CVE-2020-14797",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14797"
},
{
"name": "CVE-2020-14781",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14781"
},
{
"name": "CVE-2020-14782",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14782"
},
{
"name": "CVE-2020-14155",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14155"
},
{
"name": "CVE-2019-20838",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20838"
},
{
"name": "CVE-2019-25013",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-25013"
},
{
"name": "CVE-2020-28196",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-28196"
},
{
"name": "CVE-2021-2161",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2161"
},
{
"name": "CVE-2021-2163",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2163"
},
{
"name": "CVE-2021-25217",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-25217"
},
{
"name": "CVE-2019-13232",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-13232"
},
{
"name": "CVE-2021-0561",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0561"
},
{
"name": "CVE-2021-29921",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-29921"
},
{
"name": "CVE-2014-3577",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-3577"
},
{
"name": "CVE-2012-6153",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-6153"
},
{
"name": "CVE-2015-5262",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-5262"
},
{
"name": "CVE-2020-8908",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-8908"
},
{
"name": "CVE-2021-2388",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2388"
},
{
"name": "CVE-2021-2341",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2341"
},
{
"name": "CVE-2021-2369",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2369"
},
{
"name": "CVE-2020-10029",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10029"
},
{
"name": "CVE-2013-0340",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-0340"
},
{
"name": "CVE-2019-18276",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-18276"
},
{
"name": "CVE-2021-3520",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3520"
},
{
"name": "CVE-2021-3421",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3421"
},
{
"name": "CVE-2021-3326",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3326"
},
{
"name": "CVE-2019-2708",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-2708"
},
{
"name": "CVE-2020-27618",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27618"
},
{
"name": "CVE-2021-36222",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36222"
},
{
"name": "CVE-2021-35603",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35603"
},
{
"name": "CVE-2021-35560",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35560"
},
{
"name": "CVE-2021-35586",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35586"
},
{
"name": "CVE-2021-35559",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35559"
},
{
"name": "CVE-2021-35567",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35567"
},
{
"name": "CVE-2021-35578",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35578"
},
{
"name": "CVE-2021-35550",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35550"
},
{
"name": "CVE-2021-35561",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35561"
},
{
"name": "CVE-2021-35565",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35565"
},
{
"name": "CVE-2021-35588",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35588"
},
{
"name": "CVE-2021-35564",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35564"
},
{
"name": "CVE-2021-35556",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35556"
},
{
"name": "CVE-2021-43527",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43527"
},
{
"name": "CVE-2021-44717",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44717"
},
{
"name": "CVE-2021-36221",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36221"
},
{
"name": "CVE-2021-29923",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-29923"
},
{
"name": "CVE-2021-34558",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-34558"
},
{
"name": "CVE-2021-36976",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36976"
},
{
"name": "CVE-2022-21349",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21349"
},
{
"name": "CVE-2022-21291",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21291"
},
{
"name": "CVE-2022-21340",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21340"
},
{
"name": "CVE-2022-21282",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21282"
},
{
"name": "CVE-2022-21271",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21271"
},
{
"name": "CVE-2022-21341",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21341"
},
{
"name": "CVE-2022-21365",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21365"
},
{
"name": "CVE-2022-21305",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21305"
},
{
"name": "CVE-2022-21366",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21366"
},
{
"name": "CVE-2022-21360",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21360"
},
{
"name": "CVE-2022-21296",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21296"
},
{
"name": "CVE-2022-21293",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21293"
},
{
"name": "CVE-2022-21248",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21248"
},
{
"name": "CVE-2022-21299",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21299"
},
{
"name": "CVE-2022-21294",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21294"
},
{
"name": "CVE-2022-21283",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21283"
},
{
"name": "CVE-2021-3737",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3737"
},
{
"name": "CVE-2021-44716",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44716"
},
{
"name": "CVE-2021-3733",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3733"
},
{
"name": "CVE-2021-41772",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41772"
},
{
"name": "CVE-2021-41771",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41771"
},
{
"name": "CVE-2022-37967",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-37967"
},
{
"name": "CVE-2022-45061",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45061"
},
{
"name": "CVE-2022-40674",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40674"
},
{
"name": "CVE-2022-3602",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3602"
},
{
"name": "CVE-2022-37434",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-37434"
},
{
"name": "CVE-2022-2309",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2309"
},
{
"name": "CVE-2022-43680",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43680"
},
{
"name": "CVE-2022-29824",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29824"
},
{
"name": "CVE-2022-23308",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23308"
},
{
"name": "CVE-2022-35737",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-35737"
},
{
"name": "CVE-2022-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40303"
},
{
"name": "CVE-2022-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40304"
},
{
"name": "CVE-2022-21476",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21476"
},
{
"name": "CVE-2022-42898",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42898"
},
{
"name": "CVE-2022-30633",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30633"
},
{
"name": "CVE-2022-1705",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1705"
},
{
"name": "CVE-2022-27664",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27664"
},
{
"name": "CVE-2022-28131",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28131"
},
{
"name": "CVE-2022-32148",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32148"
},
{
"name": "CVE-2022-32189",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32189"
},
{
"name": "CVE-2022-1962",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1962"
},
{
"name": "CVE-2022-30635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30635"
},
{
"name": "CVE-2022-30631",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30631"
},
{
"name": "CVE-2022-30632",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30632"
},
{
"name": "CVE-2022-30630",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30630"
},
{
"name": "CVE-2022-0696",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0696"
},
{
"name": "CVE-2022-3786",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3786"
},
{
"name": "CVE-2022-0714",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0714"
},
{
"name": "CVE-2022-29526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29526"
},
{
"name": "CVE-2022-34903",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34903"
},
{
"name": "CVE-2022-3515",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3515"
},
{
"name": "CVE-2022-32205",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32205"
},
{
"name": "CVE-2022-32206",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32206"
},
{
"name": "CVE-2018-25032",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-25032"
},
{
"name": "CVE-2022-3996",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3996"
},
{
"name": "CVE-2022-22942",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22942"
},
{
"name": "CVE-2022-23773",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23773"
},
{
"name": "CVE-2022-0391",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0391"
},
{
"name": "CVE-2022-23772",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23772"
},
{
"name": "CVE-2022-23806",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23806"
},
{
"name": "CVE-2022-0158",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0158"
},
{
"name": "CVE-2022-0156",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0156"
},
{
"name": "CVE-2018-11813",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11813"
},
{
"name": "CVE-2018-1000075",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000075"
},
{
"name": "CVE-2018-18384",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-18384"
},
{
"name": "CVE-2019-8325",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8325"
},
{
"name": "CVE-2019-8322",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8322"
},
{
"name": "CVE-2018-1000073",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000073"
},
{
"name": "CVE-2018-1000079",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000079"
},
{
"name": "CVE-2019-8324",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8324"
},
{
"name": "CVE-2018-1000076",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000076"
},
{
"name": "CVE-2018-1000074",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000074"
},
{
"name": "CVE-2018-1000078",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000078"
},
{
"name": "CVE-2018-1000077",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000077"
},
{
"name": "CVE-2019-1010238",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-1010238"
},
{
"name": "CVE-2019-8323",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8323"
},
{
"name": "CVE-2022-0351",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0351"
},
{
"name": "CVE-2022-0319",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0319"
},
{
"name": "CVE-2022-21434",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21434"
},
{
"name": "CVE-2022-21443",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21443"
},
{
"name": "CVE-2022-21496",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21496"
},
{
"name": "CVE-2022-21426",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21426"
},
{
"name": "CVE-2021-20266",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20266"
},
{
"name": "CVE-2022-24921",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24921"
},
{
"name": "CVE-2022-1434",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1434"
},
{
"name": "CVE-2022-1292",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1292"
},
{
"name": "CVE-2022-1343",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1343"
},
{
"name": "CVE-2022-1473",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1473"
},
{
"name": "CVE-2022-0530",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0530"
},
{
"name": "CVE-2021-3521",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3521"
},
{
"name": "CVE-2021-39293",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-39293"
},
{
"name": "CVE-2022-27774",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27774"
},
{
"name": "CVE-2022-27775",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27775"
},
{
"name": "CVE-2022-22576",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22576"
},
{
"name": "CVE-2022-27776",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27776"
},
{
"name": "CVE-2022-2068",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2068"
},
{
"name": "CVE-2022-2097",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2097"
},
{
"name": "CVE-2022-24407",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24407"
},
{
"name": "CVE-2017-7500",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7500"
},
{
"name": "CVE-2021-33574",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33574"
},
{
"name": "CVE-2017-11164",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-11164"
},
{
"name": "CVE-2021-37750",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37750"
},
{
"name": "CVE-2022-21541",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21541"
},
{
"name": "CVE-2022-34169",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34169"
},
{
"name": "CVE-2022-21540",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21540"
},
{
"name": "CVE-2022-24070",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24070"
},
{
"name": "CVE-2021-28544",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-28544"
},
{
"name": "CVE-2021-31566",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31566"
},
{
"name": "CVE-2021-23177",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23177"
},
{
"name": "CVE-2021-3999",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3999"
},
{
"name": "CVE-2022-23218",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23218"
},
{
"name": "CVE-2022-23219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23219"
},
{
"name": "CVE-2022-28327",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28327"
},
{
"name": "CVE-2022-24675",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24675"
},
{
"name": "CVE-2022-27782",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27782"
},
{
"name": "CVE-2022-38476",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38476"
},
{
"name": "CVE-2022-26488",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26488"
},
{
"name": "CVE-2022-32208",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32208"
},
{
"name": "CVE-2022-27781",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27781"
},
{
"name": "CVE-2022-32207",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32207"
},
{
"name": "CVE-2022-3358",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3358"
},
{
"name": "CVE-2022-1271",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1271"
},
{
"name": "CVE-2021-4189",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4189"
},
{
"name": "CVE-2012-5783",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-5783"
},
{
"name": "CVE-2022-1587",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1587"
},
{
"name": "CVE-2022-21626",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21626"
},
{
"name": "CVE-2022-21619",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21619"
},
{
"name": "CVE-2022-21628",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21628"
},
{
"name": "CVE-2022-21624",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21624"
},
{
"name": "CVE-2022-1725",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1725"
},
{
"name": "CVE-2022-29458",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29458"
},
{
"name": "CVE-2022-28739",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28739"
},
{
"name": "CVE-2022-1897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1897"
},
{
"name": "CVE-2022-1420",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1420"
},
{
"name": "CVE-2021-39537",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-39537"
},
{
"name": "CVE-2022-1674",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1674"
},
{
"name": "CVE-2022-1622",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1622"
},
{
"name": "CVE-2022-37454",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-37454"
},
{
"name": "CVE-2023-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21830"
},
{
"name": "CVE-2023-21843",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21843"
},
{
"name": "CVE-2020-10735",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10735"
},
{
"name": "CVE-2022-32221",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32221"
},
{
"name": "CVE-2022-42916",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42916"
},
{
"name": "CVE-2022-35252",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-35252"
},
{
"name": "CVE-2022-42915",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42915"
},
{
"name": "CVE-2022-43551",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43551"
},
{
"name": "CVE-2022-43552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43552"
},
{
"name": "CVE-2022-40897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
},
{
"name": "CVE-2022-4304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4304"
},
{
"name": "CVE-2022-4203",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4203"
},
{
"name": "CVE-2023-0286",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0286"
},
{
"name": "CVE-2023-0401",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0401"
},
{
"name": "CVE-2023-0215",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0215"
},
{
"name": "CVE-2023-0217",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0217"
},
{
"name": "CVE-2023-0216",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0216"
},
{
"name": "CVE-2022-4450",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4450"
},
{
"name": "CVE-2023-0767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0767"
},
{
"name": "CVE-2015-20107",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-20107"
},
{
"name": "CVE-2022-1586",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1586"
},
{
"name": "CVE-2022-25147",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25147"
},
{
"name": "CVE-2022-45873",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45873"
},
{
"name": "CVE-2022-4415",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4415"
},
{
"name": "CVE-2022-3821",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3821"
},
{
"name": "CVE-2023-23915",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23915"
},
{
"name": "CVE-2023-23914",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23914"
},
{
"name": "CVE-2023-23916",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23916"
},
{
"name": "CVE-2022-1304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1304"
},
{
"name": "CVE-2023-24329",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24329"
},
{
"name": "CVE-2023-23931",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23931"
},
{
"name": "CVE-2022-41717",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41717"
},
{
"name": "CVE-2023-0464",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0464"
},
{
"name": "CVE-2022-2879",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2879"
},
{
"name": "CVE-2022-41715",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41715"
},
{
"name": "CVE-2022-2880",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2880"
},
{
"name": "CVE-2022-41716",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41716"
},
{
"name": "CVE-2023-0466",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0466"
},
{
"name": "CVE-2023-0465",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0465"
},
{
"name": "CVE-2023-0614",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0614"
},
{
"name": "CVE-2022-32743",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32743"
},
{
"name": "CVE-2023-0922",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0922"
},
{
"name": "CVE-2022-30629",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30629"
},
{
"name": "CVE-2022-41723",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41723"
},
{
"name": "CVE-2022-41722",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41722"
},
{
"name": "CVE-2022-30580",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30580"
},
{
"name": "CVE-2022-41720",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41720"
},
{
"name": "CVE-2022-41725",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41725"
},
{
"name": "CVE-2022-41724",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41724"
},
{
"name": "CVE-2021-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46828"
},
{
"name": "CVE-2021-33621",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33621"
},
{
"name": "CVE-2023-21937",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21937"
},
{
"name": "CVE-2023-21939",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21939"
},
{
"name": "CVE-2023-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21967"
},
{
"name": "CVE-2023-21930",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21930"
},
{
"name": "CVE-2023-21968",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21968"
},
{
"name": "CVE-2023-21938",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21938"
},
{
"name": "CVE-2023-21954",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21954"
},
{
"name": "CVE-2023-24532",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24532"
},
{
"name": "CVE-2023-24537",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24537"
},
{
"name": "CVE-2023-29469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29469"
},
{
"name": "CVE-2023-28484",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28484"
},
{
"name": "CVE-2023-20873",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-20873"
},
{
"name": "CVE-2023-20883",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-20883"
},
{
"name": "CVE-2023-2650",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2650"
},
{
"name": "CVE-2023-27535",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27535"
},
{
"name": "CVE-2022-25858",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25858"
},
{
"name": "CVE-2022-30634",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30634"
},
{
"name": "CVE-2022-36227",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36227"
},
{
"name": "CVE-2023-27533",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27533"
},
{
"name": "CVE-2023-27538",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27538"
},
{
"name": "CVE-2023-27534",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27534"
},
{
"name": "CVE-2023-27536",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27536"
},
{
"name": "CVE-2022-27780",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27780"
},
{
"name": "CVE-2022-29804",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29804"
},
{
"name": "CVE-2023-27537",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27537"
},
{
"name": "CVE-2020-1752",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-1752"
},
{
"name": "CVE-2021-35942",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35942"
},
{
"name": "CVE-2021-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38604"
},
{
"name": "CVE-2020-29562",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-29562"
},
{
"name": "CVE-2021-27645",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-27645"
},
{
"name": "CVE-2023-24536",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24536"
},
{
"name": "CVE-2023-24538",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24538"
},
{
"name": "CVE-2023-1255",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1255"
},
{
"name": "CVE-2016-3189",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-3189"
},
{
"name": "CVE-2021-45346",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-45346"
},
{
"name": "CVE-2023-28322",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28322"
},
{
"name": "CVE-2022-46908",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-46908"
},
{
"name": "CVE-2023-28320",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28320"
},
{
"name": "CVE-2023-28321",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28321"
},
{
"name": "CVE-2023-24540",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24540"
},
{
"name": "CVE-2023-29400",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29400"
},
{
"name": "CVE-2023-24539",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24539"
},
{
"name": "CVE-2021-28861",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-28861"
},
{
"name": "CVE-2023-2975",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2975"
},
{
"name": "CVE-2023-22049",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22049"
},
{
"name": "CVE-2023-25193",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25193"
},
{
"name": "CVE-2023-22045",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22045"
},
{
"name": "CVE-2022-4899",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4899"
},
{
"name": "CVE-2023-0361",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0361"
},
{
"name": "CVE-2023-3446",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3446"
},
{
"name": "CVE-2023-28319",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28319"
},
{
"name": "CVE-2023-34967",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34967"
},
{
"name": "CVE-2023-34968",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34968"
},
{
"name": "CVE-2023-3817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3817"
},
{
"name": "CVE-2023-29404",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29404"
},
{
"name": "CVE-2023-29402",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29402"
},
{
"name": "CVE-2023-29403",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29403"
},
{
"name": "CVE-2023-29405",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29405"
},
{
"name": "CVE-2023-2283",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2283"
},
{
"name": "CVE-2023-1667",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1667"
},
{
"name": "CVE-2023-2976",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2976"
},
{
"name": "CVE-2021-38297",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38297"
},
{
"name": "CVE-2023-29409",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29409"
},
{
"name": "CVE-2023-29406",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29406"
},
{
"name": "CVE-2023-40403",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40403"
},
{
"name": "CVE-2023-4911",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4911"
},
{
"name": "CVE-2023-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44487"
},
{
"name": "CVE-2023-4091",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4091"
},
{
"name": "CVE-2023-42670",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-42670"
},
{
"name": "CVE-2023-4154",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4154"
},
{
"name": "CVE-2023-42669",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-42669"
},
{
"name": "CVE-2016-1000027",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000027"
},
{
"name": "CVE-2023-35116",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35116"
},
{
"name": "CVE-2023-38039",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38039"
},
{
"name": "CVE-2023-22081",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22081"
},
{
"name": "CVE-2023-22025",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22025"
},
{
"name": "CVE-2023-22067",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22067"
},
{
"name": "CVE-2023-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38546"
},
{
"name": "CVE-2023-38545",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38545"
},
{
"name": "CVE-2023-5363",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5363"
},
{
"name": "CVE-2023-4807",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4807"
},
{
"name": "CVE-2023-30774",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30774"
},
{
"name": "CVE-2023-45853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45853"
},
{
"name": "CVE-2023-5678",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5678"
},
{
"name": "CVE-2023-40217",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40217"
},
{
"name": "CVE-2022-1615",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1615"
},
{
"name": "CVE-2020-22218",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-22218"
},
{
"name": "CVE-2023-2603",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2603"
},
{
"name": "CVE-2023-2602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2602"
},
{
"name": "CVE-2023-4527",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4527"
},
{
"name": "CVE-2023-4813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4813"
},
{
"name": "CVE-2023-4806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4806"
},
{
"name": "CVE-2022-48303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48303"
},
{
"name": "CVE-2021-3426",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3426"
},
{
"name": "CVE-2023-34055",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34055"
},
{
"name": "CVE-2022-41409",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41409"
},
{
"name": "CVE-2022-0563",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0563"
},
{
"name": "CVE-2023-32643",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32643"
},
{
"name": "CVE-2023-4039",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4039"
},
{
"name": "CVE-2022-2509",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2509"
},
{
"name": "CVE-2022-3715",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3715"
},
{
"name": "CVE-2023-0687",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0687"
},
{
"name": "CVE-2023-5156",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5156"
},
{
"name": "CVE-2022-48522",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48522"
},
{
"name": "CVE-2023-29491",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29491"
},
{
"name": "CVE-2023-35945",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35945"
},
{
"name": "CVE-2023-32665",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32665"
},
{
"name": "CVE-2023-39615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39615"
},
{
"name": "CVE-2021-37600",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37600"
},
{
"name": "CVE-2021-46848",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46848"
},
{
"name": "CVE-2021-3997",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3997"
},
{
"name": "CVE-2021-33294",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33294"
},
{
"name": "CVE-2021-43618",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43618"
},
{
"name": "CVE-2023-45322",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45322"
},
{
"name": "CVE-2023-29499",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29499"
},
{
"name": "CVE-2022-28321",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28321"
},
{
"name": "CVE-2021-32292",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32292"
},
{
"name": "CVE-2023-4016",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4016"
},
{
"name": "CVE-2013-4235",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-4235"
},
{
"name": "CVE-2023-34969",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34969"
},
{
"name": "CVE-2023-32611",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32611"
},
{
"name": "CVE-2023-29383",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29383"
},
{
"name": "CVE-2023-5981",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5981"
},
{
"name": "CVE-2023-32636",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32636"
},
{
"name": "CVE-2023-51385",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51385"
},
{
"name": "CVE-2023-51384",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51384"
},
{
"name": "CVE-2023-48795",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48795"
},
{
"name": "CVE-2024-20696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20696"
},
{
"name": "CVE-2023-6237",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6237"
},
{
"name": "CVE-2024-20918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20918"
},
{
"name": "CVE-2024-20945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20945"
},
{
"name": "CVE-2024-20952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20952"
},
{
"name": "CVE-2024-20919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20919"
},
{
"name": "CVE-2024-20926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20926"
},
{
"name": "CVE-2024-20921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20921"
},
{
"name": "CVE-2023-39323",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39323"
},
{
"name": "CVE-2024-0743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0743"
},
{
"name": "CVE-2024-0746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0746"
},
{
"name": "CVE-2023-31484",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31484"
},
{
"name": "CVE-2021-4048",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4048"
},
{
"name": "CVE-2023-36054",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36054"
},
{
"name": "CVE-2023-28487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28487"
},
{
"name": "CVE-2023-30086",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30086"
},
{
"name": "CVE-2023-26965",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26965"
},
{
"name": "CVE-2022-42919",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42919"
},
{
"name": "CVE-2023-3316",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3316"
},
{
"name": "CVE-2023-28486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28486"
},
{
"name": "CVE-2022-28738",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28738"
},
{
"name": "CVE-2023-50868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50868"
},
{
"name": "CVE-2023-2804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2804"
},
{
"name": "CVE-2023-7104",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7104"
},
{
"name": "CVE-2023-24534",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24534"
},
{
"name": "CVE-2023-6129",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6129"
},
{
"name": "CVE-2023-46218",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46218"
},
{
"name": "CVE-2023-46219",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46219"
},
{
"name": "CVE-2023-39318",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39318"
},
{
"name": "CVE-2023-39319",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39319"
},
{
"name": "CVE-2024-0727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0727"
},
{
"name": "CVE-2024-25126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25126"
},
{
"name": "CVE-2024-26141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26141"
},
{
"name": "CVE-2024-26146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26146"
},
{
"name": "CVE-2023-47038",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47038"
},
{
"name": "CVE-2022-48554",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48554"
},
{
"name": "CVE-2023-39325",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39325"
},
{
"name": "CVE-2024-24762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24762"
},
{
"name": "CVE-2023-52593",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52593"
},
{
"name": "CVE-2023-5388",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5388"
},
{
"name": "CVE-2022-2127",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2127"
},
{
"name": "CVE-2023-27043",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27043"
},
{
"name": "CVE-2023-6481",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6481"
},
{
"name": "CVE-2023-36632",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36632"
},
{
"name": "CVE-2024-28085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28085"
},
{
"name": "CVE-2024-2511",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2511"
},
{
"name": "CVE-2024-26256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26256"
},
{
"name": "CVE-2020-22916",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-22916"
},
{
"name": "CVE-2016-2781",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-2781"
},
{
"name": "CVE-2023-3978",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3978"
},
{
"name": "CVE-2023-49083",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-49083"
},
{
"name": "CVE-2017-7501",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7501"
},
{
"name": "CVE-2021-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35939"
},
{
"name": "CVE-2024-0553",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0553"
},
{
"name": "CVE-2021-35938",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35938"
},
{
"name": "CVE-2023-50782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50782"
},
{
"name": "CVE-2021-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35937"
},
{
"name": "CVE-2023-6597",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6597"
},
{
"name": "CVE-2023-52426",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52426"
},
{
"name": "CVE-2024-21011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21011"
},
{
"name": "CVE-2024-21094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21094"
},
{
"name": "CVE-2024-21068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21068"
},
{
"name": "CVE-2024-21085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21085"
},
{
"name": "CVE-2024-26775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26775"
},
{
"name": "CVE-2024-26726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26726"
},
{
"name": "CVE-2024-26700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26700"
},
{
"name": "CVE-2023-39326",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39326"
},
{
"name": "CVE-2023-45283",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45283"
},
{
"name": "CVE-2023-45285",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45285"
},
{
"name": "CVE-2023-45284",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45284"
},
{
"name": "CVE-2007-4559",
"url": "https://www.cve.org/CVERecord?id=CVE-2007-4559"
},
{
"name": "CVE-2023-52425",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52425"
},
{
"name": "CVE-2023-47282",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47282"
},
{
"name": "CVE-2023-47169",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47169"
},
{
"name": "CVE-2023-48368",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48368"
},
{
"name": "CVE-2023-22656",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22656"
},
{
"name": "CVE-2024-28182",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28182"
},
{
"name": "CVE-2023-45288",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45288"
},
{
"name": "CVE-2024-4603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4603"
},
{
"name": "CVE-2023-6378",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6378"
},
{
"name": "CVE-2023-31486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31486"
},
{
"name": "CVE-2022-48703",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48703"
},
{
"name": "CVE-2024-26896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26896"
},
{
"name": "CVE-2018-14628",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14628"
},
{
"name": "CVE-2023-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38037"
},
{
"name": "CVE-2023-45289",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45289"
},
{
"name": "CVE-2023-45290",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45290"
},
{
"name": "CVE-2024-24783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24783"
},
{
"name": "CVE-2024-24784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24784"
},
{
"name": "CVE-2024-24785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24785"
},
{
"name": "CVE-2024-4741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4741"
},
{
"name": "CVE-2025-38727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38727"
},
{
"name": "CVE-2025-38237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38237"
},
{
"name": "CVE-2025-38514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38514"
},
{
"name": "CVE-2025-38542",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38542"
},
{
"name": "CVE-2025-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38569"
},
{
"name": "CVE-2023-51074",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51074"
},
{
"name": "CVE-2025-9231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9231"
},
{
"name": "CVE-2025-41244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41244"
},
{
"name": "CVE-2025-9230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9230"
},
{
"name": "CVE-2025-9232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9232"
},
{
"name": "CVE-2025-61984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61984"
},
{
"name": "CVE-2025-8291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8291"
},
{
"name": "CVE-2025-55248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55248"
},
{
"name": "CVE-2024-28757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28757"
},
{
"name": "CVE-2025-58754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58754"
},
{
"name": "CVE-2025-55315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55315"
},
{
"name": "CVE-2024-24786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24786"
},
{
"name": "CVE-2024-29857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29857"
},
{
"name": "CVE-2024-30171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30171"
},
{
"name": "CVE-2024-30172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30172"
},
{
"name": "CVE-2024-5535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5535"
},
{
"name": "CVE-2025-9640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9640"
},
{
"name": "CVE-2021-36770",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36770"
},
{
"name": "CVE-2023-5752",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5752"
},
{
"name": "CVE-2024-2004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2004"
},
{
"name": "CVE-2024-2398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2398"
},
{
"name": "CVE-2024-0397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0397"
},
{
"name": "CVE-2024-4030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4030"
},
{
"name": "CVE-2024-4032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4032"
},
{
"name": "CVE-2024-5642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5642"
},
{
"name": "CVE-2024-34750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34750"
},
{
"name": "CVE-2024-3596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3596"
},
{
"name": "CVE-2025-41254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41254"
},
{
"name": "CVE-2023-6004",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6004"
},
{
"name": "CVE-2023-6918",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6918"
},
{
"name": "CVE-2024-0450",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0450"
},
{
"name": "CVE-2024-25062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25062"
},
{
"name": "CVE-2024-26458",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26458"
},
{
"name": "CVE-2024-26461",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26461"
},
{
"name": "CVE-2024-28834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28834"
},
{
"name": "CVE-2024-2961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2961"
},
{
"name": "CVE-2024-33599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33599"
},
{
"name": "CVE-2024-33600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33600"
},
{
"name": "CVE-2024-33601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33601"
},
{
"name": "CVE-2024-33602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33602"
},
{
"name": "CVE-2022-1771",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1771"
},
{
"name": "CVE-2023-46246",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46246"
},
{
"name": "CVE-2023-48231",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48231"
},
{
"name": "CVE-2023-48232",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48232"
},
{
"name": "CVE-2023-48233",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48233"
},
{
"name": "CVE-2023-48234",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48234"
},
{
"name": "CVE-2023-48235",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48235"
},
{
"name": "CVE-2023-48236",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48236"
},
{
"name": "CVE-2023-48237",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48237"
},
{
"name": "CVE-2023-48706",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48706"
},
{
"name": "CVE-2023-4641",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4641"
},
{
"name": "CVE-2023-50495",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50495"
},
{
"name": "CVE-2023-5341",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5341"
},
{
"name": "CVE-2024-0567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0567"
},
{
"name": "CVE-2024-22365",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22365"
},
{
"name": "CVE-2023-46045",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46045"
},
{
"name": "CVE-2024-21131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21131"
},
{
"name": "CVE-2024-21138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21138"
},
{
"name": "CVE-2024-21140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21140"
},
{
"name": "CVE-2024-21144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21144"
},
{
"name": "CVE-2024-21145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21145"
},
{
"name": "CVE-2024-21147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21147"
},
{
"name": "CVE-2018-13440",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-13440"
},
{
"name": "CVE-2019-13147",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-13147"
},
{
"name": "CVE-2022-24599",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24599"
},
{
"name": "CVE-2024-28835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28835"
},
{
"name": "CVE-2021-35452",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35452"
},
{
"name": "CVE-2021-36408",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36408"
},
{
"name": "CVE-2021-36410",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36410"
},
{
"name": "CVE-2021-36411",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36411"
},
{
"name": "CVE-2022-43235",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43235"
},
{
"name": "CVE-2022-43236",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43236"
},
{
"name": "CVE-2022-43237",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43237"
},
{
"name": "CVE-2022-43238",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43238"
},
{
"name": "CVE-2022-43239",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43239"
},
{
"name": "CVE-2022-43240",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43240"
},
{
"name": "CVE-2022-43241",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43241"
},
{
"name": "CVE-2022-43242",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43242"
},
{
"name": "CVE-2022-43243",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43243"
},
{
"name": "CVE-2022-43244",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43244"
},
{
"name": "CVE-2022-43245",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43245"
},
{
"name": "CVE-2022-43248",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43248"
},
{
"name": "CVE-2022-43249",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43249"
},
{
"name": "CVE-2022-43250",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43250"
},
{
"name": "CVE-2022-43252",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43252"
},
{
"name": "CVE-2022-43253",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43253"
},
{
"name": "CVE-2023-24751",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24751"
},
{
"name": "CVE-2023-24752",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24752"
},
{
"name": "CVE-2023-24754",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24754"
},
{
"name": "CVE-2023-24755",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24755"
},
{
"name": "CVE-2023-24756",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24756"
},
{
"name": "CVE-2023-24757",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24757"
},
{
"name": "CVE-2023-24758",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24758"
},
{
"name": "CVE-2023-6228",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6228"
},
{
"name": "CVE-2023-6277",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6277"
},
{
"name": "CVE-2024-6923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6923"
},
{
"name": "CVE-2024-3219",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3219"
},
{
"name": "CVE-2023-45287",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45287"
},
{
"name": "CVE-2023-51767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51767"
},
{
"name": "CVE-2024-24787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24787"
},
{
"name": "CVE-2024-24788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24788"
},
{
"name": "CVE-2025-55551",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55551"
},
{
"name": "CVE-2025-55552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55552"
},
{
"name": "CVE-2025-55554",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55554"
},
{
"name": "CVE-2025-61985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61985"
},
{
"name": "CVE-2025-40778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40778"
},
{
"name": "CVE-2025-40780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40780"
},
{
"name": "CVE-2025-8677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8677"
},
{
"name": "CVE-2025-55754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55754"
},
{
"name": "CVE-2025-55752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55752"
},
{
"name": "CVE-2024-6345",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6345"
},
{
"name": "CVE-2024-38808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38808"
},
{
"name": "CVE-2024-38809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38809"
},
{
"name": "CVE-2025-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58056"
},
{
"name": "CVE-2025-58057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58057"
},
{
"name": "CVE-2025-47910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47910"
},
{
"name": "CVE-2025-8176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8176"
},
{
"name": "CVE-2025-9900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9900"
},
{
"name": "CVE-2025-40025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40025"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53057"
},
{
"name": "CVE-2025-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53066"
},
{
"name": "CVE-2025-61748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61748"
},
{
"name": "CVE-2023-52969",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52969"
},
{
"name": "CVE-2023-52970",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52970"
},
{
"name": "CVE-2024-21510",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21510"
},
{
"name": "CVE-2024-58266",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58266"
},
{
"name": "CVE-2025-46551",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46551"
},
{
"name": "CVE-2025-58767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58767"
},
{
"name": "CVE-2025-59830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59830"
},
{
"name": "CVE-2025-61770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61770"
},
{
"name": "CVE-2025-61771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61771"
},
{
"name": "CVE-2025-61772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61772"
},
{
"name": "CVE-2025-61780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61780"
},
{
"name": "CVE-2025-61919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61919"
},
{
"name": "CVE-2025-61921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61921"
},
{
"name": "CVE-2025-11411",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11411"
},
{
"name": "CVE-2025-62813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62813"
},
{
"name": "CVE-2025-53040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53040"
},
{
"name": "CVE-2025-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53042"
},
{
"name": "CVE-2025-53044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53044"
},
{
"name": "CVE-2025-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53045"
},
{
"name": "CVE-2025-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53053"
},
{
"name": "CVE-2025-53054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53054"
},
{
"name": "CVE-2025-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53062"
},
{
"name": "CVE-2025-53069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53069"
},
{
"name": "CVE-2025-5351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5351"
},
{
"name": "CVE-2025-5987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5987"
},
{
"name": "CVE-2025-61795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61795"
},
{
"name": "CVE-2025-12380",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12380"
},
{
"name": "CVE-2025-11226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11226"
},
{
"name": "CVE-2025-47906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47906"
},
{
"name": "CVE-2025-54388",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54388"
},
{
"name": "CVE-2023-3164",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3164"
},
{
"name": "CVE-2024-1013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1013"
},
{
"name": "CVE-2024-34397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34397"
},
{
"name": "CVE-2024-38428",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38428"
},
{
"name": "CVE-2024-38807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38807"
},
{
"name": "CVE-2023-7008",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7008"
},
{
"name": "CVE-2024-6232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6232"
},
{
"name": "CVE-2024-6119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6119"
},
{
"name": "CVE-2018-3779",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-3779"
},
{
"name": "CVE-2019-8321",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8321"
},
{
"name": "CVE-2020-15095",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-15095"
},
{
"name": "CVE-2021-43809",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43809"
},
{
"name": "CVE-2023-22796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22796"
},
{
"name": "CVE-2023-28120",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28120"
},
{
"name": "CVE-2001-1268",
"url": "https://www.cve.org/CVERecord?id=CVE-2001-1268"
},
{
"name": "CVE-2001-1269",
"url": "https://www.cve.org/CVERecord?id=CVE-2001-1269"
},
{
"name": "CVE-2005-0602",
"url": "https://www.cve.org/CVERecord?id=CVE-2005-0602"
},
{
"name": "CVE-2011-2207",
"url": "https://www.cve.org/CVERecord?id=CVE-2011-2207"
},
{
"name": "CVE-2014-9157",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9157"
},
{
"name": "CVE-2014-9636",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9636"
},
{
"name": "CVE-2014-9748",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9748"
},
{
"name": "CVE-2014-9913",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9913"
},
{
"name": "CVE-2015-1606",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-1606"
},
{
"name": "CVE-2015-7696",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7696"
},
{
"name": "CVE-2015-7697",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7697"
},
{
"name": "CVE-2015-7747",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7747"
},
{
"name": "CVE-2015-8863",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-8863"
},
{
"name": "CVE-2016-10062",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-10062"
},
{
"name": "CVE-2016-20012",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-20012"
},
{
"name": "CVE-2016-5118",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-5118"
},
{
"name": "CVE-2016-5841",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-5841"
},
{
"name": "CVE-2016-7514",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-7514"
},
{
"name": "CVE-2016-7531",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-7531"
},
{
"name": "CVE-2016-9844",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-9844"
},
{
"name": "CVE-2017-1000476",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-1000476"
},
{
"name": "CVE-2017-10928",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-10928"
},
{
"name": "CVE-2017-11447",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-11447"
},
{
"name": "CVE-2017-12429",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-12429"
},
{
"name": "CVE-2017-12433",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-12433"
},
{
"name": "CVE-2017-12643",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-12643"
},
{
"name": "CVE-2017-12674",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-12674"
},
{
"name": "CVE-2017-16231",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-16231"
},
{
"name": "CVE-2017-18250",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-18250"
},
{
"name": "CVE-2017-18253",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-18253"
},
{
"name": "CVE-2017-6829",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6829"
},
{
"name": "CVE-2017-6830",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6830"
},
{
"name": "CVE-2017-6831",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6831"
},
{
"name": "CVE-2017-6832",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6832"
},
{
"name": "CVE-2017-6833",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6833"
},
{
"name": "CVE-2017-6834",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6834"
},
{
"name": "CVE-2017-6835",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6835"
},
{
"name": "CVE-2017-6836",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6836"
},
{
"name": "CVE-2017-6837",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6837"
},
{
"name": "CVE-2017-6838",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6838"
},
{
"name": "CVE-2017-6839",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6839"
},
{
"name": "CVE-2017-7619",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7619"
},
{
"name": "CVE-2017-9409",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-9409"
},
{
"name": "CVE-2018-1000035",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000035"
},
{
"name": "CVE-2018-10804",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-10804"
},
{
"name": "CVE-2018-10805",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-10805"
},
{
"name": "CVE-2018-11655",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11655"
},
{
"name": "CVE-2018-11656",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11656"
},
{
"name": "CVE-2018-12599",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12599"
},
{
"name": "CVE-2018-12600",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12600"
},
{
"name": "CVE-2018-13153",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-13153"
},
{
"name": "CVE-2018-13410",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-13410"
},
{
"name": "CVE-2018-14434",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14434"
},
{
"name": "CVE-2018-14437",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14437"
},
{
"name": "CVE-2018-15120",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-15120"
},
{
"name": "CVE-2018-15607",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-15607"
},
{
"name": "CVE-2018-15798",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-15798"
},
{
"name": "CVE-2018-16328",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16328"
},
{
"name": "CVE-2018-16329",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16329"
},
{
"name": "CVE-2018-16412",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16412"
},
{
"name": "CVE-2018-16645",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16645"
},
{
"name": "CVE-2018-19876",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-19876"
},
{
"name": "CVE-2018-9133",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-9133"
},
{
"name": "CVE-2018-9135",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-9135"
},
{
"name": "CVE-2019-14844",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-14844"
},
{
"name": "CVE-2019-17547",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-17547"
},
{
"name": "CVE-2019-3792",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-3792"
},
{
"name": "CVE-2019-6293",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-6293"
},
{
"name": "CVE-2019-6461",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-6461"
},
{
"name": "CVE-2019-6462",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-6462"
},
{
"name": "CVE-2019-9904",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-9904"
},
{
"name": "CVE-2020-0499",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-0499"
},
{
"name": "CVE-2020-10251",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10251"
},
{
"name": "CVE-2020-14152",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14152"
},
{
"name": "CVE-2020-14153",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14153"
},
{
"name": "CVE-2020-18032",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-18032"
},
{
"name": "CVE-2020-18781",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-18781"
},
{
"name": "CVE-2020-21599",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-21599"
},
{
"name": "CVE-2020-21605",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-21605"
},
{
"name": "CVE-2020-21606",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-21606"
},
{
"name": "CVE-2020-25663",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-25663"
},
{
"name": "CVE-2020-27768",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27768"
},
{
"name": "CVE-2020-27769",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27769"
},
{
"name": "CVE-2020-27776",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27776"
},
{
"name": "CVE-2020-27829",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27829"
},
{
"name": "CVE-2020-29509",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-29509"
},
{
"name": "CVE-2020-29511",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-29511"
},
{
"name": "CVE-2020-35492",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-35492"
},
{
"name": "CVE-2021-20176",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20176"
},
{
"name": "CVE-2016-4074",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-4074"
},
{
"name": "CVE-2021-20241",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20241"
},
{
"name": "CVE-2021-20243",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20243"
},
{
"name": "CVE-2021-20244",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20244"
},
{
"name": "CVE-2021-20245",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20245"
},
{
"name": "CVE-2021-20246",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20246"
},
{
"name": "CVE-2021-20251",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20251"
},
{
"name": "CVE-2021-20309",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20309"
},
{
"name": "CVE-2021-20310",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20310"
},
{
"name": "CVE-2021-20311",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20311"
},
{
"name": "CVE-2021-20312",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20312"
},
{
"name": "CVE-2021-20313",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20313"
},
{
"name": "CVE-2021-23215",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23215"
},
{
"name": "CVE-2021-24031",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-24031"
},
{
"name": "CVE-2021-24032",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-24032"
},
{
"name": "CVE-2021-26260",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-26260"
},
{
"name": "CVE-2021-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-26720"
},
{
"name": "CVE-2021-26945",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-26945"
},
{
"name": "CVE-2021-31879",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31879"
},
{
"name": "CVE-2021-32490",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32490"
},
{
"name": "CVE-2021-32491",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32491"
},
{
"name": "CVE-2021-32492",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32492"
},
{
"name": "CVE-2021-32493",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32493"
},
{
"name": "CVE-2021-3468",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3468"
},
{
"name": "CVE-2021-3500",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3500"
},
{
"name": "CVE-2021-3502",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3502"
},
{
"name": "CVE-2021-3574",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3574"
},
{
"name": "CVE-2021-3596",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3596"
},
{
"name": "CVE-2021-3598",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3598"
},
{
"name": "CVE-2021-3605",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3605"
},
{
"name": "CVE-2021-3610",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3610"
},
{
"name": "CVE-2021-3670",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3670"
},
{
"name": "CVE-2021-38115",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38115"
},
{
"name": "CVE-2021-39212",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-39212"
},
{
"name": "CVE-2021-3933",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3933"
},
{
"name": "CVE-2021-3941",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3941"
},
{
"name": "CVE-2021-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-40211"
},
{
"name": "CVE-2021-40812",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-40812"
},
{
"name": "CVE-2021-4214",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4214"
},
{
"name": "CVE-2021-4217",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4217"
},
{
"name": "CVE-2021-4219",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4219"
},
{
"name": "CVE-2021-44964",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44964"
},
{
"name": "CVE-2021-45931",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-45931"
},
{
"name": "CVE-2021-45942",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-45942"
},
{
"name": "CVE-2021-46310",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46310"
},
{
"name": "CVE-2021-46312",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46312"
},
{
"name": "CVE-2022-0284",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0284"
},
{
"name": "CVE-2022-0529",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0529"
},
{
"name": "CVE-2022-0865",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0865"
},
{
"name": "CVE-2022-0907",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0907"
},
{
"name": "CVE-2022-0909",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0909"
},
{
"name": "CVE-2022-0924",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0924"
},
{
"name": "CVE-2022-1056",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1056"
},
{
"name": "CVE-2022-1114",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1114"
},
{
"name": "CVE-2022-1115",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1115"
},
{
"name": "CVE-2022-1210",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1210"
},
{
"name": "CVE-2022-1355",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1355"
},
{
"name": "CVE-2022-1623",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1623"
},
{
"name": "CVE-2022-2231",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2231"
},
{
"name": "CVE-2022-2519",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2519"
},
{
"name": "CVE-2022-2520",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2520"
},
{
"name": "CVE-2022-2521",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2521"
},
{
"name": "CVE-2022-25308",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25308"
},
{
"name": "CVE-2022-25309",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25309"
},
{
"name": "CVE-2022-25310",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25310"
},
{
"name": "CVE-2022-2598",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2598"
},
{
"name": "CVE-2022-26280",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26280"
},
{
"name": "CVE-2022-2719",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2719"
},
{
"name": "CVE-2022-28463",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28463"
},
{
"name": "CVE-2022-28805",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28805"
},
{
"name": "CVE-2022-29217",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29217"
},
{
"name": "CVE-2022-2928",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2928"
},
{
"name": "CVE-2022-2929",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2929"
},
{
"name": "CVE-2022-2953",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2953"
},
{
"name": "CVE-2022-30698",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30698"
},
{
"name": "CVE-2022-30699",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30699"
},
{
"name": "CVE-2022-31683",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31683"
},
{
"name": "CVE-2022-31782",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31782"
},
{
"name": "CVE-2022-3213",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3213"
},
{
"name": "CVE-2022-32545",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32545"
},
{
"name": "CVE-2022-32546",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32546"
},
{
"name": "CVE-2022-32547",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32547"
},
{
"name": "CVE-2022-33068",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-33068"
},
{
"name": "CVE-2022-33099",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-33099"
},
{
"name": "CVE-2022-36087",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36087"
},
{
"name": "CVE-2022-44267",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44267"
},
{
"name": "CVE-2022-48281",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48281"
},
{
"name": "CVE-2023-1289",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1289"
},
{
"name": "CVE-2023-1355",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1355"
},
{
"name": "CVE-2023-1906",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1906"
},
{
"name": "CVE-2023-1981",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1981"
},
{
"name": "CVE-2023-2157",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2157"
},
{
"name": "CVE-2023-2426",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2426"
},
{
"name": "CVE-2023-26785",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26785"
},
{
"name": "CVE-2023-27102",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27102"
},
{
"name": "CVE-2023-30571",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30571"
},
{
"name": "CVE-2023-3195",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3195"
},
{
"name": "CVE-2023-34151",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34151"
},
{
"name": "CVE-2023-34152",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34152"
},
{
"name": "CVE-2023-34153",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34153"
},
{
"name": "CVE-2023-3428",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3428"
},
{
"name": "CVE-2023-34474",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34474"
},
{
"name": "CVE-2023-34475",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34475"
},
{
"name": "CVE-2023-3618",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3618"
},
{
"name": "CVE-2023-38469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38469"
},
{
"name": "CVE-2023-38470",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38470"
},
{
"name": "CVE-2023-38471",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38471"
},
{
"name": "CVE-2023-38472",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38472"
},
{
"name": "CVE-2023-38473",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38473"
},
{
"name": "CVE-2023-38633",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38633"
},
{
"name": "CVE-2023-3896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3896"
},
{
"name": "CVE-2023-39327",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39327"
},
{
"name": "CVE-2023-39593",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39593"
},
{
"name": "CVE-2023-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39978"
},
{
"name": "CVE-2023-43887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-43887"
},
{
"name": "CVE-2023-45913",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45913"
},
{
"name": "CVE-2023-45919",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45919"
},
{
"name": "CVE-2023-45922",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45922"
},
{
"name": "CVE-2023-45931",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45931"
},
{
"name": "CVE-2023-47471",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47471"
},
{
"name": "CVE-2023-5568",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5568"
},
{
"name": "CVE-2024-10524",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10524"
},
{
"name": "CVE-2024-13978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-13978"
},
{
"name": "CVE-2024-27766",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27766"
},
{
"name": "CVE-2024-37407",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37407"
},
{
"name": "CVE-2024-41817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41817"
},
{
"name": "CVE-2024-43167",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43167"
},
{
"name": "CVE-2024-43168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43168"
},
{
"name": "CVE-2024-43790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43790"
},
{
"name": "CVE-2024-45720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45720"
},
{
"name": "CVE-2024-46901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46901"
},
{
"name": "CVE-2024-57970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57970"
},
{
"name": "CVE-2025-0306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0306"
},
{
"name": "CVE-2025-0838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0838"
},
{
"name": "CVE-2025-10911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10911"
},
{
"name": "CVE-2025-11731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11731"
},
{
"name": "CVE-2025-1632",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1632"
},
{
"name": "CVE-2025-2099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2099"
},
{
"name": "CVE-2025-2148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2148"
},
{
"name": "CVE-2025-2149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2149"
},
{
"name": "CVE-2025-2953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2953"
},
{
"name": "CVE-2025-2998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2998"
},
{
"name": "CVE-2025-2999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2999"
},
{
"name": "CVE-2025-3000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3000"
},
{
"name": "CVE-2025-3001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3001"
},
{
"name": "CVE-2025-3121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3121"
},
{
"name": "CVE-2025-3136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3136"
},
{
"name": "CVE-2025-31498",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31498"
},
{
"name": "CVE-2025-3262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3262"
},
{
"name": "CVE-2025-3263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3263"
},
{
"name": "CVE-2025-3264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3264"
},
{
"name": "CVE-2025-3730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3730"
},
{
"name": "CVE-2025-3777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3777"
},
{
"name": "CVE-2025-3933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3933"
},
{
"name": "CVE-2025-40002",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40002"
},
{
"name": "CVE-2025-40004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40004"
},
{
"name": "CVE-2025-40007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40007"
},
{
"name": "CVE-2025-40015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40015"
},
{
"name": "CVE-2025-40017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40017"
},
{
"name": "CVE-2025-4056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4056"
},
{
"name": "CVE-2025-4287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4287"
},
{
"name": "CVE-2025-43965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-43965"
},
{
"name": "CVE-2025-46148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46148"
},
{
"name": "CVE-2025-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46149"
},
{
"name": "CVE-2025-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46150"
},
{
"name": "CVE-2025-46152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46152"
},
{
"name": "CVE-2025-46153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46153"
},
{
"name": "CVE-2025-46393",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46393"
},
{
"name": "CVE-2025-46569",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46569"
},
{
"name": "CVE-2025-47291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47291"
},
{
"name": "CVE-2025-50950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50950"
},
{
"name": "CVE-2025-5197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5197"
},
{
"name": "CVE-2025-52099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52099"
},
{
"name": "CVE-2025-53014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53014"
},
{
"name": "CVE-2025-53019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53019"
},
{
"name": "CVE-2025-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53101"
},
{
"name": "CVE-2025-53367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53367"
},
{
"name": "CVE-2025-53643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53643"
},
{
"name": "CVE-2025-54801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54801"
},
{
"name": "CVE-2025-54874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54874"
},
{
"name": "CVE-2025-55004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55004"
},
{
"name": "CVE-2025-55005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55005"
},
{
"name": "CVE-2025-55154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55154"
},
{
"name": "CVE-2025-55160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55160"
},
{
"name": "CVE-2025-55197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55197"
},
{
"name": "CVE-2025-55212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55212"
},
{
"name": "CVE-2025-55298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55298"
},
{
"name": "CVE-2025-55553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55553"
},
{
"name": "CVE-2025-55557",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55557"
},
{
"name": "CVE-2025-55558",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55558"
},
{
"name": "CVE-2025-55560",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55560"
},
{
"name": "CVE-2025-5745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5745"
},
{
"name": "CVE-2025-57803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-57803"
},
{
"name": "CVE-2025-57807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-57807"
},
{
"name": "CVE-2025-5878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5878"
},
{
"name": "CVE-2025-5918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5918"
},
{
"name": "CVE-2025-59375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59375"
},
{
"name": "CVE-2025-59842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59842"
},
{
"name": "CVE-2025-6051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6051"
},
{
"name": "CVE-2025-6052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6052"
},
{
"name": "CVE-2025-6141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6141"
},
{
"name": "CVE-2025-62171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62171"
},
{
"name": "CVE-2025-6638",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6638"
},
{
"name": "CVE-2025-6921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6921"
},
{
"name": "CVE-2025-7039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7039"
},
{
"name": "CVE-2025-7709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7709"
},
{
"name": "CVE-2025-8114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8114"
},
{
"name": "CVE-2025-8177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8177"
},
{
"name": "CVE-2025-8277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8277"
},
{
"name": "CVE-2025-8534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8534"
},
{
"name": "CVE-2025-8556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8556"
},
{
"name": "CVE-2025-8851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8851"
},
{
"name": "CVE-2025-8961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8961"
},
{
"name": "CVE-2025-9092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9092"
},
{
"name": "CVE-2025-9165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9165"
},
{
"name": "CVE-2025-9340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9340"
},
{
"name": "CVE-2025-9341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9341"
},
{
"name": "CVE-2025-9390",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9390"
},
{
"name": "CVE-2025-9403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9403"
},
{
"name": "CVE-2025-9714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9714"
},
{
"name": "CVE-2024-45491",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45491"
},
{
"name": "CVE-2024-45492",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45492"
},
{
"name": "CVE-2024-38816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38816"
},
{
"name": "CVE-2024-44939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44939"
},
{
"name": "CVE-2024-7264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7264"
},
{
"name": "CVE-2024-41957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41957"
},
{
"name": "CVE-2024-34459",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34459"
},
{
"name": "CVE-2024-8096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8096"
},
{
"name": "CVE-2023-6246",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6246"
},
{
"name": "CVE-2024-27280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27280"
},
{
"name": "CVE-2024-24789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24789"
},
{
"name": "CVE-2024-34155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34155"
},
{
"name": "CVE-2024-34156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34156"
},
{
"name": "CVE-2024-34158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34158"
},
{
"name": "CVE-2024-5569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5569"
},
{
"name": "CVE-2024-24790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24790"
},
{
"name": "CVE-2019-16775",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-16775"
},
{
"name": "CVE-2019-16776",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-16776"
},
{
"name": "CVE-2019-16777",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-16777"
},
{
"name": "CVE-2024-21208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21208"
},
{
"name": "CVE-2024-21210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21210"
},
{
"name": "CVE-2024-21217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21217"
},
{
"name": "CVE-2024-21235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21235"
},
{
"name": "CVE-2024-37370",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37370"
},
{
"name": "CVE-2024-37371",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37371"
},
{
"name": "CVE-2024-7254",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7254"
},
{
"name": "CVE-2024-9143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9143"
},
{
"name": "CVE-2024-38819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38819"
},
{
"name": "CVE-2024-38820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38820"
},
{
"name": "CVE-2023-6349",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6349"
},
{
"name": "CVE-2024-5197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5197"
},
{
"name": "CVE-2024-35176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35176"
},
{
"name": "CVE-2024-39908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39908"
},
{
"name": "CVE-2024-41123",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41123"
},
{
"name": "CVE-2024-41946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41946"
},
{
"name": "CVE-2024-43398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43398"
},
{
"name": "CVE-2024-34447",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34447"
},
{
"name": "CVE-2024-45490",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45490"
},
{
"name": "CVE-2024-47874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47874"
},
{
"name": "CVE-2024-7592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7592"
},
{
"name": "CVE-2024-8088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8088"
},
{
"name": "CVE-2024-9681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9681"
},
{
"name": "CVE-2024-11168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11168"
},
{
"name": "CVE-2024-38828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38828"
},
{
"name": "CVE-2024-38829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38829"
},
{
"name": "CVE-2024-52316",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52316"
},
{
"name": "CVE-2024-43788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43788"
},
{
"name": "CVE-2023-49582",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-49582"
},
{
"name": "CVE-2024-11053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11053"
},
{
"name": "CVE-2024-54534",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54534"
},
{
"name": "CVE-2024-10041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10041"
},
{
"name": "CVE-2024-10963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10963"
},
{
"name": "CVE-2024-47554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47554"
},
{
"name": "CVE-2024-50379",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50379"
},
{
"name": "CVE-2024-54677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54677"
},
{
"name": "CVE-2024-27407",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27407"
},
{
"name": "CVE-2024-50157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50157"
},
{
"name": "CVE-2017-9937",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-9937"
},
{
"name": "CVE-2022-0561",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0561"
},
{
"name": "CVE-2022-0562",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0562"
},
{
"name": "CVE-2022-0908",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0908"
},
{
"name": "CVE-2022-2056",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2056"
},
{
"name": "CVE-2022-2057",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2057"
},
{
"name": "CVE-2022-2058",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2058"
},
{
"name": "CVE-2022-22844",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22844"
},
{
"name": "CVE-2022-2867",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2867"
},
{
"name": "CVE-2022-2868",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2868"
},
{
"name": "CVE-2022-2869",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2869"
},
{
"name": "CVE-2022-34526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34526"
},
{
"name": "CVE-2022-3570",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3570"
},
{
"name": "CVE-2022-3597",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3597"
},
{
"name": "CVE-2022-3598",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3598"
},
{
"name": "CVE-2022-3599",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3599"
},
{
"name": "CVE-2022-3626",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3626"
},
{
"name": "CVE-2022-3627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3627"
},
{
"name": "CVE-2022-40090",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40090"
},
{
"name": "CVE-2022-4645",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4645"
},
{
"name": "CVE-2023-0795",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0795"
},
{
"name": "CVE-2023-0796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0796"
},
{
"name": "CVE-2023-0797",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0797"
},
{
"name": "CVE-2023-0798",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0798"
},
{
"name": "CVE-2023-0799",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0799"
},
{
"name": "CVE-2023-0800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0800"
},
{
"name": "CVE-2023-0801",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0801"
},
{
"name": "CVE-2023-0802",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0802"
},
{
"name": "CVE-2023-0803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0803"
},
{
"name": "CVE-2023-0804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0804"
},
{
"name": "CVE-2023-1916",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1916"
},
{
"name": "CVE-2023-2731",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2731"
},
{
"name": "CVE-2023-2908",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2908"
},
{
"name": "CVE-2023-3576",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3576"
},
{
"name": "CVE-2023-40745",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40745"
},
{
"name": "CVE-2023-41175",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-41175"
},
{
"name": "CVE-2024-56337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56337"
},
{
"name": "CVE-2024-27281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27281"
},
{
"name": "CVE-2024-12085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12085"
},
{
"name": "CVE-2024-12086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12086"
},
{
"name": "CVE-2024-12087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12087"
},
{
"name": "CVE-2024-12088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12088"
},
{
"name": "CVE-2024-12747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12747"
},
{
"name": "CVE-2025-21502",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21502"
},
{
"name": "CVE-2025-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23083"
},
{
"name": "CVE-2025-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23084"
},
{
"name": "CVE-2025-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23085"
},
{
"name": "CVE-2024-11187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11187"
},
{
"name": "CVE-2024-12705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12705"
},
{
"name": "CVE-2025-0938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0938"
},
{
"name": "CVE-2025-0167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0167"
},
{
"name": "CVE-2025-0725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0725"
},
{
"name": "CVE-2023-28154",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28154"
},
{
"name": "CVE-2024-47535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47535"
},
{
"name": "CVE-2024-50602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50602"
},
{
"name": "CVE-2025-21666",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21666"
},
{
"name": "CVE-2025-21669",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21669"
},
{
"name": "CVE-2025-21670",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21670"
},
{
"name": "CVE-2025-21674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21674"
},
{
"name": "CVE-2025-21675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21675"
},
{
"name": "CVE-2025-21676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21676"
},
{
"name": "CVE-2025-21678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21678"
},
{
"name": "CVE-2025-21682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21682"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2024-57948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57948"
},
{
"name": "CVE-2025-21665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21665"
},
{
"name": "CVE-2025-21667",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21667"
},
{
"name": "CVE-2025-21668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21668"
},
{
"name": "CVE-2025-21680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21680"
},
{
"name": "CVE-2025-21681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21681"
},
{
"name": "CVE-2025-21683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21683"
},
{
"name": "CVE-2024-12797",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12797"
},
{
"name": "CVE-2024-13176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-13176"
},
{
"name": "CVE-2025-1094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1094"
},
{
"name": "CVE-2025-26465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-26465"
},
{
"name": "CVE-2025-21673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21673"
},
{
"name": "CVE-2024-49887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49887"
},
{
"name": "CVE-2024-8508",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8508"
},
{
"name": "CVE-2025-1795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1795"
},
{
"name": "CVE-2025-21684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21684"
},
{
"name": "CVE-2025-21689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21689"
},
{
"name": "CVE-2025-21690",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21690"
},
{
"name": "CVE-2025-21692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21692"
},
{
"name": "CVE-2025-21697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21697"
},
{
"name": "CVE-2025-21699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21699"
},
{
"name": "CVE-2024-57949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57949"
},
{
"name": "CVE-2024-57951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57951"
},
{
"name": "CVE-2025-21694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21694"
},
{
"name": "CVE-2025-24813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24813"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-57994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57994"
},
{
"name": "CVE-2025-21705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21705"
},
{
"name": "CVE-2025-21715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21715"
},
{
"name": "CVE-2025-21716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21716"
},
{
"name": "CVE-2025-21719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21719"
},
{
"name": "CVE-2025-21724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21724"
},
{
"name": "CVE-2025-21725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21725"
},
{
"name": "CVE-2025-21728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21728"
},
{
"name": "CVE-2025-21733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21733"
},
{
"name": "CVE-2025-21753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21753"
},
{
"name": "CVE-2025-21754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21754"
},
{
"name": "CVE-2025-21767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21767"
},
{
"name": "CVE-2025-21790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21790"
},
{
"name": "CVE-2025-21795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21795"
},
{
"name": "CVE-2025-21799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21799"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2022-49043",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49043"
},
{
"name": "CVE-2025-24970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24970"
},
{
"name": "CVE-2025-25193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25193"
},
{
"name": "CVE-2024-24791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24791"
},
{
"name": "CVE-2025-22228",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22228"
},
{
"name": "CVE-2023-24531",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24531"
},
{
"name": "CVE-2024-45336",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45336"
},
{
"name": "CVE-2024-45337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45337"
},
{
"name": "CVE-2024-45341",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45341"
},
{
"name": "CVE-2025-22866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22866"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2025-21772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21772"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2024-57883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57883"
},
{
"name": "CVE-2024-57924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57924"
},
{
"name": "CVE-2024-56171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56171"
},
{
"name": "CVE-2025-27113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27113"
},
{
"name": "CVE-2024-54458",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54458"
},
{
"name": "CVE-2024-57834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57834"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-57981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57981"
},
{
"name": "CVE-2024-57986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57986"
},
{
"name": "CVE-2024-57993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57993"
},
{
"name": "CVE-2024-57997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57997"
},
{
"name": "CVE-2024-57998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57998"
},
{
"name": "CVE-2024-58001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58001"
},
{
"name": "CVE-2024-58007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58007"
},
{
"name": "CVE-2024-58010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58010"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2024-58016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58016"
},
{
"name": "CVE-2024-58017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58017"
},
{
"name": "CVE-2024-58020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58020"
},
{
"name": "CVE-2024-58034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58034"
},
{
"name": "CVE-2024-58051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58051"
},
{
"name": "CVE-2024-58052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58052"
},
{
"name": "CVE-2024-58054",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58054"
},
{
"name": "CVE-2024-58055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58055"
},
{
"name": "CVE-2024-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58056"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2024-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58061"
},
{
"name": "CVE-2024-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58063"
},
{
"name": "CVE-2024-58068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58068"
},
{
"name": "CVE-2024-58069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58069"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2024-58076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58076"
},
{
"name": "CVE-2024-58077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58077"
},
{
"name": "CVE-2024-58080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58080"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2024-58085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58085"
},
{
"name": "CVE-2024-58086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58086"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2025-21706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21706"
},
{
"name": "CVE-2025-21707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21707"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-21711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21711"
},
{
"name": "CVE-2025-21722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21722"
},
{
"name": "CVE-2025-21726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21726"
},
{
"name": "CVE-2025-21727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21727"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2025-21734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21734"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-21736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21736"
},
{
"name": "CVE-2025-21738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21738"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2025-21745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21745"
},
{
"name": "CVE-2025-21748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21748"
},
{
"name": "CVE-2025-21749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21749"
},
{
"name": "CVE-2025-21750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21750"
},
{
"name": "CVE-2025-21758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21758"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2025-21761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21761"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2025-21764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21764"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2025-21766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21766"
},
{
"name": "CVE-2025-21775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21775"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21779"
},
{
"name": "CVE-2025-21781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21781"
},
{
"name": "CVE-2025-21782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21782"
},
{
"name": "CVE-2025-21787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21787"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2025-21792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21792"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-21804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21804"
},
{
"name": "CVE-2025-21806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21806"
},
{
"name": "CVE-2025-21811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21811"
},
{
"name": "CVE-2025-21812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21812"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21820"
},
{
"name": "CVE-2025-21821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21821"
},
{
"name": "CVE-2025-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21823"
},
{
"name": "CVE-2025-21826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21826"
},
{
"name": "CVE-2025-21829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21829"
},
{
"name": "CVE-2025-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21830"
},
{
"name": "CVE-2025-21832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21832"
},
{
"name": "CVE-2025-21835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21835"
},
{
"name": "CVE-2024-49761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49761"
},
{
"name": "CVE-2025-21574",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21574"
},
{
"name": "CVE-2025-21575",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21575"
},
{
"name": "CVE-2025-21577",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21577"
},
{
"name": "CVE-2025-21579",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21579"
},
{
"name": "CVE-2025-21580",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21580"
},
{
"name": "CVE-2025-21581",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21581"
},
{
"name": "CVE-2025-21584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21584"
},
{
"name": "CVE-2025-21585",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21585"
},
{
"name": "CVE-2025-30681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30681"
},
{
"name": "CVE-2025-30682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30682"
},
{
"name": "CVE-2025-30683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30683"
},
{
"name": "CVE-2025-30684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30684"
},
{
"name": "CVE-2025-30685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30685"
},
{
"name": "CVE-2025-30687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30687"
},
{
"name": "CVE-2025-30688",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30688"
},
{
"name": "CVE-2025-30689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30689"
},
{
"name": "CVE-2025-30693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30693"
},
{
"name": "CVE-2025-30695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30695"
},
{
"name": "CVE-2025-30696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30696"
},
{
"name": "CVE-2025-30699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30699"
},
{
"name": "CVE-2025-30703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30703"
},
{
"name": "CVE-2025-30704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30704"
},
{
"name": "CVE-2025-30705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30705"
},
{
"name": "CVE-2025-30715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30715"
},
{
"name": "CVE-2025-30721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30721"
},
{
"name": "CVE-2025-30722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30722"
},
{
"name": "CVE-2024-52559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52559"
},
{
"name": "CVE-2024-57974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57974"
},
{
"name": "CVE-2024-57990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57990"
},
{
"name": "CVE-2024-57999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57999"
},
{
"name": "CVE-2024-58002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58002"
},
{
"name": "CVE-2024-58005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58005"
},
{
"name": "CVE-2024-58006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58006"
},
{
"name": "CVE-2024-58019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58019"
},
{
"name": "CVE-2024-58057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58057"
},
{
"name": "CVE-2024-58078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58078"
},
{
"name": "CVE-2024-58079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58079"
},
{
"name": "CVE-2025-21714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21714"
},
{
"name": "CVE-2025-21723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21723"
},
{
"name": "CVE-2025-21732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21732"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2025-21741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21741"
},
{
"name": "CVE-2025-21742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21742"
},
{
"name": "CVE-2025-21743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21743"
},
{
"name": "CVE-2025-21759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21759"
},
{
"name": "CVE-2025-21773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21773"
},
{
"name": "CVE-2025-21784",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21784"
},
{
"name": "CVE-2025-21793",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21793"
},
{
"name": "CVE-2025-21810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21810"
},
{
"name": "CVE-2025-21815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21815"
},
{
"name": "CVE-2025-21825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21825"
},
{
"name": "CVE-2025-21828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21828"
},
{
"name": "CVE-2025-21838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21838"
},
{
"name": "CVE-2025-21839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21839"
},
{
"name": "CVE-2025-21844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21844"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2025-21847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21847"
},
{
"name": "CVE-2025-21848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21848"
},
{
"name": "CVE-2025-21855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21855"
},
{
"name": "CVE-2025-21856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21856"
},
{
"name": "CVE-2025-21857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21857"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2025-21859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21859"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-21862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21862"
},
{
"name": "CVE-2025-21864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21864"
},
{
"name": "CVE-2025-21866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21866"
},
{
"name": "CVE-2025-21869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21869"
},
{
"name": "CVE-2025-21870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21870"
},
{
"name": "CVE-2025-21871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21871"
},
{
"name": "CVE-2025-21877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21877"
},
{
"name": "CVE-2025-21878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21878"
},
{
"name": "CVE-2025-21883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21883"
},
{
"name": "CVE-2025-21885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21885"
},
{
"name": "CVE-2025-21888",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21888"
},
{
"name": "CVE-2025-21890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21890"
},
{
"name": "CVE-2025-21891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21891"
},
{
"name": "CVE-2025-21892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21892"
},
{
"name": "CVE-2025-21587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21587"
},
{
"name": "CVE-2025-30698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30698"
},
{
"name": "CVE-2024-8176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8176"
},
{
"name": "CVE-2025-24928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24928"
},
{
"name": "CVE-2024-57977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57977"
},
{
"name": "CVE-2024-58090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58090"
},
{
"name": "CVE-2025-21712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21712"
},
{
"name": "CVE-2025-21721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21721"
},
{
"name": "CVE-2025-21867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21867"
},
{
"name": "CVE-2025-21875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21875"
},
{
"name": "CVE-2025-21881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21881"
},
{
"name": "CVE-2025-21887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21887"
},
{
"name": "CVE-2025-21898",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21898"
},
{
"name": "CVE-2025-21899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21899"
},
{
"name": "CVE-2025-21904",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21904"
},
{
"name": "CVE-2025-21905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21905"
},
{
"name": "CVE-2025-21909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21909"
},
{
"name": "CVE-2025-21910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21910"
},
{
"name": "CVE-2025-21912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21912"
},
{
"name": "CVE-2025-21913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21913"
},
{
"name": "CVE-2025-21914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21914"
},
{
"name": "CVE-2025-21916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21916"
},
{
"name": "CVE-2025-21917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21917"
},
{
"name": "CVE-2025-21918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21918"
},
{
"name": "CVE-2025-21919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21919"
},
{
"name": "CVE-2025-21920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21920"
},
{
"name": "CVE-2025-21922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21922"
},
{
"name": "CVE-2025-21924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21924"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2025-21928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21928"
},
{
"name": "CVE-2025-21934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21934"
},
{
"name": "CVE-2025-21935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21935"
},
{
"name": "CVE-2025-21936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21936"
},
{
"name": "CVE-2025-21937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21937"
},
{
"name": "CVE-2025-21941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21941"
},
{
"name": "CVE-2025-21943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21943"
},
{
"name": "CVE-2025-21944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21944"
},
{
"name": "CVE-2025-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21945"
},
{
"name": "CVE-2025-21947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21947"
},
{
"name": "CVE-2025-21948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21948"
},
{
"name": "CVE-2025-21950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21950"
},
{
"name": "CVE-2025-21951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21951"
},
{
"name": "CVE-2025-21956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21956"
},
{
"name": "CVE-2025-21957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21957"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2025-21960",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21960"
},
{
"name": "CVE-2025-21962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21962"
},
{
"name": "CVE-2025-21963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21963"
},
{
"name": "CVE-2025-21964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21964"
},
{
"name": "CVE-2025-21968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21968"
},
{
"name": "CVE-2025-21970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21970"
},
{
"name": "CVE-2025-21975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21975"
},
{
"name": "CVE-2025-21978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21978"
},
{
"name": "CVE-2025-21979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21979"
},
{
"name": "CVE-2025-21980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21980"
},
{
"name": "CVE-2025-21981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21981"
},
{
"name": "CVE-2025-21986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21986"
},
{
"name": "CVE-2025-21991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21991"
},
{
"name": "CVE-2025-21992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21992"
},
{
"name": "CVE-2025-21994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21994"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-21997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21997"
},
{
"name": "CVE-2025-21999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21999"
},
{
"name": "CVE-2025-22004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22004"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2025-22008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22008"
},
{
"name": "CVE-2025-22010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22010"
},
{
"name": "CVE-2025-22014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22014"
},
{
"name": "CVE-2025-22015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22015"
},
{
"name": "CVE-2025-21969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21969"
},
{
"name": "CVE-2024-12798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12798"
},
{
"name": "CVE-2024-12801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12801"
},
{
"name": "CVE-2025-27789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27789"
},
{
"name": "CVE-2025-22868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22868"
},
{
"name": "CVE-2025-22871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22871"
},
{
"name": "CVE-2025-22235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22235"
},
{
"name": "CVE-2024-57952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57952"
},
{
"name": "CVE-2025-21672",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21672"
},
{
"name": "CVE-2025-21691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21691"
},
{
"name": "CVE-2025-2312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2312"
},
{
"name": "CVE-2025-21927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21927"
},
{
"name": "CVE-2025-21853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21853"
},
{
"name": "CVE-2025-22088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22088"
},
{
"name": "CVE-2025-37785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37785"
},
{
"name": "CVE-2025-27363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27363"
},
{
"name": "CVE-2025-27516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27516"
},
{
"name": "CVE-2024-58081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58081"
},
{
"name": "CVE-2025-4207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4207"
},
{
"name": "CVE-2025-4516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4516"
},
{
"name": "CVE-2025-22233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22233"
},
{
"name": "CVE-2024-55549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55549"
},
{
"name": "CVE-2024-9287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9287"
},
{
"name": "CVE-2025-24855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24855"
},
{
"name": "CVE-2025-41232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41232"
},
{
"name": "CVE-2025-23165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23165"
},
{
"name": "CVE-2025-23166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23166"
},
{
"name": "CVE-2025-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23167"
},
{
"name": "CVE-2025-32414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32414"
},
{
"name": "CVE-2025-32415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32415"
},
{
"name": "CVE-2024-58018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58018"
},
{
"name": "CVE-2024-58070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58070"
},
{
"name": "CVE-2024-58088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58088"
},
{
"name": "CVE-2024-58093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58093"
},
{
"name": "CVE-2025-21768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21768"
},
{
"name": "CVE-2025-21808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21808"
},
{
"name": "CVE-2025-21836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21836"
},
{
"name": "CVE-2025-21854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21854"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2025-21873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21873"
},
{
"name": "CVE-2025-21889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21889"
},
{
"name": "CVE-2025-21894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21894"
},
{
"name": "CVE-2025-21895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21895"
},
{
"name": "CVE-2025-21908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21908"
},
{
"name": "CVE-2025-21915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21915"
},
{
"name": "CVE-2025-21930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21930"
},
{
"name": "CVE-2025-21961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21961"
},
{
"name": "CVE-2025-21966",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21966"
},
{
"name": "CVE-2025-21972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21972"
},
{
"name": "CVE-2025-21976",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21976"
},
{
"name": "CVE-2025-21995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21995"
},
{
"name": "CVE-2025-22001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22001"
},
{
"name": "CVE-2025-22003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22003"
},
{
"name": "CVE-2025-22009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22009"
},
{
"name": "CVE-2025-22013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22013"
},
{
"name": "CVE-2025-22016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22016"
},
{
"name": "CVE-2025-22017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22017"
},
{
"name": "CVE-2025-37798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37798"
},
{
"name": "CVE-2025-22869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22869"
},
{
"name": "CVE-2025-5283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5283"
},
{
"name": "CVE-2025-4947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4947"
},
{
"name": "CVE-2025-5025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5025"
},
{
"name": "CVE-2025-46701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46701"
},
{
"name": "CVE-2025-21872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21872"
},
{
"name": "CVE-2025-37752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37752"
},
{
"name": "CVE-2025-37756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37756"
},
{
"name": "CVE-2025-37797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37797"
},
{
"name": "CVE-2025-37889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37889"
},
{
"name": "CVE-2025-37890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37890"
},
{
"name": "CVE-2025-37932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37932"
},
{
"name": "CVE-2025-37948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37948"
},
{
"name": "CVE-2025-37963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37963"
},
{
"name": "CVE-2025-4517",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4517"
},
{
"name": "CVE-2025-4330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4330"
},
{
"name": "CVE-2025-4138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4138"
},
{
"name": "CVE-2024-12718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12718"
},
{
"name": "CVE-2025-4435",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4435"
},
{
"name": "CVE-2022-1354",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1354"
},
{
"name": "CVE-2025-27144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27144"
},
{
"name": "CVE-2023-6779",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6779"
},
{
"name": "CVE-2023-6780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6780"
},
{
"name": "CVE-2024-12133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12133"
},
{
"name": "CVE-2024-12243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12243"
},
{
"name": "CVE-2024-2236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2236"
},
{
"name": "CVE-2024-52533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52533"
},
{
"name": "CVE-2024-56433",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56433"
},
{
"name": "CVE-2025-0395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0395"
},
{
"name": "CVE-2025-1390",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1390"
},
{
"name": "CVE-2025-31115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31115"
},
{
"name": "CVE-2025-32728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32728"
},
{
"name": "CVE-2025-4373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4373"
},
{
"name": "CVE-2025-4598",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4598"
},
{
"name": "CVE-2025-32434",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32434"
},
{
"name": "CVE-2025-37750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37750"
},
{
"name": "CVE-2025-37958",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37958"
},
{
"name": "CVE-2025-37974",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37974"
},
{
"name": "CVE-2025-49146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49146"
},
{
"name": "CVE-2025-27219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27219"
},
{
"name": "CVE-2025-27220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27220"
},
{
"name": "CVE-2025-43859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-43859"
},
{
"name": "CVE-2025-48988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48988"
},
{
"name": "CVE-2025-49124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49124"
},
{
"name": "CVE-2025-49125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49125"
},
{
"name": "CVE-2023-32570",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32570"
},
{
"name": "CVE-2023-39328",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39328"
},
{
"name": "CVE-2023-51792",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51792"
},
{
"name": "CVE-2024-38949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38949"
},
{
"name": "CVE-2024-38950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38950"
},
{
"name": "CVE-2024-45993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45993"
},
{
"name": "CVE-2024-52616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52616"
},
{
"name": "CVE-2024-53427",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53427"
},
{
"name": "CVE-2024-56406",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56406"
},
{
"name": "CVE-2024-56826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56826"
},
{
"name": "CVE-2024-56827",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56827"
},
{
"name": "CVE-2025-22872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22872"
},
{
"name": "CVE-2025-4802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4802"
},
{
"name": "CVE-2025-21868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21868"
},
{
"name": "CVE-2025-21929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21929"
},
{
"name": "CVE-2025-40364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40364"
},
{
"name": "CVE-2025-6020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6020"
},
{
"name": "CVE-2025-6021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6021"
},
{
"name": "CVE-2025-37997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37997"
},
{
"name": "CVE-2025-38000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38000"
},
{
"name": "CVE-2025-38001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38001"
},
{
"name": "CVE-2025-21903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21903"
},
{
"name": "CVE-2025-21911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21911"
},
{
"name": "CVE-2025-21946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21946"
},
{
"name": "CVE-2025-21955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21955"
},
{
"name": "CVE-2025-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21967"
},
{
"name": "CVE-2025-21977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21977"
},
{
"name": "CVE-2025-21982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21982"
},
{
"name": "CVE-2025-22011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22011"
},
{
"name": "CVE-2025-32462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32462"
},
{
"name": "CVE-2025-32463",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32463"
},
{
"name": "CVE-2025-52434",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52434"
},
{
"name": "CVE-2025-52520",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52520"
},
{
"name": "CVE-2025-53506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53506"
},
{
"name": "CVE-2022-2208",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2208"
},
{
"name": "CVE-2022-2874",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2874"
},
{
"name": "CVE-2022-2923",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2923"
},
{
"name": "CVE-2022-2980",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2980"
},
{
"name": "CVE-2022-3153",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3153"
},
{
"name": "CVE-2022-3278",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3278"
},
{
"name": "CVE-2022-4293",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4293"
},
{
"name": "CVE-2023-1170",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1170"
},
{
"name": "CVE-2023-1175",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1175"
},
{
"name": "CVE-2023-1264",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1264"
},
{
"name": "CVE-2023-2609",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2609"
},
{
"name": "CVE-2023-5441",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5441"
},
{
"name": "CVE-2024-41965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41965"
},
{
"name": "CVE-2024-43374",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43374"
},
{
"name": "CVE-2024-43802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43802"
},
{
"name": "CVE-2024-47081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47081"
},
{
"name": "CVE-2024-47814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47814"
},
{
"name": "CVE-2024-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52615"
},
{
"name": "CVE-2025-1215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1215"
},
{
"name": "CVE-2025-22134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22134"
},
{
"name": "CVE-2025-24014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24014"
},
{
"name": "CVE-2025-25724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25724"
},
{
"name": "CVE-2025-26603",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-26603"
},
{
"name": "CVE-2025-29768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29768"
},
{
"name": "CVE-2025-31344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31344"
},
{
"name": "CVE-2025-3576",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3576"
},
{
"name": "CVE-2025-4565",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4565"
},
{
"name": "CVE-2025-47268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47268"
},
{
"name": "CVE-2025-5702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5702"
},
{
"name": "CVE-2024-57982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57982"
},
{
"name": "CVE-2024-58053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58053"
},
{
"name": "CVE-2025-21720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21720"
},
{
"name": "CVE-2025-21880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21880"
},
{
"name": "CVE-2025-38003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38003"
},
{
"name": "CVE-2025-38004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38004"
},
{
"name": "CVE-2025-38031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38031"
},
{
"name": "CVE-2025-38043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38043"
},
{
"name": "CVE-2025-38044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38044"
},
{
"name": "CVE-2025-38065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38065"
},
{
"name": "CVE-2025-38068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38068"
},
{
"name": "CVE-2025-38072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38072"
},
{
"name": "CVE-2025-38077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38077"
},
{
"name": "CVE-2025-38078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38078"
},
{
"name": "CVE-2025-38079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38079"
},
{
"name": "CVE-2025-38083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38083"
},
{
"name": "CVE-2025-22227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22227"
},
{
"name": "CVE-2025-30749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30749"
},
{
"name": "CVE-2025-30754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30754"
},
{
"name": "CVE-2025-30761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30761"
},
{
"name": "CVE-2025-50059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50059"
},
{
"name": "CVE-2025-50106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50106"
},
{
"name": "CVE-2025-50077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50077"
},
{
"name": "CVE-2025-50078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50078"
},
{
"name": "CVE-2025-50079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50079"
},
{
"name": "CVE-2025-50080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50080"
},
{
"name": "CVE-2025-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50082"
},
{
"name": "CVE-2025-50083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50083"
},
{
"name": "CVE-2025-50084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50084"
},
{
"name": "CVE-2025-50085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50085"
},
{
"name": "CVE-2025-50086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50086"
},
{
"name": "CVE-2025-50087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50087"
},
{
"name": "CVE-2025-50088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50088"
},
{
"name": "CVE-2025-50091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50091"
},
{
"name": "CVE-2025-50092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50092"
},
{
"name": "CVE-2025-50093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50093"
},
{
"name": "CVE-2025-50094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50094"
},
{
"name": "CVE-2025-50096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50096"
},
{
"name": "CVE-2025-50097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50097"
},
{
"name": "CVE-2025-50098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50098"
},
{
"name": "CVE-2025-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50099"
},
{
"name": "CVE-2025-50100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50100"
},
{
"name": "CVE-2025-50101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50101"
},
{
"name": "CVE-2025-50102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50102"
},
{
"name": "CVE-2025-50104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50104"
},
{
"name": "CVE-2025-53023",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53023"
},
{
"name": "CVE-2025-48734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48734"
},
{
"name": "CVE-2025-38061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38061"
},
{
"name": "CVE-2021-3995",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3995"
},
{
"name": "CVE-2021-3996",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3996"
},
{
"name": "CVE-2024-23337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23337"
},
{
"name": "CVE-2024-47611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47611"
},
{
"name": "CVE-2025-0913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0913"
},
{
"name": "CVE-2025-22874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22874"
},
{
"name": "CVE-2025-25186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25186"
},
{
"name": "CVE-2025-27221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27221"
},
{
"name": "CVE-2025-29786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29786"
},
{
"name": "CVE-2025-32955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32955"
},
{
"name": "CVE-2025-32988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32988"
},
{
"name": "CVE-2025-32989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32989"
},
{
"name": "CVE-2025-32990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32990"
},
{
"name": "CVE-2025-38177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38177"
},
{
"name": "CVE-2025-4673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4673"
},
{
"name": "CVE-2025-48060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48060"
},
{
"name": "CVE-2025-4877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4877"
},
{
"name": "CVE-2025-4878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4878"
},
{
"name": "CVE-2025-48924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48924"
},
{
"name": "CVE-2025-49014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49014"
},
{
"name": "CVE-2025-50181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50181"
},
{
"name": "CVE-2025-5318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5318"
},
{
"name": "CVE-2025-5372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5372"
},
{
"name": "CVE-2025-5914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5914"
},
{
"name": "CVE-2025-5915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5915"
},
{
"name": "CVE-2025-5916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5916"
},
{
"name": "CVE-2025-5917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5917"
},
{
"name": "CVE-2025-6069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6069"
},
{
"name": "CVE-2025-6395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6395"
},
{
"name": "CVE-2024-57953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57953"
},
{
"name": "CVE-2024-57975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57975"
},
{
"name": "CVE-2024-58003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58003"
},
{
"name": "CVE-2024-58082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58082"
},
{
"name": "CVE-2025-21710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21710"
},
{
"name": "CVE-2025-21798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21798"
},
{
"name": "CVE-2025-21801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21801"
},
{
"name": "CVE-2025-21809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21809"
},
{
"name": "CVE-2025-21816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21816"
},
{
"name": "CVE-2025-38086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38086"
},
{
"name": "CVE-2025-8194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8194"
},
{
"name": "CVE-2025-7424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7424"
},
{
"name": "CVE-2025-7425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7425"
},
{
"name": "CVE-2024-12254",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12254"
},
{
"name": "CVE-2025-50182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50182"
},
{
"name": "CVE-2025-38052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38052"
},
{
"name": "CVE-2025-38088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38088"
},
{
"name": "CVE-2025-27210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27210"
},
{
"name": "CVE-2025-38181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38181"
},
{
"name": "CVE-2025-38200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38200"
},
{
"name": "CVE-2025-38206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38206"
},
{
"name": "CVE-2025-38212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38212"
},
{
"name": "CVE-2025-38257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38257"
},
{
"name": "CVE-2025-27817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27817"
},
{
"name": "CVE-2025-27818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27818"
},
{
"name": "CVE-2025-48989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48989"
},
{
"name": "CVE-2025-7783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7783"
},
{
"name": "CVE-2025-53859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53859"
},
{
"name": "CVE-2025-24293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24293"
},
{
"name": "CVE-2025-55193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55193"
},
{
"name": "CVE-2021-32256",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32256"
},
{
"name": "CVE-2024-25260",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25260"
},
{
"name": "CVE-2025-1371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1371"
},
{
"name": "CVE-2025-1376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1376"
},
{
"name": "CVE-2025-1377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1377"
},
{
"name": "CVE-2025-47273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47273"
},
{
"name": "CVE-2025-48964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48964"
},
{
"name": "CVE-2025-49794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49794"
},
{
"name": "CVE-2025-49796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49796"
},
{
"name": "CVE-2025-53905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53905"
},
{
"name": "CVE-2025-53906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53906"
},
{
"name": "CVE-2025-41242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41242"
},
{
"name": "CVE-2025-38034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38034"
},
{
"name": "CVE-2025-38035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38035"
},
{
"name": "CVE-2025-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38037"
},
{
"name": "CVE-2025-38048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38048"
},
{
"name": "CVE-2025-38051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38051"
},
{
"name": "CVE-2025-38058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38058"
},
{
"name": "CVE-2025-38066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38066"
},
{
"name": "CVE-2025-38067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38067"
},
{
"name": "CVE-2025-38074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38074"
},
{
"name": "CVE-2025-38075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38075"
},
{
"name": "CVE-2025-38084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38084"
},
{
"name": "CVE-2025-38085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38085"
},
{
"name": "CVE-2025-38090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38090"
},
{
"name": "CVE-2025-38100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38100"
},
{
"name": "CVE-2025-38102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38102"
},
{
"name": "CVE-2025-38103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38103"
},
{
"name": "CVE-2025-38107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38107"
},
{
"name": "CVE-2025-38108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38108"
},
{
"name": "CVE-2025-38111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38111"
},
{
"name": "CVE-2025-38112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38112"
},
{
"name": "CVE-2025-38115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38115"
},
{
"name": "CVE-2025-38119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38119"
},
{
"name": "CVE-2025-38120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38120"
},
{
"name": "CVE-2025-38122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38122"
},
{
"name": "CVE-2025-38135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38135"
},
{
"name": "CVE-2025-38136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38136"
},
{
"name": "CVE-2025-38138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38138"
},
{
"name": "CVE-2025-38143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38143"
},
{
"name": "CVE-2025-38145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38145"
},
{
"name": "CVE-2025-38146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38146"
},
{
"name": "CVE-2025-38147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38147"
},
{
"name": "CVE-2025-38153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38153"
},
{
"name": "CVE-2025-38154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38154"
},
{
"name": "CVE-2025-38157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38157"
},
{
"name": "CVE-2025-38159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38159"
},
{
"name": "CVE-2025-38160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38160"
},
{
"name": "CVE-2025-38161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38161"
},
{
"name": "CVE-2025-38163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38163"
},
{
"name": "CVE-2025-38167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38167"
},
{
"name": "CVE-2025-38173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38173"
},
{
"name": "CVE-2025-38174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38174"
},
{
"name": "CVE-2025-38184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38184"
},
{
"name": "CVE-2025-38194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38194"
},
{
"name": "CVE-2025-38197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38197"
},
{
"name": "CVE-2025-38211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38211"
},
{
"name": "CVE-2025-38218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38218"
},
{
"name": "CVE-2025-38219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38219"
},
{
"name": "CVE-2025-38222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38222"
},
{
"name": "CVE-2025-38226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38226"
},
{
"name": "CVE-2025-38227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38227"
},
{
"name": "CVE-2025-38229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38229"
},
{
"name": "CVE-2025-38231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38231"
},
{
"name": "CVE-2025-38245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38245"
},
{
"name": "CVE-2025-38249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38249"
},
{
"name": "CVE-2025-38251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38251"
},
{
"name": "CVE-2025-38262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38262"
},
{
"name": "CVE-2025-38263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38263"
},
{
"name": "CVE-2025-38273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38273"
},
{
"name": "CVE-2025-38280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38280"
},
{
"name": "CVE-2025-38285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38285"
},
{
"name": "CVE-2025-38286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38286"
},
{
"name": "CVE-2025-38293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38293"
},
{
"name": "CVE-2025-38298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38298"
},
{
"name": "CVE-2025-38305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38305"
},
{
"name": "CVE-2025-38310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38310"
},
{
"name": "CVE-2025-38312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38312"
},
{
"name": "CVE-2025-38313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38313"
},
{
"name": "CVE-2025-38319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38319"
},
{
"name": "CVE-2025-38320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38320"
},
{
"name": "CVE-2025-38324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38324"
},
{
"name": "CVE-2025-38326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38326"
},
{
"name": "CVE-2025-38328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38328"
},
{
"name": "CVE-2025-38332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38332"
},
{
"name": "CVE-2025-38336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38336"
},
{
"name": "CVE-2025-38337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38337"
},
{
"name": "CVE-2025-38342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38342"
},
{
"name": "CVE-2025-38344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38344"
},
{
"name": "CVE-2025-38345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38345"
},
{
"name": "CVE-2025-38346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38346"
},
{
"name": "CVE-2025-38348",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38348"
},
{
"name": "CVE-2025-38350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38350"
},
{
"name": "CVE-2025-38352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38352"
},
{
"name": "CVE-2025-38362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38362"
},
{
"name": "CVE-2025-38363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38363"
},
{
"name": "CVE-2025-38371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38371"
},
{
"name": "CVE-2025-38375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38375"
},
{
"name": "CVE-2025-38377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38377"
},
{
"name": "CVE-2025-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38384"
},
{
"name": "CVE-2025-38386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38386"
},
{
"name": "CVE-2025-38387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38387"
},
{
"name": "CVE-2025-38389",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38389"
},
{
"name": "CVE-2025-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38391"
},
{
"name": "CVE-2025-38393",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38393"
},
{
"name": "CVE-2025-38395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38395"
},
{
"name": "CVE-2025-38399",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38399"
},
{
"name": "CVE-2025-38400",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38400"
},
{
"name": "CVE-2025-38401",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38401"
},
{
"name": "CVE-2025-38403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38403"
},
{
"name": "CVE-2025-38406",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38406"
},
{
"name": "CVE-2025-38410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38410"
},
{
"name": "CVE-2025-38412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38412"
},
{
"name": "CVE-2025-38415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38415"
},
{
"name": "CVE-2025-38416",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38416"
},
{
"name": "CVE-2025-38418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38418"
},
{
"name": "CVE-2025-38419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38419"
},
{
"name": "CVE-2025-38420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38420"
},
{
"name": "CVE-2025-38424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38424"
},
{
"name": "CVE-2025-38428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38428"
},
{
"name": "CVE-2025-38430",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38430"
},
{
"name": "CVE-2025-38439",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38439"
},
{
"name": "CVE-2025-38441",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38441"
},
{
"name": "CVE-2025-38443",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38443"
},
{
"name": "CVE-2025-38444",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38444"
},
{
"name": "CVE-2025-38445",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38445"
},
{
"name": "CVE-2025-38448",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38448"
},
{
"name": "CVE-2025-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38457"
},
{
"name": "CVE-2025-38458",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38458"
},
{
"name": "CVE-2025-38459",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38459"
},
{
"name": "CVE-2025-38460",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38460"
},
{
"name": "CVE-2025-38461",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38461"
},
{
"name": "CVE-2025-38462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38462"
},
{
"name": "CVE-2025-38464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38464"
},
{
"name": "CVE-2025-38465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38465"
},
{
"name": "CVE-2025-38466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38466"
},
{
"name": "CVE-2025-38467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38467"
},
{
"name": "CVE-2025-38477",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38477"
},
{
"name": "CVE-2025-38498",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38498"
},
{
"name": "CVE-2025-38500",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38500"
},
{
"name": "CVE-2025-8713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8713"
},
{
"name": "CVE-2025-8714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8714"
},
{
"name": "CVE-2025-8715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8715"
},
{
"name": "CVE-2024-54456",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54456"
},
{
"name": "CVE-2025-21746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21746"
},
{
"name": "CVE-2025-21783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21783"
},
{
"name": "CVE-2025-21786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21786"
},
{
"name": "CVE-2025-38203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38203"
},
{
"name": "CVE-2025-38204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38204"
},
{
"name": "CVE-2025-54988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54988"
},
{
"name": "CVE-2025-6965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6965"
},
{
"name": "CVE-2025-55668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55668"
},
{
"name": "CVE-2025-4674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4674"
},
{
"name": "CVE-2025-47907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47907"
},
{
"name": "CVE-2025-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52999"
},
{
"name": "CVE-2025-54410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54410"
},
{
"name": "CVE-2025-55163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55163"
},
{
"name": "CVE-2025-8941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8941"
},
{
"name": "CVE-2025-9288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9288"
},
{
"name": "CVE-2011-3374",
"url": "https://www.cve.org/CVERecord?id=CVE-2011-3374"
},
{
"name": "CVE-2014-4715",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-4715"
},
{
"name": "CVE-2016-0682",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0682"
},
{
"name": "CVE-2016-0689",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0689"
},
{
"name": "CVE-2016-0692",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0692"
},
{
"name": "CVE-2016-0694",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0694"
},
{
"name": "CVE-2016-3418",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-3418"
},
{
"name": "CVE-2017-10140",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-10140"
},
{
"name": "CVE-2017-3604",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3604"
},
{
"name": "CVE-2017-3605",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3605"
},
{
"name": "CVE-2017-3606",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3606"
},
{
"name": "CVE-2017-3607",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3607"
},
{
"name": "CVE-2017-3608",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3608"
},
{
"name": "CVE-2017-3609",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3609"
},
{
"name": "CVE-2017-3610",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3610"
},
{
"name": "CVE-2017-3611",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3611"
},
{
"name": "CVE-2017-3612",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3612"
},
{
"name": "CVE-2017-3613",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3613"
},
{
"name": "CVE-2017-3614",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3614"
},
{
"name": "CVE-2017-3615",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3615"
},
{
"name": "CVE-2017-3616",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3616"
},
{
"name": "CVE-2017-3617",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3617"
},
{
"name": "CVE-2020-2981",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2981"
},
{
"name": "CVE-2022-3219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3219"
},
{
"name": "CVE-2022-39046",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-39046"
},
{
"name": "CVE-2022-42010",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42010"
},
{
"name": "CVE-2022-42011",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42011"
},
{
"name": "CVE-2022-42012",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42012"
},
{
"name": "CVE-2022-44638",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44638"
},
{
"name": "CVE-2023-31437",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31437"
},
{
"name": "CVE-2023-31438",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31438"
},
{
"name": "CVE-2023-31439",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31439"
},
{
"name": "CVE-2023-37769",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-37769"
},
{
"name": "CVE-2023-47039",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47039"
},
{
"name": "CVE-2024-11584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11584"
},
{
"name": "CVE-2024-21742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21742"
},
{
"name": "CVE-2024-26462",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26462"
},
{
"name": "CVE-2024-3220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3220"
},
{
"name": "CVE-2024-6174",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6174"
},
{
"name": "CVE-2025-1352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1352"
},
{
"name": "CVE-2025-1365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1365"
},
{
"name": "CVE-2025-1372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1372"
},
{
"name": "CVE-2025-24294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24294"
},
{
"name": "CVE-2025-27587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27587"
},
{
"name": "CVE-2025-30258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30258"
},
{
"name": "CVE-2025-31672",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31672"
},
{
"name": "CVE-2025-40909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40909"
},
{
"name": "CVE-2025-43857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-43857"
},
{
"name": "CVE-2025-45582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-45582"
},
{
"name": "CVE-2025-45768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-45768"
},
{
"name": "CVE-2025-49795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49795"
},
{
"name": "CVE-2025-5222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5222"
},
{
"name": "CVE-2025-5278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5278"
},
{
"name": "CVE-2025-53864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53864"
},
{
"name": "CVE-2025-6170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6170"
},
{
"name": "CVE-2025-6297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6297"
},
{
"name": "CVE-2025-7962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7962"
},
{
"name": "CVE-2025-8058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8058"
},
{
"name": "CVE-2025-8732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8732"
},
{
"name": "CVE-2025-8885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8885"
},
{
"name": "CVE-2025-8916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8916"
},
{
"name": "CVE-2025-32386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32386"
},
{
"name": "CVE-2025-32387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32387"
},
{
"name": "CVE-2025-53547",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53547"
},
{
"name": "CVE-2025-10148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10148"
},
{
"name": "CVE-2025-9086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9086"
},
{
"name": "CVE-2025-38513",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38513"
},
{
"name": "CVE-2025-38515",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38515"
},
{
"name": "CVE-2025-38516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38516"
},
{
"name": "CVE-2025-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38540"
},
{
"name": "CVE-2025-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38617"
},
{
"name": "CVE-2025-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38618"
},
{
"name": "CVE-2025-5994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5994"
},
{
"name": "CVE-2025-41248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41248"
},
{
"name": "CVE-2025-41249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41249"
}
],
"initial_release_date": "2025-11-06T00:00:00",
"last_revision_date": "2025-11-06T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0969",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-11-06T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits VMware. Elles permettent \u00e0 un attaquant de provoquer un probl\u00e8me de s\u00e9curit\u00e9 non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits VMware",
"vendor_advisories": [
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36320",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36320"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36423",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36423"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2022-19",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36364"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-53",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36351"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36424",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36424"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36412",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36412"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36388",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36388"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36426",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36426"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36411",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36411"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36357",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36357"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36408",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36408"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36349",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36349"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36414",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36414"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36397",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36397"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36389",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36389"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36398",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36398"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36380",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36380"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-41",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36407"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36362",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36362"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36413",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36413"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36384",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36384"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36379",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36379"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36400",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36400"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36377",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36377"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36368",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36368"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36418",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36418"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36420",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36420"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36391",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36391"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36392",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36392"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36353",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36353"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-14",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36356"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36422",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36422"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36381",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36381"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36421",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36421"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36416",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36416"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-86",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36415"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36403",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36403"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36347",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36347"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36383",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36383"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36410",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36410"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36352",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36352"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36394",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36394"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36354",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36354"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36399",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36399"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-53",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36350"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36419",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36419"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-85",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36401"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2022-19",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36365"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36405",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36405"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2018-27",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36367"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36395",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36395"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36387",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36387"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36363",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36363"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36385",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36385"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36409",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36409"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-53",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36359"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36348",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36348"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36386",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36386"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36417",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36417"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36425",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36425"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2018-27",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36366"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2024-44",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36360"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36355",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36355"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-53",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36358"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36396",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36396"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36378",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36378"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36382",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36382"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36404",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36404"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2024-44",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36361"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36402",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36402"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36393",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36393"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36406",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36406"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36390",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36390"
}
]
}
CERTFR-2026-AVI-0249
Vulnerability from certfr_avis - Published: 2026-03-06 - Updated: 2026-03-06
De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| IBM | QRadar | QRadar Data Synchronization App versions antérieures à 3.3.0 | ||
| IBM | Db2 | DB2 Data Management Console versions antérieures à 3.1.13 | ||
| IBM | Tivoli | Tivoli Netcool/OMNIbus_GUI sans le dernier correctif de sécurité | ||
| IBM | Db2 | DB2 Recovery Expert versions antérieures à 5.5.0.1 Interim Fix 8 | ||
| IBM | Db2 | Db2 Warehouse on Cloud Pak for Data versions antérieures à 5.3.1 | ||
| IBM | Db2 | Db2 on Cloud Pak for Data versions antérieures à 5.3.1 | ||
| IBM | QRadar | QRadar Pre-Validation App versions antérieures à 2.0.2 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "QRadar Data Synchronization App versions ant\u00e9rieures \u00e0 3.3.0",
"product": {
"name": "QRadar",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "DB2 Data Management Console versions ant\u00e9rieures \u00e0 3.1.13",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Tivoli Netcool/OMNIbus_GUI sans le dernier correctif de s\u00e9curit\u00e9",
"product": {
"name": "Tivoli",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "DB2 Recovery Expert versions ant\u00e9rieures \u00e0 5.5.0.1 Interim Fix 8",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 Warehouse on Cloud Pak for Data versions ant\u00e9rieures \u00e0 5.3.1",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "Db2 on Cloud Pak for Data versions ant\u00e9rieures \u00e0 5.3.1",
"product": {
"name": "Db2",
"vendor": {
"name": "IBM",
"scada": false
}
}
},
{
"description": "QRadar Pre-Validation App versions ant\u00e9rieures \u00e0 2.0.2",
"product": {
"name": "QRadar",
"vendor": {
"name": "IBM",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2024-24790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24790"
},
{
"name": "CVE-2025-66506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66506"
},
{
"name": "CVE-2021-33036",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33036"
},
{
"name": "CVE-2024-20919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20919"
},
{
"name": "CVE-2023-21938",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21938"
},
{
"name": "CVE-2025-53547",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53547"
},
{
"name": "CVE-2025-36353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36353"
},
{
"name": "CVE-2026-21933",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21933"
},
{
"name": "CVE-2025-58183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58183"
},
{
"name": "CVE-2023-21843",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21843"
},
{
"name": "CVE-2026-21932",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21932"
},
{
"name": "CVE-2024-21235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21235"
},
{
"name": "CVE-2018-14042",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14042"
},
{
"name": "CVE-2025-58190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58190"
},
{
"name": "CVE-2024-6531",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6531"
},
{
"name": "CVE-2022-21426",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21426"
},
{
"name": "CVE-2024-37891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37891"
},
{
"name": "CVE-2023-38264",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38264"
},
{
"name": "CVE-2024-22201",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22201"
},
{
"name": "CVE-2016-0703",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0703"
},
{
"name": "CVE-2025-5222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5222"
},
{
"name": "CVE-2025-27516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27516"
},
{
"name": "CVE-2025-4447",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4447"
},
{
"name": "CVE-2024-21144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21144"
},
{
"name": "CVE-2024-55565",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55565"
},
{
"name": "CVE-2025-13867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13867"
},
{
"name": "CVE-2025-2668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2668"
},
{
"name": "CVE-2025-22872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22872"
},
{
"name": "CVE-2025-36427",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36427"
},
{
"name": "CVE-2024-23944",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23944"
},
{
"name": "CVE-2025-32386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32386"
},
{
"name": "CVE-2024-35176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35176"
},
{
"name": "CVE-2023-21954",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21954"
},
{
"name": "CVE-2022-4304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4304"
},
{
"name": "CVE-2023-21939",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21939"
},
{
"name": "CVE-2024-20926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20926"
},
{
"name": "CVE-2018-14040",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14040"
},
{
"name": "CVE-2025-32421",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32421"
},
{
"name": "CVE-2025-47944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47944"
},
{
"name": "CVE-2024-3154",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3154"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-12797",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12797"
},
{
"name": "CVE-2025-27219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27219"
},
{
"name": "CVE-2025-36384",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36384"
},
{
"name": "CVE-2025-36098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36098"
},
{
"name": "CVE-2025-45582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-45582"
},
{
"name": "CVE-2024-21068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21068"
},
{
"name": "CVE-2023-45288",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45288"
},
{
"name": "CVE-2023-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21830"
},
{
"name": "CVE-2024-50302",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50302"
},
{
"name": "CVE-2025-36184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36184"
},
{
"name": "CVE-2025-58185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58185"
},
{
"name": "CVE-2023-0215",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0215"
},
{
"name": "CVE-2016-0800",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0800"
},
{
"name": "CVE-2024-3933",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3933"
},
{
"name": "CVE-2023-0286",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0286"
},
{
"name": "CVE-2025-22121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22121"
},
{
"name": "CVE-2025-24970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24970"
},
{
"name": "CVE-2025-49128",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49128"
},
{
"name": "CVE-2025-22091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22091"
},
{
"name": "CVE-2024-24791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24791"
},
{
"name": "CVE-2024-20921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20921"
},
{
"name": "CVE-2025-36247",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36247"
},
{
"name": "CVE-2024-8176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8176"
},
{
"name": "CVE-2025-36009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36009"
},
{
"name": "CVE-2016-9318",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-9318"
},
{
"name": "CVE-2024-51479",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-51479"
},
{
"name": "CVE-2024-45341",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45341"
},
{
"name": "CVE-2026-23745",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23745"
},
{
"name": "CVE-2025-15467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15467"
},
{
"name": "CVE-2022-21624",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21624"
},
{
"name": "CVE-2025-36070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36070"
},
{
"name": "CVE-2022-46337",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-46337"
},
{
"name": "CVE-2015-2716",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2716"
},
{
"name": "CVE-2024-43398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43398"
},
{
"name": "CVE-2024-29857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29857"
},
{
"name": "CVE-2023-45133",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45133"
},
{
"name": "CVE-2025-36428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36428"
},
{
"name": "CVE-2025-41248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41248"
},
{
"name": "CVE-2025-21613",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21613"
},
{
"name": "CVE-2025-15284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15284"
},
{
"name": "CVE-2024-34447",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34447"
},
{
"name": "CVE-2022-40897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
},
{
"name": "CVE-2024-29025",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29025"
},
{
"name": "CVE-2025-36424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36424"
},
{
"name": "CVE-2025-36387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36387"
},
{
"name": "CVE-2019-19921",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-19921"
},
{
"name": "CVE-2023-22081",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22081"
},
{
"name": "CVE-2025-64329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64329"
},
{
"name": "CVE-2025-27903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27903"
},
{
"name": "CVE-2015-1283",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-1283"
},
{
"name": "CVE-2025-50106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50106"
},
{
"name": "CVE-2025-37958",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37958"
},
{
"name": "CVE-2023-22041",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22041"
},
{
"name": "CVE-2022-21626",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21626"
},
{
"name": "CVE-2025-58057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58057"
},
{
"name": "CVE-2025-61727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61727"
},
{
"name": "CVE-2025-22866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22866"
},
{
"name": "CVE-2026-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21925"
},
{
"name": "CVE-2024-26308",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26308"
},
{
"name": "CVE-2016-4472",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-4472"
},
{
"name": "CVE-2025-30754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30754"
},
{
"name": "CVE-2024-10917",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10917"
},
{
"name": "CVE-2024-9042",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9042"
},
{
"name": "CVE-2025-22233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22233"
},
{
"name": "CVE-2024-31141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31141"
},
{
"name": "CVE-2025-30691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30691"
},
{
"name": "CVE-2025-57822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-57822"
},
{
"name": "CVE-2024-53113",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53113"
},
{
"name": "CVE-2024-30172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30172"
},
{
"name": "CVE-2025-67779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-67779"
},
{
"name": "CVE-2022-32743",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32743"
},
{
"name": "CVE-2025-55183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55183"
},
{
"name": "CVE-2024-51744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-51744"
},
{
"name": "CVE-2024-38820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38820"
},
{
"name": "CVE-2024-12085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12085"
},
{
"name": "CVE-2024-45338",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45338"
},
{
"name": "CVE-2023-48795",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48795"
},
{
"name": "CVE-2025-6965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6965"
},
{
"name": "CVE-2025-47906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47906"
},
{
"name": "CVE-2023-22043",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22043"
},
{
"name": "CVE-2016-4658",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-4658"
},
{
"name": "CVE-2025-31133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31133"
},
{
"name": "CVE-2024-36621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36621"
},
{
"name": "CVE-2024-23454",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23454"
},
{
"name": "CVE-2022-3510",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3510"
},
{
"name": "CVE-2022-3509",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3509"
},
{
"name": "CVE-2023-22067",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22067"
},
{
"name": "CVE-2025-55173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55173"
},
{
"name": "CVE-2024-40635",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-40635"
},
{
"name": "CVE-2024-48910",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48910"
},
{
"name": "CVE-2024-8184",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8184"
},
{
"name": "CVE-2025-38086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38086"
},
{
"name": "CVE-2025-48068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48068"
},
{
"name": "CVE-2025-27152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27152"
},
{
"name": "CVE-2022-40609",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40609"
},
{
"name": "CVE-2018-5764",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-5764"
},
{
"name": "CVE-2024-50264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50264"
},
{
"name": "CVE-2025-57752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-57752"
},
{
"name": "CVE-2024-21634",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21634"
},
{
"name": "CVE-2022-21628",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21628"
},
{
"name": "CVE-2025-38110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38110"
},
{
"name": "CVE-2020-15115",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-15115"
},
{
"name": "CVE-2024-21011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21011"
},
{
"name": "CVE-2024-45336",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45336"
},
{
"name": "CVE-2025-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52881"
},
{
"name": "CVE-2025-22868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22868"
},
{
"name": "CVE-2025-22113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22113"
},
{
"name": "CVE-2025-61724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61724"
},
{
"name": "CVE-2025-5187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5187"
},
{
"name": "CVE-2026-1188",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1188"
},
{
"name": "CVE-2025-37797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37797"
},
{
"name": "CVE-2012-2098",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-2098"
},
{
"name": "CVE-2024-41909",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41909"
},
{
"name": "CVE-2024-45296",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45296"
},
{
"name": "CVE-2023-35887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35887"
},
{
"name": "CVE-2025-21587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21587"
},
{
"name": "CVE-2025-66471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66471"
},
{
"name": "CVE-2026-21441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21441"
},
{
"name": "CVE-2024-21147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21147"
},
{
"name": "CVE-2024-56332",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56332"
},
{
"name": "CVE-2024-25710",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25710"
},
{
"name": "CVE-2026-25765",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25765"
},
{
"name": "CVE-2025-7039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7039"
},
{
"name": "CVE-2022-29458",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29458"
},
{
"name": "CVE-2024-39908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39908"
},
{
"name": "CVE-2025-27220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27220"
},
{
"name": "CVE-2024-29133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29133"
},
{
"name": "CVE-2025-55163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55163"
},
{
"name": "CVE-2024-35195",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35195"
},
{
"name": "CVE-2025-38089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38089"
},
{
"name": "CVE-2023-2727",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2727"
},
{
"name": "CVE-2024-12905",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12905"
},
{
"name": "CVE-2024-21140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21140"
},
{
"name": "CVE-2025-36425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36425"
},
{
"name": "CVE-2024-21094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21094"
},
{
"name": "CVE-2021-37404",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37404"
},
{
"name": "CVE-2025-58457",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58457"
},
{
"name": "CVE-2026-24842",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24842"
},
{
"name": "CVE-2025-47935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47935"
},
{
"name": "CVE-2025-22085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22085"
},
{
"name": "CVE-2025-50537",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50537"
},
{
"name": "CVE-2026-23950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23950"
},
{
"name": "CVE-2023-21937",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21937"
},
{
"name": "CVE-2024-52798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52798"
},
{
"name": "CVE-2024-21626",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21626"
},
{
"name": "CVE-2025-30761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30761"
},
{
"name": "CVE-2025-47912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47912"
},
{
"name": "CVE-2023-43804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-43804"
},
{
"name": "CVE-2024-47535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47535"
},
{
"name": "CVE-2022-4450",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4450"
},
{
"name": "CVE-2016-0704",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0704"
},
{
"name": "CVE-2023-33850",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33850"
},
{
"name": "CVE-2025-54410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54410"
},
{
"name": "CVE-2025-52565",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52565"
},
{
"name": "CVE-2023-2597",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2597"
},
{
"name": "CVE-2022-29154",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29154"
},
{
"name": "CVE-2025-1767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1767"
},
{
"name": "CVE-2025-58186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58186"
},
{
"name": "CVE-2025-30698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30698"
},
{
"name": "CVE-2021-22569",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22569"
},
{
"name": "CVE-2025-58187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58187"
},
{
"name": "CVE-2025-4673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4673"
},
{
"name": "CVE-2025-36001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36001"
},
{
"name": "CVE-2023-22045",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22045"
},
{
"name": "CVE-2025-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58056"
},
{
"name": "CVE-2025-22871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22871"
},
{
"name": "CVE-2024-21138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21138"
},
{
"name": "CVE-2024-47875",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47875"
},
{
"name": "CVE-2023-22049",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22049"
},
{
"name": "CVE-2025-47913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47913"
},
{
"name": "CVE-2024-6119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6119"
},
{
"name": "CVE-2018-14041",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14041"
},
{
"name": "CVE-2025-24294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24294"
},
{
"name": "CVE-2025-29927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29927"
},
{
"name": "CVE-2024-25621",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25621"
},
{
"name": "CVE-2025-36365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36365"
},
{
"name": "CVE-2023-42503",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-42503"
},
{
"name": "CVE-2025-27904",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27904"
},
{
"name": "CVE-2025-32387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32387"
},
{
"name": "CVE-2025-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58058"
},
{
"name": "CVE-2025-22869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22869"
},
{
"name": "CVE-2026-25639",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25639"
},
{
"name": "CVE-2023-5676",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5676"
},
{
"name": "CVE-2025-58189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58189"
},
{
"name": "CVE-2025-36442",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36442"
},
{
"name": "CVE-2024-28863",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28863"
},
{
"name": "CVE-2025-25193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25193"
},
{
"name": "CVE-2026-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21945"
},
{
"name": "CVE-2024-21145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21145"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2023-21968",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21968"
},
{
"name": "CVE-2025-5889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5889"
},
{
"name": "CVE-2025-21905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21905"
},
{
"name": "CVE-2024-30171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30171"
},
{
"name": "CVE-2025-30749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30749"
},
{
"name": "CVE-2025-7339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7339"
},
{
"name": "CVE-2025-14689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14689"
},
{
"name": "CVE-2025-27789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27789"
},
{
"name": "CVE-2023-21930",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21930"
},
{
"name": "CVE-2025-8916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8916"
},
{
"name": "CVE-2024-47072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47072"
},
{
"name": "CVE-2024-20918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20918"
},
{
"name": "CVE-2025-41249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41249"
},
{
"name": "CVE-2025-36366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36366"
},
{
"name": "CVE-2025-36123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36123"
},
{
"name": "CVE-2025-27900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27900"
},
{
"name": "CVE-2025-0426",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0426"
},
{
"name": "CVE-2024-3651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3651"
},
{
"name": "CVE-2025-27899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27899"
},
{
"name": "CVE-2025-64756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64756"
},
{
"name": "CVE-2023-22044",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22044"
},
{
"name": "CVE-2025-48997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48997"
},
{
"name": "CVE-2025-27901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27901"
},
{
"name": "CVE-2022-45047",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45047"
},
{
"name": "CVE-2021-22570",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22570"
},
{
"name": "CVE-2024-21085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21085"
},
{
"name": "CVE-2025-48387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48387"
},
{
"name": "CVE-2024-20945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20945"
},
{
"name": "CVE-2024-21131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21131"
},
{
"name": "CVE-2024-21210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21210"
},
{
"name": "CVE-2025-27898",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27898"
},
{
"name": "CVE-2025-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53057"
},
{
"name": "CVE-2022-3171",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3171"
},
{
"name": "CVE-2023-2728",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2728"
},
{
"name": "CVE-2024-7143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7143"
},
{
"name": "CVE-2023-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21967"
},
{
"name": "CVE-2024-34155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34155"
},
{
"name": "CVE-2022-21619",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21619"
},
{
"name": "CVE-2025-36407",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-36407"
},
{
"name": "CVE-2025-7338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7338"
},
{
"name": "CVE-2025-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53066"
},
{
"name": "CVE-2025-13465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13465"
},
{
"name": "CVE-2025-55184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55184"
},
{
"name": "CVE-2024-21217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21217"
},
{
"name": "CVE-2024-27267",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27267"
},
{
"name": "CVE-2025-59343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59343"
},
{
"name": "CVE-2024-36623",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36623"
},
{
"name": "CVE-2024-20952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20952"
},
{
"name": "CVE-2024-36620",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36620"
},
{
"name": "CVE-2025-27221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27221"
},
{
"name": "CVE-2021-20251",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20251"
},
{
"name": "CVE-2025-61729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61729"
},
{
"name": "CVE-2024-21208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21208"
},
{
"name": "CVE-2019-8331",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8331"
},
{
"name": "CVE-2025-66418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66418"
}
],
"initial_release_date": "2026-03-06T00:00:00",
"last_revision_date": "2026-03-06T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0249",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-03-06T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Injection de code indirecte \u00e0 distance (XSS)"
},
{
"description": "Injection de requ\u00eates ill\u00e9gitimes par rebond (CSRF)"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Falsification de requ\u00eates c\u00f4t\u00e9 serveur (SSRF)"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits IBM. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et un d\u00e9ni de service \u00e0 distance.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits IBM",
"vendor_advisories": [
{
"published_at": "2026-03-06",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7262753",
"url": "https://www.ibm.com/support/pages/node/7262753"
},
{
"published_at": "2026-03-06",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7262754",
"url": "https://www.ibm.com/support/pages/node/7262754"
},
{
"published_at": "2026-03-02",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7262324",
"url": "https://www.ibm.com/support/pages/node/7262324"
},
{
"published_at": "2026-03-05",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7262669",
"url": "https://www.ibm.com/support/pages/node/7262669"
},
{
"published_at": "2026-03-03",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7262494",
"url": "https://www.ibm.com/support/pages/node/7262494"
},
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7262548",
"url": "https://www.ibm.com/support/pages/node/7262548"
},
{
"published_at": "2026-03-02",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7262325",
"url": "https://www.ibm.com/support/pages/node/7262325"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 IBM 7259901",
"url": "https://www.ibm.com/support/pages/node/7259901"
}
]
}
FKIE_CVE-2025-21905
Vulnerability from fkie_nvd - Published: 2025-04-01 16:15 - Updated: 2026-06-17 08:447.1 (High) - CVSS:3.1/
| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/38f0d398b6d7640d223db69df022c4a232f24774 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/47616b82f2d42ea2060334746fed9a2988d845c9 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/59cdda202829d1d6a095d233386870a59aff986f | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/88ed69f924638c7503644e1f8eed1e976f3ffa7a | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/b02f8d5a71c8571ccf77f285737c566db73ef5e5 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c0e626f2b2390472afac52dfe72b29daf9ed8e1d | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/e0dc2c1bef722cbf16ae557690861e5f91208129 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/f265e6031d0bc4fc40c4619cb42466722b46eaa9 | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html | ||
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | 6.14 | |
| linux | linux_kernel | 6.14 | |
| linux | linux_kernel | 6.14 | |
| linux | linux_kernel | 6.14 | |
| linux | linux_kernel | 6.14 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/iwl-drv.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "38f0d398b6d7640d223db69df022c4a232f24774",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "c0e626f2b2390472afac52dfe72b29daf9ed8e1d",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "47616b82f2d42ea2060334746fed9a2988d845c9",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "88ed69f924638c7503644e1f8eed1e976f3ffa7a",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "b02f8d5a71c8571ccf77f285737c566db73ef5e5",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "f265e6031d0bc4fc40c4619cb42466722b46eaa9",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "59cdda202829d1d6a095d233386870a59aff986f",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
},
{
"lessThan": "e0dc2c1bef722cbf16ae557690861e5f91208129",
"status": "affected",
"version": "aee1b6385e29e472ae5592b9652b750a29bf702e",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/net/wireless/intel/iwlwifi/iwl-drv.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.131",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.83",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.19",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.7",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "18F68456-FFB3-4E0E-A802-F3E41C67B10E",
"versionEndExcluding": "5.4.291",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "545121FA-DE31-4154-9446-C2000FB4104D",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C708062C-4E1B-465F-AE6D-C09C46400875",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "BA9C2DE3-D37C-46C6-8DCD-2EE509456E0B",
"versionEndExcluding": "6.1.131",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "7D9F642F-6E05-4926-B0FE-62F95B7266BC",
"versionEndExcluding": "6.6.83",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "32865E5C-8AE1-4D3D-A64D-299039694A88",
"versionEndExcluding": "6.12.19",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "842F5A44-3E71-4546-B4FD-43B0ACE3F32B",
"versionEndExcluding": "6.13.7",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc1:*:*:*:*:*:*",
"matchCriteriaId": "186716B6-2B66-4BD0-852E-D48E71C0C85F",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc2:*:*:*:*:*:*",
"matchCriteriaId": "0D3E781C-403A-498F-9DA9-ECEE50F41E75",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc3:*:*:*:*:*:*",
"matchCriteriaId": "66619FB8-0AAF-4166-B2CF-67B24143261D",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc4:*:*:*:*:*:*",
"matchCriteriaId": "D3D6550E-6679-4560-902D-AF52DCFE905B",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.14:rc5:*:*:*:*:*:*",
"matchCriteriaId": "45B90F6B-BEC7-4D4E-883A-9DBADE021750",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0027s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0027s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: iwlwifi: limitar la cadena impresa del archivo FW. No se garantiza que el archivo siempre tenga una terminaci\u00f3n NUL, por lo que al leer la cadena, se podr\u00eda leer m\u00e1s all\u00e1 del final del TLV. Si ese es el \u00faltimo TLV del archivo, es posible que incluso pueda leer m\u00e1s all\u00e1 del final del b\u00fafer del archivo. Para solucionar esto, limite el formato de impresi\u00f3n al tama\u00f1o del b\u00fafer disponible."
}
],
"id": "CVE-2025-21905",
"lastModified": "2026-06-17T08:44:34.570",
"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"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2025-21905",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:24:24.171530Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-04-01T16:15:20.980",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/38f0d398b6d7640d223db69df022c4a232f24774"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/47616b82f2d42ea2060334746fed9a2988d845c9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/59cdda202829d1d6a095d233386870a59aff986f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/88ed69f924638c7503644e1f8eed1e976f3ffa7a"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/b02f8d5a71c8571ccf77f285737c566db73ef5e5"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c0e626f2b2390472afac52dfe72b29daf9ed8e1d"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e0dc2c1bef722cbf16ae557690861e5f91208129"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/f265e6031d0bc4fc40c4619cb42466722b46eaa9"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-125"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-7FC4-8Q5H-8MJJ
Vulnerability from github – Published: 2025-04-01 18:30 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.
{
"affected": [],
"aliases": [
"CVE-2025-21905"
],
"database_specific": {
"cwe_ids": [
"CWE-125"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T16:15:20Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0027s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0027s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.",
"id": "GHSA-7fc4-8q5h-8mjj",
"modified": "2025-11-03T21:33:20Z",
"published": "2025-04-01T18:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/38f0d398b6d7640d223db69df022c4a232f24774"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/47616b82f2d42ea2060334746fed9a2988d845c9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59cdda202829d1d6a095d233386870a59aff986f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/88ed69f924638c7503644e1f8eed1e976f3ffa7a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b02f8d5a71c8571ccf77f285737c566db73ef5e5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c0e626f2b2390472afac52dfe72b29daf9ed8e1d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e0dc2c1bef722cbf16ae557690861e5f91208129"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f265e6031d0bc4fc40c4619cb42466722b46eaa9"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
MSRC_CVE-2025-21905
Vulnerability from csaf_microsoft - Published: 2025-04-02 00:00 - Updated: 2026-02-21 02:43OESA-2025-2800 (CVE-2023-53091)
Vulnerability from osv_openeuler – Published: 2025-12-12 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ext4: update s_journal_inum if it changes after journal replay
When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.(CVE-2023-53091)
In the Linux kernel, the following vulnerability has been resolved:
vxlan: Fix nexthop hash size
The nexthop code expects a 31 bit hash, such as what is returned by fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash returned by skb_get_hash() can lead to problems related to the fact that 'int hash' is a negative number when the MSB is set.
In the case of hash threshold nexthop groups, nexthop_select_path_hthr() will disproportionately select the first nexthop group entry. In the case of resilient nexthop groups, nexthop_select_path_res() may do an out of bounds access in nh_buckets[], for example: hash = -912054133 num_nh_buckets = 2 bucket_index = 65535
which leads to the following panic:
BUG: unable to handle page fault for address: ffffc900025910c8 PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0 Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:nexthop_select_path+0x197/0xbf0 Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85 RSP: 0018:ffff88810c36f260 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77 RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8 RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219 R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0 R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900 FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 ? nexthop_select_path+0x197/0xbf0 ? nexthop_select_path+0x197/0xbf0 ? lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 ? __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10 ? __pfxlockacquire+0x10/0x10 ? pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 ? __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350 __dev_queue_xmit+0x513/0x1e20 ? __pfxdevqueue_xmit+0x10/0x10 ? pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 ? skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ? ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 ? lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfxlockacquire+0x10/0x10 ? pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 ? find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ? __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ? __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 ? __kthread_parkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60
---truncated---(CVE-2023-53192)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine:
BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool.
Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release.(CVE-2023-53282)
In the Linux kernel, the following vulnerability has been resolved:
start_kernel: Add __no_stack_protector function attribute
Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it.
Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.(CVE-2023-53491)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.(CVE-2023-53520)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without hci_conn_get, so disconn_cfm must be called so they can clean up their conn, otherwise use-after-free occurs.
ISO:
iso_sock_connect:880: sk 00000000eabd6557 iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073 hci_dev_put:1487: hci0 orig refcnt 17 __iso_chan_add:214: conn 00000000b6251073 iso_sock_clear_timer:117: sock 00000000eabd6557 state 3 ... hci_rx_work:4085: hci0 Event packet hci_event_packet:7601: hci0: event 0x0f hci_cmd_status_evt:4346: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3107: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560 hci_conn_unlink:1102: hci0: hcon 000000001696f1fd hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2 hci_chan_list_flush:2780: hcon 000000001696f1fd hci_dev_put:1487: hci0 orig refcnt 21 hci_dev_put:1487: hci0 orig refcnt 20 hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c ... <no iso_* activity on sk/conn> ... iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557 BUG: kernel NULL pointer dereference, address: 0000000000000668 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth ==========================================================
L2CAP:
hci_cmd_status_evt:4359: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3085: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585 hci_conn_unlink:1102: hci0: hcon ffff88800c999000 hci_chan_list_flush:2780: hcon ffff88800c999000 hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280 ... BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth] Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175
CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xf8/0x180 ? hci_send_acl+0x2d/0x540 [bluetooth] kasan_report+0xa8/0xe0 ? hci_send_acl+0x2d/0x540 [bluetooth] hci_send_acl+0x2d/0x540 [bluetooth] ? __pfxlockacquire+0x10/0x10 l2cap_chan_send+0x1fd/0x1300 [bluetooth] ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth] ? pfx_l2cap_chan_send+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? mark_held_locks+0x1a/0x90 l2cap_sock_sendmsg+0x100/0x170 [bluetooth] sock_write_iter+0x275/0x280 ? __pfx_sock_write_iter+0x10/0x10 ? __pfxlockacquire+0x10/0x10 do_iter_readv_writev+0x176/0x220 ? pfx_do_iter_readv_writev+0x10/0x10 ? find_held_lock+0x83/0xa0 ? selinux_file_permission+0x13e/0x210 do_iter_write+0xda/0x340 vfs_writev+0x1b4/0x400 ? __pfx_vfs_writev+0x10/0x10 ? __seccomp_filter+0x112/0x750 ? populate_seccomp_data+0x182/0x220 ? __fget_light+0xdf/0x100 ? do_writev+0x19d/0x210 do_writev+0x19d/0x210 ? __pfx_do_writev+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0x60/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 ? do_syscall_64+0x6c/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7ff45cb23e64 Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: ---truncated---(CVE-2023-53673)
In the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.(CVE-2024-38662)
In the Linux kernel, the following vulnerability has been resolved:Revert mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Patch series mm: Avoid possible overflows in dirty throttling .Dirty throttling logic assumes dirty limits in page units fit into32-bits. This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways. Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh >= 1<<32 (which is actually common - thedefault settings with 4GB of RAM will trigger this). Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs. We havediv64_ul() in case we want to be safe & cheap. Thirdly, if dirtythresholds are larger than 1<<32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)
In the Linux kernel, the following vulnerability has been resolved:nfsd: map the EBADMSG to nfserr_io to avoid warningExt4 will throw -EBADMSG through ext4_readdir when a checksum erroroccurs, resulting in the following WARNING.Fix it by mapping EBADMSG to nfserr_io.nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING[ 161.115610] ------------[ cut here ]------------[ 161.116465] nfsd: non-standard errno: -74[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0[ 161.118596] Modules linked in:[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 161.141519] PKRU: 55555554[ 161.142076] Call Trace:[ 161.142575] ? __warn+0x9b/0x140[ 161.143229] ? nfserrno+0x9d/0xd0[ 161.143872] ? report_bug+0x125/0x150[ 161.144595] ? handle_bug+0x41/0x90[ 161.145284] ? exc_invalid_op+0x14/0x70[ 161.146009] ? asm_exc_invalid_op+0x12/0x20[ 161.146816] ? nfserrno+0x9d/0xd0[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170[ 161.151004] ? generic_file_llseek_size+0x48/0x160[ 161.151895] nfsd_readdir+0x132/0x190[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.153516] ? nfsd_unlink+0x380/0x380[ 161.154256] ? override_creds+0x45/0x60[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0[ 161.158494] ? lock_downgrade+0x90/0x90[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10[ 161.160092] nfsd4_encode_operation+0x15a/0x440[ 161.160959] nfsd4_proc_compound+0x718/0xe90[ 161.161818] nfsd_dispatch+0x18e/0x2c0[ 161.162586] svc_process_common+0x786/0xc50[ 161.163403] ? nfsd_svc+0x380/0x380[ 161.164137] ? svc_printk+0x160/0x160[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380[ 161.165808] ? nfsd_svc+0x380/0x380[ 161.166523] ? rcu_is_watching+0x23/0x40[ 161.167309] svc_process+0x1a5/0x200[ 161.168019] nfsd+0x1f5/0x380[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260[ 161.169554] kthread+0x1c4/0x210[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80[ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: rockchip_saradc: fix information leak in triggered buffer
The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57907)
In the Linux kernel, the following vulnerability has been resolved:
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace.(CVE-2024-57911)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20
Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---(CVE-2025-22020)
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---(CVE-2025-22022)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix overflow in dacloffset bounds check
The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().
This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.
This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.(CVE-2025-22039)
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint
If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang:
- Use-after-free when no tpgs are found:
This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do:
vhost_vq_set_backend(vq, vs_tpg); ...
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via:
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If a scsi request is then sent we do:
vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend
which sees the vs_tpg we just did a kfree on.
- Tpg dir removal hang:
This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.
The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg.
Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.
- Tpg leak:
This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names.
The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs.
Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.(CVE-2025-22083)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { / is more than half of this entry in 2nd half of the block? / if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfxdquotinitialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #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:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _bpfget_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 _bpfget_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 __bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47
Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisc_tree_reduce_backlog always calls qlen_notify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdisc_reset() and / or qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing the following qdisc_tree_reduce_backlog() to report to the parent. Note that this may call qlen_notify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifs_oplock_break
A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting:
cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF
The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.(CVE-2025-38527)
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.(CVE-2025-38617)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()
snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)
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:
KVM: arm64: Prevent access to vCPU events before init
Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception.
In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection:
kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.(CVE-2025-40102)
In the Linux kernel, the following vulnerability has been resolved:
smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().
smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname().
Note that the returned value of smc_clc_prfx_set() is not used in the caller.
While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.(CVE-2025-40139)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"perf-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"perf-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.196.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-294.0.0.196.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: update s_journal_inum if it changes after journal replay\n\nWhen mounting a crafted ext4 image, s_journal_inum may change after journal\nreplay, which is obviously unreasonable because we have successfully loaded\nand replayed the journal through the old s_journal_inum. And the new\ns_journal_inum bypasses some of the checks in ext4_get_journal(), which\nmay trigger a null pointer dereference problem. So if s_journal_inum\nchanges after the journal replay, we ignore the change, and rewrite the\ncurrent journal_inum to the superblock.(CVE-2023-53091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix nexthop hash size\n\nThe nexthop code expects a 31 bit hash, such as what is returned by\nfib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash\nreturned by skb_get_hash() can lead to problems related to the fact that\n\u0026apos;int hash\u0026apos; is a negative number when the MSB is set.\n\nIn the case of hash threshold nexthop groups, nexthop_select_path_hthr()\nwill disproportionately select the first nexthop group entry. In the case\nof resilient nexthop groups, nexthop_select_path_res() may do an out of\nbounds access in nh_buckets[], for example:\n hash = -912054133\n num_nh_buckets = 2\n bucket_index = 65535\n\nwhich leads to the following panic:\n\nBUG: unable to handle page fault for address: ffffc900025910c8\nPGD 100000067 P4D 100000067 PUD 10026b067 PMD 0\nOops: 0002 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nWorkqueue: ipv6_addrconf addrconf_dad_work\nRIP: 0010:nexthop_select_path+0x197/0xbf0\nCode: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff \u0026lt;4d\u0026gt; 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85\nRSP: 0018:ffff88810c36f260 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8\nRBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219\nR10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0\nR13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900\nFS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x1ee/0x5c0\n ? __pfx_is_prefetch.constprop.0+0x10/0x10\n ? __pfx_page_fault_oops+0x10/0x10\n ? search_bpf_extables+0xfe/0x1c0\n ? fixup_exception+0x3b/0x470\n ? exc_page_fault+0xf6/0x110\n ? asm_exc_page_fault+0x26/0x30\n ? nexthop_select_path+0x197/0xbf0\n ? nexthop_select_path+0x197/0xbf0\n ? lock_is_held_type+0xe7/0x140\n vxlan_xmit+0x5b2/0x2340\n ? __lock_acquire+0x92b/0x3370\n ? __pfx_vxlan_xmit+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_register_lock_class+0x10/0x10\n ? skb_network_protocol+0xce/0x2d0\n ? dev_hard_start_xmit+0xca/0x350\n ? __pfx_vxlan_xmit+0x10/0x10\n dev_hard_start_xmit+0xca/0x350\n __dev_queue_xmit+0x513/0x1e20\n ? __pfx___dev_queue_xmit+0x10/0x10\n ? __pfx_lock_release+0x10/0x10\n ? mark_held_locks+0x44/0x90\n ? skb_push+0x4c/0x80\n ? eth_header+0x81/0xe0\n ? __pfx_eth_header+0x10/0x10\n ? neigh_resolve_output+0x215/0x310\n ? ip6_finish_output2+0x2ba/0xc90\n ip6_finish_output2+0x2ba/0xc90\n ? lock_release+0x236/0x3e0\n ? ip6_mtu+0xbb/0x240\n ? __pfx_ip6_finish_output2+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? lock_is_held_type+0xe7/0x140\n ip6_finish_output+0x1ee/0x780\n ip6_output+0x138/0x460\n ? __pfx_ip6_output+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n ? __pfx_ip6_finish_output+0x10/0x10\n NF_HOOK.constprop.0+0xc0/0x420\n ? __pfx_NF_HOOK.constprop.0+0x10/0x10\n ? ndisc_send_skb+0x2c0/0x960\n ? __pfx_lock_release+0x10/0x10\n ? __local_bh_enable_ip+0x93/0x110\n ? lock_is_held_type+0xe7/0x140\n ndisc_send_skb+0x4be/0x960\n ? __pfx_ndisc_send_skb+0x10/0x10\n ? mark_held_locks+0x65/0x90\n ? find_held_lock+0x83/0xa0\n ndisc_send_ns+0xb0/0x110\n ? __pfx_ndisc_send_ns+0x10/0x10\n addrconf_dad_work+0x631/0x8e0\n ? lock_acquire+0x180/0x3f0\n ? __pfx_addrconf_dad_work+0x10/0x10\n ? mark_held_locks+0x24/0x90\n process_one_work+0x582/0x9c0\n ? __pfx_process_one_work+0x10/0x10\n ? __pfx_do_raw_spin_lock+0x10/0x10\n ? mark_held_locks+0x24/0x90\n worker_thread+0x93/0x630\n ? __kthread_parkme+0xdc/0x100\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x1a5/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n \n---truncated---(CVE-2023-53192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write\n\nDuring the sysfs firmware write process, a use-after-free read warning is\nlogged from the lpfc_wr_object() routine:\n\n BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]\n Use-after-free read at 0x0000000000cf164d (in kfence-#111):\n lpfc_wr_object+0x235/0x310 [lpfc]\n lpfc_write_firmware.cold+0x206/0x30d [lpfc]\n lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]\n lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]\n kernfs_fop_write_iter+0x121/0x1b0\n new_sync_write+0x11c/0x1b0\n vfs_write+0x1ef/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x59/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe driver accessed wr_object pointer data, which was initialized into\nmailbox payload memory, after the mailbox object was released back to the\nmailbox pool.\n\nFix by moving the mailbox free calls to the end of the routine ensuring\nthat we don\u0026apos;t reference internal mailbox memory after release.(CVE-2023-53282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstart_kernel: Add __no_stack_protector function attribute\n\nBack during the discussion of\ncommit a9a3ed1eff36 (\u0026quot;x86: Fix early boot crash on gcc-10, third try\u0026quot;)\nwe discussed the need for a function attribute to control the omission\nof stack protectors on a per-function basis; at the time Clang had\nsupport for no_stack_protector but GCC did not. This was fixed in\ngcc-11. Now that the function attribute is available, let\u0026apos;s start using\nit.\n\nCallers of boot_init_stack_canary need to use this function attribute\nunless they\u0026apos;re compiled with -fno-stack-protector, otherwise the canary\nstored in the stack slot of the caller will differ upon the call to\nboot_init_stack_canary. This will lead to a call to __stack_chk_fail()\nthen panic.(CVE-2023-53491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix hci_suspend_sync crash\n\nIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier\nmay still be accessing it, it can cause the program to crash.\nHere\u0026apos;s the call trace:\n \u0026lt;4\u0026gt;[102152.653246] Call Trace:\n \u0026lt;4\u0026gt;[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]\n \u0026lt;4\u0026gt;[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]\n \u0026lt;4\u0026gt;[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]\n \u0026lt;4\u0026gt;[102152.653268] notifier_call_chain+0x43/0x6b\n \u0026lt;4\u0026gt;[102152.653271] __blocking_notifier_call_chain+0x48/0x69\n \u0026lt;4\u0026gt;[102152.653273] __pm_notifier_call_chain+0x22/0x39\n \u0026lt;4\u0026gt;[102152.653276] pm_suspend+0x287/0x57c\n \u0026lt;4\u0026gt;[102152.653278] state_store+0xae/0xe5\n \u0026lt;4\u0026gt;[102152.653281] kernfs_fop_write+0x109/0x173\n \u0026lt;4\u0026gt;[102152.653284] __vfs_write+0x16f/0x1a2\n \u0026lt;4\u0026gt;[102152.653287] ? selinux_file_permission+0xca/0x16f\n \u0026lt;4\u0026gt;[102152.653289] ? security_file_permission+0x36/0x109\n \u0026lt;4\u0026gt;[102152.653291] vfs_write+0x114/0x21d\n \u0026lt;4\u0026gt;[102152.653293] __x64_sys_write+0x7b/0xdb\n \u0026lt;4\u0026gt;[102152.653296] do_syscall_64+0x59/0x194\n \u0026lt;4\u0026gt;[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1\n\nThis patch holds the reference count of the hci_dev object while\nprocessing it in hci_suspend_notifier to avoid potential crash\ncaused by the race condition.(CVE-2023-53520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: call disconnect callback before deleting conn\n\nIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.\n\nISO, L2CAP and SCO connections refer to the hci_conn without\nhci_conn_get, so disconn_cfm must be called so they can clean up their\nconn, otherwise use-after-free occurs.\n\nISO:\n==========================================================\niso_sock_connect:880: sk 00000000eabd6557\niso_connect_cis:356: 70:1a:b8:98:ff:a2 -\u0026gt; 28:3d:c2:4a:7e:da\n...\niso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073\nhci_dev_put:1487: hci0 orig refcnt 17\n__iso_chan_add:214: conn 00000000b6251073\niso_sock_clear_timer:117: sock 00000000eabd6557 state 3\n...\nhci_rx_work:4085: hci0 Event packet\nhci_event_packet:7601: hci0: event 0x0f\nhci_cmd_status_evt:4346: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3107: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560\nhci_conn_unlink:1102: hci0: hcon 000000001696f1fd\nhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2\nhci_chan_list_flush:2780: hcon 000000001696f1fd\nhci_dev_put:1487: hci0 orig refcnt 21\nhci_dev_put:1487: hci0 orig refcnt 20\nhci_req_cmd_complete:3978: opcode 0x0406 status 0x0c\n... \u0026lt;no iso_* activity on sk/conn\u0026gt; ...\niso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557\nBUG: kernel NULL pointer dereference, address: 0000000000000668\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nRIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth\n==========================================================\n\nL2CAP:\n==================================================================\nhci_cmd_status_evt:4359: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3085: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585\nhci_conn_unlink:1102: hci0: hcon ffff88800c999000\nhci_chan_list_flush:2780: hcon ffff88800c999000\nhci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280\n...\nBUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]\nRead of size 8 at addr ffff888018ddd298 by task bluetoothd/1175\n\nCPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5b/0x90\n print_report+0xcf/0x670\n ? __virt_addr_valid+0xf8/0x180\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n kasan_report+0xa8/0xe0\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n hci_send_acl+0x2d/0x540 [bluetooth]\n ? __pfx___lock_acquire+0x10/0x10\n l2cap_chan_send+0x1fd/0x1300 [bluetooth]\n ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]\n ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]\n ? lock_release+0x1d5/0x3c0\n ? mark_held_locks+0x1a/0x90\n l2cap_sock_sendmsg+0x100/0x170 [bluetooth]\n sock_write_iter+0x275/0x280\n ? __pfx_sock_write_iter+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n do_iter_readv_writev+0x176/0x220\n ? __pfx_do_iter_readv_writev+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? selinux_file_permission+0x13e/0x210\n do_iter_write+0xda/0x340\n vfs_writev+0x1b4/0x400\n ? __pfx_vfs_writev+0x10/0x10\n ? __seccomp_filter+0x112/0x750\n ? populate_seccomp_data+0x182/0x220\n ? __fget_light+0xdf/0x100\n ? do_writev+0x19d/0x210\n do_writev+0x19d/0x210\n ? __pfx_do_writev+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0x60/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n ? do_syscall_64+0x6c/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7ff45cb23e64\nCode: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\nRSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: \n---truncated---(CVE-2023-53673)\n\nIn the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.(CVE-2024-38662)\n\nIn the Linux kernel, the following vulnerability has been resolved:Revert mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again Patch series mm: Avoid possible overflows in dirty throttling .Dirty throttling logic assumes dirty limits in page units fit into32-bits. This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways. Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh \u0026gt;= 1\u0026lt;\u0026lt;32 (which is actually common - thedefault settings with 4GB of RAM will trigger this). Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs. We havediv64_ul() in case we want to be safe \u0026amp; cheap. Thirdly, if dirtythresholds are larger than 1\u0026lt;\u0026lt;32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)\n\nIn the Linux kernel, the following vulnerability has been resolved:nfsd: map the EBADMSG to nfserr_io to avoid warningExt4 will throw -EBADMSG through ext4_readdir when a checksum erroroccurs, resulting in the following WARNING.Fix it by mapping EBADMSG to nfserr_io.nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING[ 161.115610] ------------[ cut here ]------------[ 161.116465] nfsd: non-standard errno: -74[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0[ 161.118596] Modules linked in:[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 \u0026lt;0f\u0026gt; 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 161.141519] PKRU: 55555554[ 161.142076] Call Trace:[ 161.142575] ? __warn+0x9b/0x140[ 161.143229] ? nfserrno+0x9d/0xd0[ 161.143872] ? report_bug+0x125/0x150[ 161.144595] ? handle_bug+0x41/0x90[ 161.145284] ? exc_invalid_op+0x14/0x70[ 161.146009] ? asm_exc_invalid_op+0x12/0x20[ 161.146816] ? nfserrno+0x9d/0xd0[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170[ 161.151004] ? generic_file_llseek_size+0x48/0x160[ 161.151895] nfsd_readdir+0x132/0x190[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380[ 161.153516] ? nfsd_unlink+0x380/0x380[ 161.154256] ? override_creds+0x45/0x60[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0[ 161.158494] ? lock_downgrade+0x90/0x90[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10[ 161.160092] nfsd4_encode_operation+0x15a/0x440[ 161.160959] nfsd4_proc_compound+0x718/0xe90[ 161.161818] nfsd_dispatch+0x18e/0x2c0[ 161.162586] svc_process_common+0x786/0xc50[ 161.163403] ? nfsd_svc+0x380/0x380[ 161.164137] ? svc_printk+0x160/0x160[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380[ 161.165808] ? nfsd_svc+0x380/0x380[ 161.166523] ? rcu_is_watching+0x23/0x40[ 161.167309] svc_process+0x1a5/0x200[ 161.168019] nfsd+0x1f5/0x380[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260[ 161.169554] kthread+0x1c4/0x210[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80[ 161.171246] ret_from_fork+0x1f/0x30(CVE-2024-49875)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: rockchip_saradc: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; local struct is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57907)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; array is allocated via kmalloc() and it is used to push data\nto user space from a triggered buffer, but it does not set values for\ninactive channels, as it only uses iio_for_each_active_channel()\nto assign new values.\n\nUse kzalloc for the memory allocation to avoid pushing uninitialized\ninformation to userspace.(CVE-2024-57911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---(CVE-2025-22020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Apply the link chain quirk on NEC isoc endpoints\n\nTwo clearly different specimens of NEC uPD720200 (one with start/stop\nbug, one without) were seen to cause IOMMU faults after some Missed\nService Errors. Faulting address is immediately after a transfer ring\nsegment and patched dynamic debug messages revealed that the MSE was\nreceived when waiting for a TD near the end of that segment:\n\n[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0\n[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]\n[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]\n\nIt gets even funnier if the next page is a ring segment accessible to\nthe HC. Below, it reports MSE in segment at ff1e8000, plows through a\nzero-filled page at ff1e9000 and starts reporting events for TRBs in\npage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.\n\n[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.\n[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n\nAt some point completion events change from Isoch Buffer Overrun to\nShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.\n\n[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2\n\nIt\u0026apos;s possible that data from the isochronous device were written to\nrandom buffers of pending TDs on other endpoints (either IN or OUT),\nother devices or even other HCs in the same IOMMU domain.\n\nLastly, an error from a different USB device on another HC. Was it\ncaused by the above? I don\u0026apos;t know, but it may have been. The disk\nwas working without any other issues and generated PCIe traffic to\nstarve the NEC of upstream BW and trigger those MSEs. The two HCs\nshared one x1 slot by means of a commercial \u0026quot;PCIe splitter\u0026quot; board.\n\n[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd\n[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s\n[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00\n[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0\n\nFortunately, it appears that this ridiculous bug is avoided by setting\nthe chain bit of Link TRBs on isochronous rings. Other ancient HCs are\nknown which also expect the bit to be set and they ignore Link TRBs if\nit\u0026apos;s not. Reportedly, 0.95 spec guaranteed that the bit is set.\n\nThe bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports\ntens of MSEs per second and runs into the bug within seconds. Chaining\nLink TRBs allows the same workload to run for many minutes, many times.\n\nNo ne\n---truncated---(CVE-2025-22022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix overflow in dacloffset bounds check\n\nThe dacloffset field was originally typed as int and used in an\nunchecked addition, which could overflow and bypass the existing\nbounds check in both smb_check_perm_dacl() and smb_inherit_dacl().\n\nThis could result in out-of-bounds memory access and a kernel crash\nwhen dereferencing the DACL pointer.\n\nThis patch converts dacloffset to unsigned int and uses\ncheck_add_overflow() to validate access to the DACL.(CVE-2025-22039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint\n\nIf vhost_scsi_set_endpoint is called multiple times without a\nvhost_scsi_clear_endpoint between them, we can hit multiple bugs\nfound by Haoran Zhang:\n\n1. Use-after-free when no tpgs are found:\n\nThis fixes a use after free that occurs when vhost_scsi_set_endpoint is\ncalled more than once and calls after the first call do not find any\ntpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds\ntpgs to add to the vs_tpg array match=true, so we will do:\n\nvhost_vq_set_backend(vq, vs_tpg);\n...\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf vhost_scsi_set_endpoint is called again and no tpgs are found\nmatch=false so we skip the vhost_vq_set_backend call leaving the\npointer to the vs_tpg we then free via:\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf a scsi request is then sent we do:\n\nvhost_scsi_handle_vq -\u0026gt; vhost_scsi_get_req -\u0026gt; vhost_vq_get_backend\n\nwhich sees the vs_tpg we just did a kfree on.\n\n2. Tpg dir removal hang:\n\nThis patch fixes an issue where we cannot remove a LIO/target layer\ntpg (and structs above it like the target) dir due to the refcount\ndropping to -1.\n\nThe problem is that if vhost_scsi_set_endpoint detects a tpg is already\nin the vs-\u0026gt;vs_tpg array or if the tpg has been removed so\ntarget_depend_item fails, the undepend goto handler will do\ntarget_undepend_item on all tpgs in the vs_tpg array dropping their\nrefcount to 0. At this time vs_tpg contains both the tpgs we have added\nin the current vhost_scsi_set_endpoint call as well as tpgs we added in\nprevious calls which are also in vs-\u0026gt;vs_tpg.\n\nLater, when vhost_scsi_clear_endpoint runs it will do\ntarget_undepend_item on all the tpgs in the vs-\u0026gt;vs_tpg which will drop\ntheir refcount to -1. Userspace will then not be able to remove the tpg\nand will hang when it tries to do rmdir on the tpg dir.\n\n3. Tpg leak:\n\nThis fixes a bug where we can leak tpgs and cause them to be\nun-removable because the target name is overwritten when\nvhost_scsi_set_endpoint is called multiple times but with different\ntarget names.\n\nThe bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup\na vhost-scsi device to target/tpg mapping, then calls\nVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we\nhaven\u0026apos;t seen before (target1 has tpg1 but target2 has tpg2). When this\nhappens we don\u0026apos;t teardown the old target tpg mapping and just overwrite\nthe target name and the vs-\u0026gt;vs_tpg array. Later when we do\nvhost_scsi_clear_endpoint, we are passed in either target1 or target2\u0026apos;s\nname and we will only match that target\u0026apos;s tpgs when we loop over the\nvs-\u0026gt;vs_tpg. We will then return from the function without doing\ntarget_undepend_item on the tpgs.\n\nBecause of all these bugs, it looks like being able to call\nvhost_scsi_set_endpoint multiple times was never supported. The major\nuser, QEMU, already has checks to prevent this use case. So to fix the\nissues, this patch prevents vhost_scsi_set_endpoint from being called\nif it\u0026apos;s already successfully added tpgs. To add, remove or change the\ntpg config or target name, you must do a vhost_scsi_clear_endpoint\nfirst.(CVE-2025-22083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\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_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nThe following loop is located right above \u0026apos;if\u0026apos; statement.\n\nfor (i = count-1; i \u0026gt;= 0; i--) {\n\t/* is more than half of this entry in 2nd half of the block? */\n\tif (size + map[i].size/2 \u0026gt; blocksize/2)\n\t\tbreak;\n\tsize += map[i].size;\n\tmove++;\n}\n\n\u0026apos;i\u0026apos; in this case could go down to -1, in which case sum of active entries\nwouldn\u0026apos;t exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix WARN() in get_bpf_raw_tp_regs\n\nsyzkaller reported an issue:\n\nWARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nModules linked in:\nCPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #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:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nRSP: 0018:ffffc90003636fa8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c\nRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005\nRBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003\nR10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004\nR13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900\nFS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]\n bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]\n __bpf_prog_run include/linux/filter.h:718 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]\n bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405\n __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47\n __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47\n __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35\n __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]\n mmap_read_trylock include/linux/mmap_lock.h:204 [inline]\n stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157\n __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483\n ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]\n bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]\n bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n\nTracepoint like trace_mmap_lock_acquire_returned may cause nested call\nas the corner case show above, which will be resolved with more general\nmethod in the future. As a result, WARN_ON_ONCE will be triggered. As\nAlexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes\u0026apos; dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent\u0026apos;s parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n tc qdisc add dev lo root handle 1: drr\n tc filter add dev lo parent 1: basic classid 1:1\n tc class add dev lo parent 1: classid 1:1 drr\n tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n tc qdisc add dev lo parent 2:1 handle 3: netem\n tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n tc class delete dev lo classid 1:1\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in cifs_oplock_break\n\nA race condition can occur in cifs_oplock_break() leading to a\nuse-after-free of the cinode structure when unmounting:\n\n cifs_oplock_break()\n _cifsFileInfo_put(cfile)\n cifsFileInfo_put_final()\n cifs_sb_deactive()\n [last ref, start releasing sb]\n kill_sb()\n kill_anon_super()\n generic_shutdown_super()\n evict_inodes()\n dispose_list()\n evict()\n destroy_inode()\n call_rcu(\u0026amp;inode-\u0026gt;i_rcu, i_callback)\n spin_lock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- OK\n [later] i_callback()\n cifs_free_inode()\n kmem_cache_free(cinode)\n spin_unlock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- UAF\n cifs_done_oplock_break(cinode) \u0026lt;- UAF\n\nThe issue occurs when umount has already released its reference to the\nsuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this\nreleases the last reference, triggering the immediate cleanup of all\ninodes under RCU. However, cifs_oplock_break() continues to access the\ncinode after this point, resulting in use-after-free.\n\nFix this by holding an extra reference to the superblock during the\nentire oplock break operation. This ensures that the superblock and\nits inodes remain valid until the oplock break completes.(CVE-2025-38527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix a null pointer dereference in ice_copy_and_init_pkg()\n\nAdd check for the return value of devm_kmemdup()\nto prevent potential null pointer dereference.(CVE-2025-38664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()\n\nsnd_soc_remove_pcm_runtime() might be called with rtd == NULL which will\nleads to null pointer dereference.\nThis was reproduced with topology loading and marking a link as ignore\ndue to missing hardware component on the system.\nOn module removal the soc_tplg_remove_link() would call\nsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,\nno runtime was created.(CVE-2025-38706)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\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\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0026apos;t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0026apos;ve been\nthrown away by the eventual reset of the vCPU\u0026apos;s state.(CVE-2025-40102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().\n\nsmc_clc_prfx_set() is called during connect() and not under RCU\nnor RTNL.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()\nafter kernel_getsockname().\n\nNote that the returned value of smc_clc_prfx_set() is not used\nin the caller.\n\nWhile at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()\nnot to touch dst there.(CVE-2025-40139)",
"id": "OESA-2025-2800",
"modified": "2026-08-06T11:09:55Z",
"published": "2025-12-12T11:09:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2800"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53491"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53520"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38662"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49875"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40139"
}
],
"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-2023-53091",
"CVE-2023-53192",
"CVE-2023-53282",
"CVE-2023-53491",
"CVE-2023-53520",
"CVE-2023-53673",
"CVE-2024-38662",
"CVE-2024-42102",
"CVE-2024-49875",
"CVE-2024-57907",
"CVE-2024-57911",
"CVE-2024-58034",
"CVE-2025-21905",
"CVE-2025-22020",
"CVE-2025-22022",
"CVE-2025-22039",
"CVE-2025-22083",
"CVE-2025-23150",
"CVE-2025-23158",
"CVE-2025-37749",
"CVE-2025-37785",
"CVE-2025-37789",
"CVE-2025-37927",
"CVE-2025-38201",
"CVE-2025-38285",
"CVE-2025-38350",
"CVE-2025-38527",
"CVE-2025-38617",
"CVE-2025-38664",
"CVE-2025-38706",
"CVE-2025-38729",
"CVE-2025-39851",
"CVE-2025-40102",
"CVE-2025-40139"
]
}
OESA-2025-2801 (CVE-2023-53091)
Vulnerability from osv_openeuler – Published: 2025-12-12 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
ext4: update s_journal_inum if it changes after journal replay
When mounting a crafted ext4 image, s_journal_inum may change after journal replay, which is obviously unreasonable because we have successfully loaded and replayed the journal through the old s_journal_inum. And the new s_journal_inum bypasses some of the checks in ext4_get_journal(), which may trigger a null pointer dereference problem. So if s_journal_inum changes after the journal replay, we ignore the change, and rewrite the current journal_inum to the superblock.(CVE-2023-53091)
In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write
During the sysfs firmware write process, a use-after-free read warning is logged from the lpfc_wr_object() routine:
BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc] Use-after-free read at 0x0000000000cf164d (in kfence-#111): lpfc_wr_object+0x235/0x310 [lpfc] lpfc_write_firmware.cold+0x206/0x30d [lpfc] lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc] lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc] kernfs_fop_write_iter+0x121/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1ef/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x59/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The driver accessed wr_object pointer data, which was initialized into mailbox payload memory, after the mailbox object was released back to the mailbox pool.
Fix by moving the mailbox free calls to the end of the routine ensuring that we don't reference internal mailbox memory after release.(CVE-2023-53282)
In the Linux kernel, the following vulnerability has been resolved:
start_kernel: Add __no_stack_protector function attribute
Back during the discussion of commit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try") we discussed the need for a function attribute to control the omission of stack protectors on a per-function basis; at the time Clang had support for no_stack_protector but GCC did not. This was fixed in gcc-11. Now that the function attribute is available, let's start using it.
Callers of boot_init_stack_canary need to use this function attribute unless they're compiled with -fno-stack-protector, otherwise the canary stored in the stack slot of the caller will differ upon the call to boot_init_stack_canary. This will lead to a call to __stack_chk_fail() then panic.(CVE-2023-53491)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix hci_suspend_sync crash
If hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier may still be accessing it, it can cause the program to crash. Here's the call trace: <4>[102152.653246] Call Trace: <4>[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth] <4>[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth] <4>[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth] <4>[102152.653268] notifier_call_chain+0x43/0x6b <4>[102152.653271] __blocking_notifier_call_chain+0x48/0x69 <4>[102152.653273] __pm_notifier_call_chain+0x22/0x39 <4>[102152.653276] pm_suspend+0x287/0x57c <4>[102152.653278] state_store+0xae/0xe5 <4>[102152.653281] kernfs_fop_write+0x109/0x173 <4>[102152.653284] __vfs_write+0x16f/0x1a2 <4>[102152.653287] ? selinux_file_permission+0xca/0x16f <4>[102152.653289] ? security_file_permission+0x36/0x109 <4>[102152.653291] vfs_write+0x114/0x21d <4>[102152.653293] __x64_sys_write+0x7b/0xdb <4>[102152.653296] do_syscall_64+0x59/0x194 <4>[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1
This patch holds the reference count of the hci_dev object while processing it in hci_suspend_notifier to avoid potential crash caused by the race condition.(CVE-2023-53520)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: call disconnect callback before deleting conn
In hci_cs_disconnect, we do hci_conn_del even if disconnection failed.
ISO, L2CAP and SCO connections refer to the hci_conn without hci_conn_get, so disconn_cfm must be called so they can clean up their conn, otherwise use-after-free occurs.
ISO:
iso_sock_connect:880: sk 00000000eabd6557 iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da ... iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073 hci_dev_put:1487: hci0 orig refcnt 17 __iso_chan_add:214: conn 00000000b6251073 iso_sock_clear_timer:117: sock 00000000eabd6557 state 3 ... hci_rx_work:4085: hci0 Event packet hci_event_packet:7601: hci0: event 0x0f hci_cmd_status_evt:4346: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3107: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560 hci_conn_unlink:1102: hci0: hcon 000000001696f1fd hci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2 hci_chan_list_flush:2780: hcon 000000001696f1fd hci_dev_put:1487: hci0 orig refcnt 21 hci_dev_put:1487: hci0 orig refcnt 20 hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c ... <no iso_* activity on sk/conn> ... iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557 BUG: kernel NULL pointer dereference, address: 0000000000000668 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth ==========================================================
L2CAP:
hci_cmd_status_evt:4359: hci0: opcode 0x0406 hci_cs_disconnect:2760: hci0: status 0x0c hci_sent_cmd_data:3085: hci0 opcode 0x0406 hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585 hci_conn_unlink:1102: hci0: hcon ffff88800c999000 hci_chan_list_flush:2780: hcon ffff88800c999000 hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280 ... BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth] Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175
CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xf8/0x180 ? hci_send_acl+0x2d/0x540 [bluetooth] kasan_report+0xa8/0xe0 ? hci_send_acl+0x2d/0x540 [bluetooth] hci_send_acl+0x2d/0x540 [bluetooth] ? __pfxlockacquire+0x10/0x10 l2cap_chan_send+0x1fd/0x1300 [bluetooth] ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth] ? pfx_l2cap_chan_send+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? mark_held_locks+0x1a/0x90 l2cap_sock_sendmsg+0x100/0x170 [bluetooth] sock_write_iter+0x275/0x280 ? __pfx_sock_write_iter+0x10/0x10 ? __pfxlockacquire+0x10/0x10 do_iter_readv_writev+0x176/0x220 ? pfx_do_iter_readv_writev+0x10/0x10 ? find_held_lock+0x83/0xa0 ? selinux_file_permission+0x13e/0x210 do_iter_write+0xda/0x340 vfs_writev+0x1b4/0x400 ? __pfx_vfs_writev+0x10/0x10 ? __seccomp_filter+0x112/0x750 ? populate_seccomp_data+0x182/0x220 ? __fget_light+0xdf/0x100 ? do_writev+0x19d/0x210 do_writev+0x19d/0x210 ? __pfx_do_writev+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0x60/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 ? do_syscall_64+0x6c/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7ff45cb23e64 Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: ---truncated---(CVE-2023-53673)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: rockchip_saradc: fix information leak in triggered buffer
The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57907)
In the Linux kernel, the following vulnerability has been resolved:
iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer
The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values.
Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace.(CVE-2024-57911)
In the Linux kernel, the following vulnerability has been resolved:
memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()
As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code.
This bug was found by an experimental verification tool that I am developing.
krzysztof: applied v1, adjust the commit msg to incorporate v2 parts
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove
This fixes the following crash:
================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241
CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfxschedule+0x10/0x10 ? kickpool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>
Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20
Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated---(CVE-2025-22020)
In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Apply the link chain quirk on NEC isoc endpoints
Two clearly different specimens of NEC uPD720200 (one with start/stop bug, one without) were seen to cause IOMMU faults after some Missed Service Errors. Faulting address is immediately after a transfer ring segment and patched dynamic debug messages revealed that the MSE was received when waiting for a TD near the end of that segment:
[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0 [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000] [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]
It gets even funnier if the next page is a ring segment accessible to the HC. Below, it reports MSE in segment at ff1e8000, plows through a zero-filled page at ff1e9000 and starts reporting events for TRBs in page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.
[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0 [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag. [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31 [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820
At some point completion events change from Isoch Buffer Overrun to Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.
[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13 [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820 [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2
It's possible that data from the isochronous device were written to random buffers of pending TDs on other endpoints (either IN or OUT), other devices or even other HCs in the same IOMMU domain.
Lastly, an error from a different USB device on another HC. Was it caused by the above? I don't know, but it may have been. The disk was working without any other issues and generated PCIe traffic to starve the NEC of upstream BW and trigger those MSEs. The two HCs shared one x1 slot by means of a commercial "PCIe splitter" board.
[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00 [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
Fortunately, it appears that this ridiculous bug is avoided by setting the chain bit of Link TRBs on isochronous rings. Other ancient HCs are known which also expect the bit to be set and they ignore Link TRBs if it's not. Reportedly, 0.95 spec guaranteed that the bit is set.
The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports tens of MSEs per second and runs into the bug within seconds. Chaining Link TRBs allows the same workload to run for many minutes, many times.
No ne ---truncated---(CVE-2025-22022)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix overflow in dacloffset bounds check
The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smb_check_perm_dacl() and smb_inherit_dacl().
This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.
This patch converts dacloffset to unsigned int and uses check_add_overflow() to validate access to the DACL.(CVE-2025-22039)
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint
If vhost_scsi_set_endpoint is called multiple times without a vhost_scsi_clear_endpoint between them, we can hit multiple bugs found by Haoran Zhang:
- Use-after-free when no tpgs are found:
This fixes a use after free that occurs when vhost_scsi_set_endpoint is called more than once and calls after the first call do not find any tpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds tpgs to add to the vs_tpg array match=true, so we will do:
vhost_vq_set_backend(vq, vs_tpg); ...
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If vhost_scsi_set_endpoint is called again and no tpgs are found match=false so we skip the vhost_vq_set_backend call leaving the pointer to the vs_tpg we then free via:
kfree(vs->vs_tpg); vs->vs_tpg = vs_tpg;
If a scsi request is then sent we do:
vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backend
which sees the vs_tpg we just did a kfree on.
- Tpg dir removal hang:
This patch fixes an issue where we cannot remove a LIO/target layer tpg (and structs above it like the target) dir due to the refcount dropping to -1.
The problem is that if vhost_scsi_set_endpoint detects a tpg is already in the vs->vs_tpg array or if the tpg has been removed so target_depend_item fails, the undepend goto handler will do target_undepend_item on all tpgs in the vs_tpg array dropping their refcount to 0. At this time vs_tpg contains both the tpgs we have added in the current vhost_scsi_set_endpoint call as well as tpgs we added in previous calls which are also in vs->vs_tpg.
Later, when vhost_scsi_clear_endpoint runs it will do target_undepend_item on all the tpgs in the vs->vs_tpg which will drop their refcount to -1. Userspace will then not be able to remove the tpg and will hang when it tries to do rmdir on the tpg dir.
- Tpg leak:
This fixes a bug where we can leak tpgs and cause them to be un-removable because the target name is overwritten when vhost_scsi_set_endpoint is called multiple times but with different target names.
The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup a vhost-scsi device to target/tpg mapping, then calls VHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we haven't seen before (target1 has tpg1 but target2 has tpg2). When this happens we don't teardown the old target tpg mapping and just overwrite the target name and the vs->vs_tpg array. Later when we do vhost_scsi_clear_endpoint, we are passed in either target1 or target2's name and we will only match that target's tpgs when we loop over the vs->vs_tpg. We will then return from the function without doing target_undepend_item on the tpgs.
Because of all these bugs, it looks like being able to call vhost_scsi_set_endpoint multiple times was never supported. The major user, QEMU, already has checks to prevent this use case. So to fix the issues, this patch prevents vhost_scsi_set_endpoint from being called if it's already successfully added tpgs. To add, remove or change the tpg config or target name, you must do a vhost_scsi_clear_endpoint first.(CVE-2025-22083)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix off-by-one error in do_split
Syzkaller detected a use-after-free issue in ext4_insert_dentry that was caused by out-of-bounds access due to incorrect splitting in do_split.
BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847
CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
The following loop is located right above 'if' statement.
for (i = count-1; i >= 0; i--) { / is more than half of this entry in 2nd half of the block? / if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++; }
'i' in this case could go down to -1, in which case sum of active entries wouldn't exceed half the block size, but previous behaviour would also do split in half if sum would exceed at the very last block, which in case of having too many long name files in a single block could lead to out-of-bounds access and following use-after-free.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef➤ p (struct pppoe_hdr ) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix OOB read when checking dotdot dir
Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).
ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block.
If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.
Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).
Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.
This issue was found by syzkaller tool.
Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfxdquotinitialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)
In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX
Otherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when resizing hashtable because __GFP_NOWARN is unset.
Similar to:
b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix WARN() in get_bpf_raw_tp_regs
syzkaller reported an issue:
WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 Modules linked in: CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #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:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861 RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c RDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005 RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003 R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004 R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900 FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _bpfget_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 _bpfget_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 __bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47
Tracepoint like trace_mmap_lock_acquire_returned may cause nested call as the corner case show above, which will be resolved with more general method in the future. As a result, WARN_ON_ONCE will be triggered. As Alexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisc_tree_reduce_backlog always calls qlen_notify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdisc_reset() and / or qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing the following qdisc_tree_reduce_backlog() to report to the parent. Note that this may call qlen_notify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free in cifs_oplock_break
A race condition can occur in cifs_oplock_break() leading to a use-after-free of the cinode structure when unmounting:
cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAF
The issue occurs when umount has already released its reference to the superblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifs_oplock_break() continues to access the cinode after this point, resulting in use-after-free.
Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.(CVE-2025-38527)
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packet_set_ring() and packet_notifier()
When packet_set_ring() releases po->bind_lock, another thread can run packet_notifier() and process an NETDEV_UP event.
This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packet_bind() and packet_notifier()").
There too the packet_notifier NETDEV_UP event managed to run while a po->bind_lock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.
The po->bind_lock in packet_set_ring and packet_notifier precede the introduction of git history.(CVE-2025-38617)
In the Linux kernel, the following vulnerability has been resolved:
ice: Fix a null pointer dereference in ice_copy_and_init_pkg()
Add check for the return value of devm_kmemdup() to prevent potential null pointer dereference.(CVE-2025-38664)
In the Linux kernel, the following vulnerability has been resolved:
ASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()
snd_soc_remove_pcm_runtime() might be called with rtd == NULL which will leads to null pointer dereference. This was reproduced with topology loading and marking a link as ignore due to missing hardware component on the system. On module removal the soc_tplg_remove_link() would call snd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored, no runtime was created.(CVE-2025-38706)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: Validate UAC3 power domain descriptors, too
UAC3 power domain descriptors need to be verified with its variable bLength for avoiding the unexpected OOB accesses by malicious firmware, too.(CVE-2025-38729)
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:
KVM: arm64: Prevent access to vCPU events before init
Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception.
In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection:
kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)
Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state.(CVE-2025-40102)
In the Linux kernel, the following vulnerability has been resolved:
smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().
smc_clc_prfx_set() is called during connect() and not under RCU nor RTNL.
Using sk_dst_get(sk)->dev could trigger UAF.
Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock() after kernel_getsockname().
Note that the returned value of smc_clc_prfx_set() is not used in the caller.
While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu() not to touch dst there.(CVE-2025-40139)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"perf-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-294.0.0.197.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"perf-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-294.0.0.197.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-294.0.0.197.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-294.0.0.197.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: update s_journal_inum if it changes after journal replay\n\nWhen mounting a crafted ext4 image, s_journal_inum may change after journal\nreplay, which is obviously unreasonable because we have successfully loaded\nand replayed the journal through the old s_journal_inum. And the new\ns_journal_inum bypasses some of the checks in ext4_get_journal(), which\nmay trigger a null pointer dereference problem. So if s_journal_inum\nchanges after the journal replay, we ignore the change, and rewrite the\ncurrent journal_inum to the superblock.(CVE-2023-53091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix use-after-free KFENCE violation during sysfs firmware write\n\nDuring the sysfs firmware write process, a use-after-free read warning is\nlogged from the lpfc_wr_object() routine:\n\n BUG: KFENCE: use-after-free read in lpfc_wr_object+0x235/0x310 [lpfc]\n Use-after-free read at 0x0000000000cf164d (in kfence-#111):\n lpfc_wr_object+0x235/0x310 [lpfc]\n lpfc_write_firmware.cold+0x206/0x30d [lpfc]\n lpfc_sli4_request_firmware_update+0xa6/0x100 [lpfc]\n lpfc_request_firmware_upgrade_store+0x66/0xb0 [lpfc]\n kernfs_fop_write_iter+0x121/0x1b0\n new_sync_write+0x11c/0x1b0\n vfs_write+0x1ef/0x280\n ksys_write+0x5f/0xe0\n do_syscall_64+0x59/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe driver accessed wr_object pointer data, which was initialized into\nmailbox payload memory, after the mailbox object was released back to the\nmailbox pool.\n\nFix by moving the mailbox free calls to the end of the routine ensuring\nthat we don\u0026apos;t reference internal mailbox memory after release.(CVE-2023-53282)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nstart_kernel: Add __no_stack_protector function attribute\n\nBack during the discussion of\ncommit a9a3ed1eff36 (\u0026quot;x86: Fix early boot crash on gcc-10, third try\u0026quot;)\nwe discussed the need for a function attribute to control the omission\nof stack protectors on a per-function basis; at the time Clang had\nsupport for no_stack_protector but GCC did not. This was fixed in\ngcc-11. Now that the function attribute is available, let\u0026apos;s start using\nit.\n\nCallers of boot_init_stack_canary need to use this function attribute\nunless they\u0026apos;re compiled with -fno-stack-protector, otherwise the canary\nstored in the stack slot of the caller will differ upon the call to\nboot_init_stack_canary. This will lead to a call to __stack_chk_fail()\nthen panic.(CVE-2023-53491)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix hci_suspend_sync crash\n\nIf hci_unregister_dev() frees the hci_dev object but hci_suspend_notifier\nmay still be accessing it, it can cause the program to crash.\nHere\u0026apos;s the call trace:\n \u0026lt;4\u0026gt;[102152.653246] Call Trace:\n \u0026lt;4\u0026gt;[102152.653254] hci_suspend_sync+0x109/0x301 [bluetooth]\n \u0026lt;4\u0026gt;[102152.653259] hci_suspend_dev+0x78/0xcd [bluetooth]\n \u0026lt;4\u0026gt;[102152.653263] hci_suspend_notifier+0x42/0x7a [bluetooth]\n \u0026lt;4\u0026gt;[102152.653268] notifier_call_chain+0x43/0x6b\n \u0026lt;4\u0026gt;[102152.653271] __blocking_notifier_call_chain+0x48/0x69\n \u0026lt;4\u0026gt;[102152.653273] __pm_notifier_call_chain+0x22/0x39\n \u0026lt;4\u0026gt;[102152.653276] pm_suspend+0x287/0x57c\n \u0026lt;4\u0026gt;[102152.653278] state_store+0xae/0xe5\n \u0026lt;4\u0026gt;[102152.653281] kernfs_fop_write+0x109/0x173\n \u0026lt;4\u0026gt;[102152.653284] __vfs_write+0x16f/0x1a2\n \u0026lt;4\u0026gt;[102152.653287] ? selinux_file_permission+0xca/0x16f\n \u0026lt;4\u0026gt;[102152.653289] ? security_file_permission+0x36/0x109\n \u0026lt;4\u0026gt;[102152.653291] vfs_write+0x114/0x21d\n \u0026lt;4\u0026gt;[102152.653293] __x64_sys_write+0x7b/0xdb\n \u0026lt;4\u0026gt;[102152.653296] do_syscall_64+0x59/0x194\n \u0026lt;4\u0026gt;[102152.653299] entry_SYSCALL_64_after_hwframe+0x5c/0xc1\n\nThis patch holds the reference count of the hci_dev object while\nprocessing it in hci_suspend_notifier to avoid potential crash\ncaused by the race condition.(CVE-2023-53520)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: call disconnect callback before deleting conn\n\nIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.\n\nISO, L2CAP and SCO connections refer to the hci_conn without\nhci_conn_get, so disconn_cfm must be called so they can clean up their\nconn, otherwise use-after-free occurs.\n\nISO:\n==========================================================\niso_sock_connect:880: sk 00000000eabd6557\niso_connect_cis:356: 70:1a:b8:98:ff:a2 -\u0026gt; 28:3d:c2:4a:7e:da\n...\niso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073\nhci_dev_put:1487: hci0 orig refcnt 17\n__iso_chan_add:214: conn 00000000b6251073\niso_sock_clear_timer:117: sock 00000000eabd6557 state 3\n...\nhci_rx_work:4085: hci0 Event packet\nhci_event_packet:7601: hci0: event 0x0f\nhci_cmd_status_evt:4346: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3107: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560\nhci_conn_unlink:1102: hci0: hcon 000000001696f1fd\nhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2\nhci_chan_list_flush:2780: hcon 000000001696f1fd\nhci_dev_put:1487: hci0 orig refcnt 21\nhci_dev_put:1487: hci0 orig refcnt 20\nhci_req_cmd_complete:3978: opcode 0x0406 status 0x0c\n... \u0026lt;no iso_* activity on sk/conn\u0026gt; ...\niso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557\nBUG: kernel NULL pointer dereference, address: 0000000000000668\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nRIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth\n==========================================================\n\nL2CAP:\n==================================================================\nhci_cmd_status_evt:4359: hci0: opcode 0x0406\nhci_cs_disconnect:2760: hci0: status 0x0c\nhci_sent_cmd_data:3085: hci0 opcode 0x0406\nhci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585\nhci_conn_unlink:1102: hci0: hcon ffff88800c999000\nhci_chan_list_flush:2780: hcon ffff88800c999000\nhci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280\n...\nBUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]\nRead of size 8 at addr ffff888018ddd298 by task bluetoothd/1175\n\nCPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x5b/0x90\n print_report+0xcf/0x670\n ? __virt_addr_valid+0xf8/0x180\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n kasan_report+0xa8/0xe0\n ? hci_send_acl+0x2d/0x540 [bluetooth]\n hci_send_acl+0x2d/0x540 [bluetooth]\n ? __pfx___lock_acquire+0x10/0x10\n l2cap_chan_send+0x1fd/0x1300 [bluetooth]\n ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth]\n ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth]\n ? lock_release+0x1d5/0x3c0\n ? mark_held_locks+0x1a/0x90\n l2cap_sock_sendmsg+0x100/0x170 [bluetooth]\n sock_write_iter+0x275/0x280\n ? __pfx_sock_write_iter+0x10/0x10\n ? __pfx___lock_acquire+0x10/0x10\n do_iter_readv_writev+0x176/0x220\n ? __pfx_do_iter_readv_writev+0x10/0x10\n ? find_held_lock+0x83/0xa0\n ? selinux_file_permission+0x13e/0x210\n do_iter_write+0xda/0x340\n vfs_writev+0x1b4/0x400\n ? __pfx_vfs_writev+0x10/0x10\n ? __seccomp_filter+0x112/0x750\n ? populate_seccomp_data+0x182/0x220\n ? __fget_light+0xdf/0x100\n ? do_writev+0x19d/0x210\n do_writev+0x19d/0x210\n ? __pfx_do_writev+0x10/0x10\n ? mark_held_locks+0x1a/0x90\n do_syscall_64+0x60/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n ? do_syscall_64+0x6c/0x90\n ? lockdep_hardirqs_on_prepare+0x149/0x210\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7ff45cb23e64\nCode: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\nRSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014\nRAX: ffffffffffffffda RBX: \n---truncated---(CVE-2023-53673)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: adc: rockchip_saradc: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; local struct is used to push data to user space from a\ntriggered buffer, but it does not set values for inactive channels, as\nit only uses iio_for_each_active_channel() to assign new values.\n\nInitialize the struct to zero before using it to avoid pushing\nuninitialized information to userspace.(CVE-2024-57907)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer\n\nThe \u0026apos;data\u0026apos; array is allocated via kmalloc() and it is used to push data\nto user space from a triggered buffer, but it does not set values for\ninactive channels, as it only uses iio_for_each_active_channel()\nto assign new values.\n\nUse kzalloc for the memory allocation to avoid pushing uninitialized\ninformation to userspace.(CVE-2024-57911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()\n\nAs of_find_node_by_name() release the reference of the argument device\nnode, tegra_emc_find_node_by_ram_code() releases some device nodes while\nstill in use, resulting in possible UAFs. According to the bindings and\nthe in-tree DTS files, the \u0026quot;emc-tables\u0026quot; node is always device\u0026apos;s child\nnode with the property \u0026quot;nvidia,use-ram-code\u0026quot;, and the \u0026quot;lpddr2\u0026quot; node is a\nchild of the \u0026quot;emc-tables\u0026quot; node. Thus utilize the\nfor_each_child_of_node() macro and of_get_child_by_name() instead of\nof_find_node_by_name() to simplify the code.\n\nThis bug was found by an experimental verification tool that I am\ndeveloping.\n\n[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts](CVE-2024-58034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---(CVE-2025-22020)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: xhci: Apply the link chain quirk on NEC isoc endpoints\n\nTwo clearly different specimens of NEC uPD720200 (one with start/stop\nbug, one without) were seen to cause IOMMU faults after some Missed\nService Errors. Faulting address is immediately after a transfer ring\nsegment and patched dynamic debug messages revealed that the MSE was\nreceived when waiting for a TD near the end of that segment:\n\n[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0\n[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]\n[ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]\n\nIt gets even funnier if the next page is a ring segment accessible to\nthe HC. Below, it reports MSE in segment at ff1e8000, plows through a\nzero-filled page at ff1e9000 and starts reporting events for TRBs in\npage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.\n\n[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0\n[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.\n[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint\n[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31\n[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n\nAt some point completion events change from Isoch Buffer Overrun to\nShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.\n\n[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13\n[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820\n[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2\n\nIt\u0026apos;s possible that data from the isochronous device were written to\nrandom buffers of pending TDs on other endpoints (either IN or OUT),\nother devices or even other HCs in the same IOMMU domain.\n\nLastly, an error from a different USB device on another HC. Was it\ncaused by the above? I don\u0026apos;t know, but it may have been. The disk\nwas working without any other issues and generated PCIe traffic to\nstarve the NEC of upstream BW and trigger those MSEs. The two HCs\nshared one x1 slot by means of a commercial \u0026quot;PCIe splitter\u0026quot; board.\n\n[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd\n[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s\n[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00\n[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0\n\nFortunately, it appears that this ridiculous bug is avoided by setting\nthe chain bit of Link TRBs on isochronous rings. Other ancient HCs are\nknown which also expect the bit to be set and they ignore Link TRBs if\nit\u0026apos;s not. Reportedly, 0.95 spec guaranteed that the bit is set.\n\nThe bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports\ntens of MSEs per second and runs into the bug within seconds. Chaining\nLink TRBs allows the same workload to run for many minutes, many times.\n\nNo ne\n---truncated---(CVE-2025-22022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix overflow in dacloffset bounds check\n\nThe dacloffset field was originally typed as int and used in an\nunchecked addition, which could overflow and bypass the existing\nbounds check in both smb_check_perm_dacl() and smb_inherit_dacl().\n\nThis could result in out-of-bounds memory access and a kernel crash\nwhen dereferencing the DACL pointer.\n\nThis patch converts dacloffset to unsigned int and uses\ncheck_add_overflow() to validate access to the DACL.(CVE-2025-22039)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpoint\n\nIf vhost_scsi_set_endpoint is called multiple times without a\nvhost_scsi_clear_endpoint between them, we can hit multiple bugs\nfound by Haoran Zhang:\n\n1. Use-after-free when no tpgs are found:\n\nThis fixes a use after free that occurs when vhost_scsi_set_endpoint is\ncalled more than once and calls after the first call do not find any\ntpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first finds\ntpgs to add to the vs_tpg array match=true, so we will do:\n\nvhost_vq_set_backend(vq, vs_tpg);\n...\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf vhost_scsi_set_endpoint is called again and no tpgs are found\nmatch=false so we skip the vhost_vq_set_backend call leaving the\npointer to the vs_tpg we then free via:\n\nkfree(vs-\u0026gt;vs_tpg);\nvs-\u0026gt;vs_tpg = vs_tpg;\n\nIf a scsi request is then sent we do:\n\nvhost_scsi_handle_vq -\u0026gt; vhost_scsi_get_req -\u0026gt; vhost_vq_get_backend\n\nwhich sees the vs_tpg we just did a kfree on.\n\n2. Tpg dir removal hang:\n\nThis patch fixes an issue where we cannot remove a LIO/target layer\ntpg (and structs above it like the target) dir due to the refcount\ndropping to -1.\n\nThe problem is that if vhost_scsi_set_endpoint detects a tpg is already\nin the vs-\u0026gt;vs_tpg array or if the tpg has been removed so\ntarget_depend_item fails, the undepend goto handler will do\ntarget_undepend_item on all tpgs in the vs_tpg array dropping their\nrefcount to 0. At this time vs_tpg contains both the tpgs we have added\nin the current vhost_scsi_set_endpoint call as well as tpgs we added in\nprevious calls which are also in vs-\u0026gt;vs_tpg.\n\nLater, when vhost_scsi_clear_endpoint runs it will do\ntarget_undepend_item on all the tpgs in the vs-\u0026gt;vs_tpg which will drop\ntheir refcount to -1. Userspace will then not be able to remove the tpg\nand will hang when it tries to do rmdir on the tpg dir.\n\n3. Tpg leak:\n\nThis fixes a bug where we can leak tpgs and cause them to be\nun-removable because the target name is overwritten when\nvhost_scsi_set_endpoint is called multiple times but with different\ntarget names.\n\nThe bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setup\na vhost-scsi device to target/tpg mapping, then calls\nVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs we\nhaven\u0026apos;t seen before (target1 has tpg1 but target2 has tpg2). When this\nhappens we don\u0026apos;t teardown the old target tpg mapping and just overwrite\nthe target name and the vs-\u0026gt;vs_tpg array. Later when we do\nvhost_scsi_clear_endpoint, we are passed in either target1 or target2\u0026apos;s\nname and we will only match that target\u0026apos;s tpgs when we loop over the\nvs-\u0026gt;vs_tpg. We will then return from the function without doing\ntarget_undepend_item on the tpgs.\n\nBecause of all these bugs, it looks like being able to call\nvhost_scsi_set_endpoint multiple times was never supported. The major\nuser, QEMU, already has checks to prevent this use case. So to fix the\nissues, this patch prevents vhost_scsi_set_endpoint from being called\nif it\u0026apos;s already successfully added tpgs. To add, remove or change the\ntpg config or target name, you must do a vhost_scsi_clear_endpoint\nfirst.(CVE-2025-22083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix off-by-one error in do_split\n\nSyzkaller detected a use-after-free issue in ext4_insert_dentry that was\ncaused by out-of-bounds access due to incorrect splitting in do_split.\n\nBUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\nWrite of size 251 at addr ffff888074572f14 by task syz-executor335/5847\n\nCPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024\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_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109\n add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154\n make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455\n ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796\n ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431\n vfs_symlink+0x137/0x2e0 fs/namei.c:4615\n do_symlinkat+0x222/0x3a0 fs/namei.c:4641\n __do_sys_symlink fs/namei.c:4662 [inline]\n __se_sys_symlink fs/namei.c:4660 [inline]\n __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\nThe following loop is located right above \u0026apos;if\u0026apos; statement.\n\nfor (i = count-1; i \u0026gt;= 0; i--) {\n\t/* is more than half of this entry in 2nd half of the block? */\n\tif (size + map[i].size/2 \u0026gt; blocksize/2)\n\t\tbreak;\n\tsize += map[i].size;\n\tmove++;\n}\n\n\u0026apos;i\u0026apos; in this case could go down to -1, in which case sum of active entries\nwouldn\u0026apos;t exceed half the block size, but previous behaviour would also do\nsplit in half if sum would exceed at the very last block, which in case of\nhaving too many long name files in a single block could lead to\nout-of-bounds access and following use-after-free.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-23150)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef\u27a4 p *(struct pppoe_hdr *) (skb-\u0026gt;head + skb-\u0026gt;network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 4 , data = 0xffff88803346f416 : 377 , truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[(CVE-2025-37749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix OOB read when checking dotdot dir\n\nMounting a corrupted filesystem with directory which contains \u0026apos;.\u0026apos; dir\nentry with rec_len == block size results in out-of-bounds read (later\non, when the corrupted directory is removed).\n\next4_empty_dir() assumes every ext4 directory contains at least \u0026apos;.\u0026apos;\nand \u0026apos;..\u0026apos; as directory entries in the first data block. It first loads\nthe \u0026apos;.\u0026apos; dir entry, performs sanity checks by calling ext4_check_dir_entry()\nand then uses its rec_len member to compute the location of \u0026apos;..\u0026apos; dir\nentry (in ext4_next_entry). It assumes the \u0026apos;..\u0026apos; dir entry fits into the\nsame data block.\n\nIf the rec_len of \u0026apos;.\u0026apos; is precisely one block (4KB), it slips through the\nsanity checks (it is considered the last directory entry in the data\nblock) and leaves \u0026quot;struct ext4_dir_entry_2 *de\u0026quot; point exactly past the\nmemory slot allocated to the data block. The following call to\next4_check_dir_entry() on new value of de then dereferences this pointer\nwhich results in out-of-bounds mem access.\n\nFix this by extending __ext4_check_dir_entry() to check for \u0026apos;.\u0026apos; dir\nentries that reach the end of data block. Make sure to ignore the phony\ndir entries for checksum (by checking name_len for non-zero).\n\nNote: This is reported by KASAN as use-after-free in case another\nstructure was recently freed from the slot past the bound, but it is\nreally an OOB read.\n\nThis issue was found by syzkaller tool.\n\nCall Trace:\n[ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710\n[ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375\n[ 38.595158]\n[ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1\n[ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 38.595304] Call Trace:\n[ 38.595308] \u0026lt;TASK\u0026gt;\n[ 38.595311] dump_stack_lvl+0xa7/0xd0\n[ 38.595325] print_address_description.constprop.0+0x2c/0x3f0\n[ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595349] print_report+0xaa/0x250\n[ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595368] ? kasan_addr_to_slab+0x9/0x90\n[ 38.595378] kasan_report+0xab/0xe0\n[ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710\n[ 38.595400] __ext4_check_dir_entry+0x67e/0x710\n[ 38.595410] ext4_empty_dir+0x465/0x990\n[ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10\n[ 38.595432] ext4_rmdir.part.0+0x29a/0xd10\n[ 38.595441] ? __dquot_initialize+0x2a7/0xbf0\n[ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10\n[ 38.595464] ? __pfx___dquot_initialize+0x10/0x10\n[ 38.595478] ? down_write+0xdb/0x140\n[ 38.595487] ? __pfx_down_write+0x10/0x10\n[ 38.595497] ext4_rmdir+0xee/0x140\n[ 38.595506] vfs_rmdir+0x209/0x670\n[ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190\n[ 38.595529] do_rmdir+0x363/0x3c0\n[ 38.595537] ? __pfx_do_rmdir+0x10/0x10\n[ 38.595544] ? strncpy_from_user+0x1ff/0x2e0\n[ 38.595561] __x64_sys_unlinkat+0xf0/0x130\n[ 38.595570] do_syscall_64+0x5b/0x180\n[ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-37785)\n\nIn the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix nested key length validation in the set() actionIt s not safe to access nla_len(ovs_key) if the data is smaller thanthe netlink header. Check that the attribute is OK first.(CVE-2025-37789)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAX\n\nOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()\nwhen resizing hashtable because __GFP_NOWARN is unset.\n\nSimilar to:\n\n b541ba7d1f5a (\u0026quot;netfilter: conntrack: clamp maximum hashtable size to INT_MAX\u0026quot;)(CVE-2025-38201)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix WARN() in get_bpf_raw_tp_regs\n\nsyzkaller reported an issue:\n\nWARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nModules linked in:\nCPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #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:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nRSP: 0018:ffffc90003636fa8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c\nRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005\nRBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003\nR10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004\nR13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900\nFS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]\n bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]\n __bpf_prog_run include/linux/filter.h:718 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]\n bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405\n __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47\n __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47\n __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35\n __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]\n mmap_read_trylock include/linux/mmap_lock.h:204 [inline]\n stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157\n __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483\n ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]\n bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]\n bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n\nTracepoint like trace_mmap_lock_acquire_returned may cause nested call\nas the corner case show above, which will be resolved with more general\nmethod in the future. As a result, WARN_ON_ONCE will be triggered. As\nAlexei suggested, remove the WARN_ON_ONCE first.(CVE-2025-38285)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes\u0026apos; dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent\u0026apos;s parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n tc qdisc add dev lo root handle 1: drr\n tc filter add dev lo parent 1: basic classid 1:1\n tc class add dev lo parent 1: classid 1:1 drr\n tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n tc qdisc add dev lo parent 2:1 handle 3: netem\n tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n tc class delete dev lo classid 1:1\n echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in cifs_oplock_break\n\nA race condition can occur in cifs_oplock_break() leading to a\nuse-after-free of the cinode structure when unmounting:\n\n cifs_oplock_break()\n _cifsFileInfo_put(cfile)\n cifsFileInfo_put_final()\n cifs_sb_deactive()\n [last ref, start releasing sb]\n kill_sb()\n kill_anon_super()\n generic_shutdown_super()\n evict_inodes()\n dispose_list()\n evict()\n destroy_inode()\n call_rcu(\u0026amp;inode-\u0026gt;i_rcu, i_callback)\n spin_lock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- OK\n [later] i_callback()\n cifs_free_inode()\n kmem_cache_free(cinode)\n spin_unlock(\u0026amp;cinode-\u0026gt;open_file_lock) \u0026lt;- UAF\n cifs_done_oplock_break(cinode) \u0026lt;- UAF\n\nThe issue occurs when umount has already released its reference to the\nsuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this\nreleases the last reference, triggering the immediate cleanup of all\ninodes under RCU. However, cifs_oplock_break() continues to access the\ncinode after this point, resulting in use-after-free.\n\nFix this by holding an extra reference to the superblock during the\nentire oplock break operation. This ensures that the superblock and\nits inodes remain valid until the oplock break completes.(CVE-2025-38527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix a race in packet_set_ring() and packet_notifier()\n\nWhen packet_set_ring() releases po-\u0026gt;bind_lock, another thread can\nrun packet_notifier() and process an NETDEV_UP event.\n\nThis race and the fix are both similar to that of commit 15fe076edea7\n(\u0026quot;net/packet: fix a race in packet_bind() and packet_notifier()\u0026quot;).\n\nThere too the packet_notifier NETDEV_UP event managed to run while a\npo-\u0026gt;bind_lock critical section had to be temporarily released. And\nthe fix was similarly to temporarily set po-\u0026gt;num to zero to keep\nthe socket unhooked until the lock is retaken.\n\nThe po-\u0026gt;bind_lock in packet_set_ring and packet_notifier precede the\nintroduction of git history.(CVE-2025-38617)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix a null pointer dereference in ice_copy_and_init_pkg()\n\nAdd check for the return value of devm_kmemdup()\nto prevent potential null pointer dereference.(CVE-2025-38664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Check for rtd == NULL in snd_soc_remove_pcm_runtime()\n\nsnd_soc_remove_pcm_runtime() might be called with rtd == NULL which will\nleads to null pointer dereference.\nThis was reproduced with topology loading and marking a link as ignore\ndue to missing hardware component on the system.\nOn module removal the soc_tplg_remove_link() would call\nsnd_soc_remove_pcm_runtime() with rtd == NULL since the link was ignored,\nno runtime was created.(CVE-2025-38706)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Validate UAC3 power domain descriptors, too\n\nUAC3 power domain descriptors need to be verified with its variable\nbLength for avoiding the unexpected OOB accesses by malicious\nfirmware, too.(CVE-2025-38729)\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\nKVM: arm64: Prevent access to vCPU events before init\n\nAnother day, another syzkaller bug. KVM erroneously allows userspace to\npend vCPU events for a vCPU that hasn\u0026apos;t been initialized yet, leading to\nKVM interpreting a bunch of uninitialized garbage for routing /\ninjecting the exception.\n\nIn one case the injection code and the hyp disagree on whether the vCPU\nhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,\ntripping the BUG() in exception_target_el() during the next injection:\n\n kernel BUG at arch/arm64/kvm/inject_fault.c:40!\n Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT\n Hardware name: linux,dummy-virt (DT)\n pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n pc : exception_target_el+0x88/0x8c\n lr : pend_serror_exception+0x18/0x13c\n sp : ffff800082f03a10\n x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000\n x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000\n x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004\n x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000\n x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20\n Call trace:\n exception_target_el+0x88/0x8c (P)\n kvm_inject_serror_esr+0x40/0x3b4\n __kvm_arm_vcpu_set_events+0xf0/0x100\n kvm_arch_vcpu_ioctl+0x180/0x9d4\n kvm_vcpu_ioctl+0x60c/0x9f4\n __arm64_sys_ioctl+0xac/0x104\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)\n\nReject the ioctls outright as no sane VMM would call these before\nKVM_ARM_VCPU_INIT anyway. Even if it did the exception would\u0026apos;ve been\nthrown away by the eventual reset of the vCPU\u0026apos;s state.(CVE-2025-40102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().\n\nsmc_clc_prfx_set() is called during connect() and not under RCU\nnor RTNL.\n\nUsing sk_dst_get(sk)-\u0026gt;dev could trigger UAF.\n\nLet\u0026apos;s use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()\nafter kernel_getsockname().\n\nNote that the returned value of smc_clc_prfx_set() is not used\nin the caller.\n\nWhile at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()\nnot to touch dst there.(CVE-2025-40139)",
"id": "OESA-2025-2801",
"modified": "2026-08-06T11:09:55Z",
"published": "2025-12-12T11:09:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2801"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53282"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53491"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53520"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-53673"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57907"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57911"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22020"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22022"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22039"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22083"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23150"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37749"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37785"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38201"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38350"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38527"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38617"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38706"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38729"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39851"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40139"
}
],
"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-2023-53091",
"CVE-2023-53282",
"CVE-2023-53491",
"CVE-2023-53520",
"CVE-2023-53673",
"CVE-2024-57907",
"CVE-2024-57911",
"CVE-2024-58034",
"CVE-2025-21905",
"CVE-2025-22020",
"CVE-2025-22022",
"CVE-2025-22039",
"CVE-2025-22083",
"CVE-2025-23150",
"CVE-2025-23158",
"CVE-2025-37749",
"CVE-2025-37785",
"CVE-2025-37789",
"CVE-2025-37927",
"CVE-2025-38201",
"CVE-2025-38285",
"CVE-2025-38350",
"CVE-2025-38527",
"CVE-2025-38617",
"CVE-2025-38664",
"CVE-2025-38706",
"CVE-2025-38729",
"CVE-2025-39851",
"CVE-2025-40102",
"CVE-2025-40139"
]
}
OESA-2025-2882 (CVE-2024-42154)
Vulnerability from osv_openeuler – Published: 2025-12-30 11:10 – Updated: 2026-08-06 11:10 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)
In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes System RAM (kmem) a descendant of CXLWindow X . This confuses region_intersects(), which expects all SystemRAM resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be Operation not permitted instead of Bad address . Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn t allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, System RAM is a descendant of CXL Window 0 instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn t allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with System RAM not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- CXL Window 0 ------------||-- System RAM --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- System RAM --||-- CXL Window 0a --|Where CXL Window 0a is part of the original CXL Window 0 thatisn t covered by System RAM .(CVE-2024-49878)
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath10k: avoid NULL pointer error during sdio remove
When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c
This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.
After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen.
Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue
Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe().
No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore.
Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: limit printed string from FW file
There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer.
Fix that by limiting the print format to the size of the buffer we have.(CVE-2025-21905)
In the Linux kernel, the following vulnerability has been resolved:
ppp: Fix KMSAN uninit-value warning with bpf
Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter.
The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver.
As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction.
The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized.
For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN.
[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000(CVE-2025-21922)
In the Linux kernel, the following vulnerability has been resolved:
media: venus: hfi: add check to handle incorrect queue size
qsize represents size of shared queued between driver and video firmware. Firmware can modify this value to an invalid large value. In such situation, empty_space will be bigger than the space actually available. Since new_wr_idx is not checked, so the following code will result in an OOB write. ... qsize = qhdr->q_size
if (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx) .... if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB write
Add check to ensure qsize is within the allocated size while reading and writing packets into the queue.(CVE-2025-23158)
In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization
On Mediatek devices with a system companion processor (SCP) the mtk_scp structure has to be removed explicitly to avoid a resource leak. Free the structure in case the allocation of the firmware structure fails during the firmware initialization.(CVE-2025-23160)
In the Linux kernel, the following vulnerability has been resolved:
net: tls: explicitly disallow disconnect
syzbot discovered that it can disconnect a TLS socket and then run into all sort of unexpected corner cases. I have a vague recollection of Eric pointing this out to us a long time ago. Supporting disconnect is really hard, for one thing if offload is enabled we'd need to wait for all packets to be acked. Disconnect is not commonly used, disallow it.
The immediate problem syzbot run into is the warning in the strp, but that's just the easiest bug to trigger:
WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: <TASK> tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix the warning from __kernel_write_iter
[ 2110.972290] ------------[ cut here ]------------ [ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280
This patch doesn't allow writing to directory.(CVE-2025-37775)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in smb_break_all_levII_oplock()
There is a room in smb_break_all_levII_oplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.(CVE-2025-37776)
In the Linux kernel, the following vulnerability has been resolved:
pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()
With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a divide-by-zero in the following line:
do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));
due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate() returns zero.
This is presumably just a theoretical problem: COMPILE_TEST overrides the dependency on RALINK which would select COMMON_CLK. Regardless it's a good idea to check for the error explicitly to avoid divide-by-zero.
Fixes the following warning:
drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section
ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid
There is a string parsing logic error which can lead to an overflow of hid or uid buffers. Comparing ACPIID_LEN against a total string length doesn't take into account the lengths of individual hid and uid buffers so the check is insufficient in some cases. For example if the length of hid string is 4 and the length of the uid string is 260, the length of str will be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer which size is 256.
The same applies to the hid string with length 13 and uid string with length 250.
Check the length of hid and uid strings separately to prevent buffer overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)
In the Linux kernel, the following vulnerability has been resolved:
x86/sev: Evict cache lines during SNP memory validation
An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.
CPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.
Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCY_SFW_NO bit is not set, indicating the SNP guest is vulnerable.(CVE-2025-38560)
In the Linux kernel, the following vulnerability has been resolved:
i40e: remove read access to debugfs files
The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").
Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.
On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.
We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdev_ops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copy_to_user to read beyond the length of the buffer allocated by kzalloc.
A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.
Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.
In order to properly remove the i40e_dbg_netdev_ops_buf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40e_dbg_command_write, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdev_ops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size
This is inspired by the check for data_offset + data_length.(CVE-2025-39942)
In the Linux kernel, the following vulnerability has been resolved:
mm/ksm: fix flag-dropping behavior in ksm_madvise
syzkaller discovered the following crash: (kernel BUG)
[ 44.607039] ------------[ cut here ]------------ [ 44.607422] kernel BUG at mm/userfaultfd.c:2067! [ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI [ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none) [ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460
<snip other registers, drop unreliable trace>
[ 44.617726] Call Trace: [ 44.617926] <TASK> [ 44.619284] userfaultfd_release+0xef/0x1b0 [ 44.620976] __fput+0x3f9/0xb60 [ 44.621240] fput_close_sync+0x110/0x210 [ 44.622222] __x64_sys_close+0x8f/0x120 [ 44.622530] do_syscall_64+0x5b/0x2f0 [ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 44.623244] RIP: 0033:0x7f365bb3f227
Kernel panics because it detects UFFD inconsistency during userfaultfd_release_all(). Specifically, a VMA which has a valid pointer to vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.
The inconsistency is caused in ksm_madvise(): when user calls madvise() with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode, it accidentally clears all flags stored in the upper 32 bits of vma->vm_flags.
Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and int are 32-bit wide. This setup causes the following mishap during the &= ~VM_MERGEABLE assignment.
VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is then promoted to unsigned long before the & operation. This promotion fills upper 32 bits with leading 0s, as we're doing unsigned conversion (and even for a signed conversion, this wouldn't help as the leading bit is 0). & operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffff instead of intended 0xffff'ffff'7fff'ffff and hence accidentally clears the upper 32-bits of its value.
Fix it by changing VM_MERGEABLE constant to unsigned long, using the
BIT() macro.
Note: other VM_ flags are not affected: This only happens to the VM_MERGEABLE flag, as the other VM_ flags are all constants of type int and after ~ operation, they end up with leading 1 and are thus converted to unsigned long with leading 1s.
Note 2: After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this is no longer a kernel BUG, but a WARNING at the same place:
[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067
but the root-cause (flag-drop) remains the same.
[(CVE-2025-40040)
In the Linux kernel, the following vulnerability has been resolved:
net: use dst_dev_rcu() in sk_setup_caps()
Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size().
Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward().
ip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-source-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"perf-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"python3-perf-6.6.0-129.0.0.114.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.114.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-129.0.0.114.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-source-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"perf-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"python3-perf-6.6.0-129.0.0.114.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-129.0.0.114.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-129.0.0.114.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:tcp_metrics: validate source addr lengthI don t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)\n\nIn the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes System RAM (kmem) a descendant of CXLWindow X . This confuses region_intersects(), which expects all SystemRAM resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1 dd: error writing /dev/mem : Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be Operation not permitted instead of Bad address . Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn t allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, System RAM is a descendant of CXL Window 0 instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn t allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with System RAM not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- CXL Window 0 ------------||-- System RAM --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- System RAM --||-- CXL Window 0a --|Where CXL Window 0a is part of the original CXL Window 0 thatisn t covered by System RAM .(CVE-2024-49878)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during \u0026apos;rmmod ath10k\u0026apos;, ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n -\u0026gt;ath10k_core_unregister\n \u2026\u2026\n -\u0026gt;ath10k_core_stop\n -\u0026gt;ath10k_hif_stop\n -\u0026gt;ath10k_sdio_irq_disable\n -\u0026gt;ath10k_hif_power_down\n -\u0026gt;del_timer_sync(\u0026amp;ar_sdio-\u0026gt;sleep_timer)\n -\u0026gt;ath10k_core_destroy\n -\u0026gt;ath10k_mac_destroy\n -\u0026gt;ieee80211_free_hw\n -\u0026gt;wiphy_free\n \u2026\u2026\n -\u0026gt;wiphy_dev_release\n -\u0026gt;destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won\u0026apos;t be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189(CVE-2024-56599)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: limit printed string from FW file\n\nThere\u0026apos;s no guarantee here that the file is always with a\nNUL-termination, so reading the string may read beyond the\nend of the TLV. If that\u0026apos;s the last TLV in the file, it can\nperhaps even read beyond the end of the file buffer.\n\nFix that by limiting the print format to the size of the\nbuffer we have.(CVE-2025-21905)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nppp: Fix KMSAN uninit-value warning with bpf\n\nSyzbot caught an \u0026quot;KMSAN: uninit-value\u0026quot; warning [1], which is caused by the\nppp driver not initializing a 2-byte header when using socket filter.\n\nThe following code can generate a PPP filter BPF program:\n\u0026apos;\u0026apos;\u0026apos;\nstruct bpf_program fp;\npcap_t *handle;\nhandle = pcap_open_dead(DLT_PPP_PPPD, 65535);\npcap_compile(handle, \u0026amp;fp, \u0026quot;ip and outbound\u0026quot;, 0, 0);\nbpf_dump(\u0026amp;fp, 1);\n\u0026apos;\u0026apos;\u0026apos;\nIts output is:\n\u0026apos;\u0026apos;\u0026apos;\n(000) ldh [2]\n(001) jeq #0x21 jt 2 jf 5\n(002) ldb [0]\n(003) jeq #0x1 jt 4 jf 5\n(004) ret #65535\n(005) ret #0\n\u0026apos;\u0026apos;\u0026apos;\nWen can find similar code at the following link:\nhttps://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680\nThe maintainer of this code repository is also the original maintainer\nof the ppp driver.\n\nAs you can see the BPF program skips 2 bytes of data and then reads the\n\u0026apos;Protocol\u0026apos; field to determine if it\u0026apos;s an IP packet. Then it read the first\nbyte of the first 2 bytes to determine the direction.\n\nThe issue is that only the first byte indicating direction is initialized\nin current ppp driver code while the second byte is not initialized.\n\nFor normal BPF programs generated by libpcap, uninitialized data won\u0026apos;t be\nused, so it\u0026apos;s not a problem. However, for carefully crafted BPF programs,\nsuch as those generated by syzkaller [2], which start reading from offset\n0, the uninitialized data will be used and caught by KMSAN.\n\n[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791\n[2] https://syzkaller.appspot.com/text?tag=ReproC\u0026amp;x=11994913980000(CVE-2025-21922)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: venus: hfi: add check to handle incorrect queue size\n\nqsize represents size of shared queued between driver and video\nfirmware. Firmware can modify this value to an invalid large value. In\nsuch situation, empty_space will be bigger than the space actually\navailable. Since new_wr_idx is not checked, so the following code will\nresult in an OOB write.\n...\nqsize = qhdr-\u0026gt;q_size\n\nif (wr_idx \u0026gt;= rd_idx)\n empty_space = qsize - (wr_idx - rd_idx)\n....\nif (new_wr_idx \u0026lt; qsize) {\n memcpy(wr_ptr, packet, dwords \u0026lt;\u0026lt; 2) --\u0026gt; OOB write\n\nAdd check to ensure qsize is within the allocated size while\nreading and writing packets into the queue.(CVE-2025-23158)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization\n\nOn Mediatek devices with a system companion processor (SCP) the mtk_scp\nstructure has to be removed explicitly to avoid a resource leak.\nFree the structure in case the allocation of the firmware structure fails\nduring the firmware initialization.(CVE-2025-23160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: tls: explicitly disallow disconnect\n\nsyzbot discovered that it can disconnect a TLS socket and then\nrun into all sort of unexpected corner cases. I have a vague\nrecollection of Eric pointing this out to us a long time ago.\nSupporting disconnect is really hard, for one thing if offload\nis enabled we\u0026apos;d need to wait for all packets to be _acked_.\nDisconnect is not commonly used, disallow it.\n\nThe immediate problem syzbot run into is the warning in the strp,\nbut that\u0026apos;s just the easiest bug to trigger:\n\n WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486\n Call Trace:\n \u0026lt;TASK\u0026gt;\n tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363\n tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043\n inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678\n sock_recvmsg_nosec net/socket.c:1023 [inline]\n sock_recvmsg+0x109/0x280 net/socket.c:1045\n __sys_recvfrom+0x202/0x380 net/socket.c:2237(CVE-2025-37756)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix the warning from __kernel_write_iter\n\n[ 2110.972290] ------------[ cut here ]------------\n[ 2110.972301] WARNING: CPU: 3 PID: 735 at fs/read_write.c:599 __kernel_write_iter+0x21b/0x280\n\nThis patch doesn\u0026apos;t allow writing to directory.(CVE-2025-37775)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free in smb_break_all_levII_oplock()\n\nThere is a room in smb_break_all_levII_oplock that can cause racy issues\nwhen unlocking in the middle of the loop. This patch use read lock\nto protect whole loop.(CVE-2025-37776)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()\n\nWith CONFIG_COMPILE_TEST \u0026amp;\u0026amp; !CONFIG_HAVE_CLK, pwm_mediatek_config() has a\ndivide-by-zero in the following line:\n\n\tdo_div(resolution, clk_get_rate(pc-\u0026gt;clk_pwms[pwm-\u0026gt;hwpwm]));\n\ndue to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()\nreturns zero.\n\nThis is presumably just a theoretical problem: COMPILE_TEST overrides\nthe dependency on RALINK which would select COMMON_CLK. Regardless it\u0026apos;s\na good idea to check for the error explicitly to avoid divide-by-zero.\n\nFixes the following warning:\n\n drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section\n\n[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/](CVE-2025-37850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix potential buffer overflow in parse_ivrs_acpihid\n\nThere is a string parsing logic error which can lead to an overflow of hid\nor uid buffers. Comparing ACPIID_LEN against a total string length doesn\u0026apos;t\ntake into account the lengths of individual hid and uid buffers so the\ncheck is insufficient in some cases. For example if the length of hid\nstring is 4 and the length of the uid string is 260, the length of str\nwill be equal to ACPIID_LEN + 1 but uid string will overflow uid buffer\nwhich size is 256.\n\nThe same applies to the hid string with length 13 and uid string with\nlength 250.\n\nCheck the length of hid and uid strings separately to prevent\nbuffer overflow.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-37927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/sev: Evict cache lines during SNP memory validation\n\nAn SNP cache coherency vulnerability requires a cache line eviction\nmitigation when validating memory after a page state change to private.\nThe specific mitigation is to touch the first and last byte of each 4K\npage that is being validated. There is no need to perform the mitigation\nwhen performing a page state change to shared and rescinding validation.\n\nCPUID bit Fn8000001F_EBX[31] defines the COHERENCY_SFW_NO CPUID bit\nthat, when set, indicates that the software mitigation for this\nvulnerability is not needed.\n\nImplement the mitigation and invoke it when validating memory (making it\nprivate) and the COHERENCY_SFW_NO bit is not set, indicating the SNP\nguest is vulnerable.(CVE-2025-38560)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni40e: remove read access to debugfs files\n\nThe \u0026apos;command\u0026apos; and \u0026apos;netdev_ops\u0026apos; debugfs files are a legacy debugging\ninterface supported by the i40e driver since its early days by commit\n02e9c290814c (\u0026quot;i40e: debugfs interface\u0026quot;).\n\nBoth of these debugfs files provide a read handler which is mostly useless,\nand which is implemented with questionable logic. They both use a static\n256 byte buffer which is initialized to the empty string. In the case of\nthe \u0026apos;command\u0026apos; file this buffer is literally never used and simply wastes\nspace. In the case of the \u0026apos;netdev_ops\u0026apos; file, the last command written is\nsaved here.\n\nOn read, the files contents are presented as the name of the device\nfollowed by a colon and then the contents of their respective static\nbuffer. For \u0026apos;command\u0026apos; this will always be \u0026quot;\u0026lt;device\u0026gt;: \u0026quot;. For \u0026apos;netdev_ops\u0026apos;,\nthis will be \u0026quot;\u0026lt;device\u0026gt;: \u0026lt;last command written\u0026gt;\u0026quot;. But note the buffer is\nshared between all devices operated by this module. At best, it is mostly\nmeaningless information, and at worse it could be accessed simultaneously\nas there doesn\u0026apos;t appear to be any locking mechanism.\n\nWe have also recently received multiple reports for both read functions\nabout their use of snprintf and potential overflow that could result in\nreading arbitrary kernel memory. For the \u0026apos;command\u0026apos; file, this is definitely\nimpossible, since the static buffer is always zero and never written to.\nFor the \u0026apos;netdev_ops\u0026apos; file, it does appear to be possible, if the user\ncarefully crafts the command input, it will be copied into the buffer,\nwhich could be large enough to cause snprintf to truncate, which then\ncauses the copy_to_user to read beyond the length of the buffer allocated\nby kzalloc.\n\nA minimal fix would be to replace snprintf() with scnprintf() which would\ncap the return to the number of bytes written, preventing an overflow. A\nmore involved fix would be to drop the mostly useless static buffers,\nsaving 512 bytes and modifying the read functions to stop needing those as\ninput.\n\nInstead, lets just completely drop the read access to these files. These\nare debug interfaces exposed as part of debugfs, and I don\u0026apos;t believe that\ndropping read access will break any script, as the provided output is\npretty useless. You can find the netdev name through other more standard\ninterfaces, and the \u0026apos;netdev_ops\u0026apos; interface can easily result in garbage if\nyou issue simultaneous writes to multiple devices at once.\n\nIn order to properly remove the i40e_dbg_netdev_ops_buf, we need to\nrefactor its write function to avoid using the static buffer. Instead, use\nthe same logic as the i40e_dbg_command_write, with an allocated buffer.\nUpdate the code to use this instead of the static buffer, and ensure we\nfree the buffer on exit. This fixes simultaneous writes to \u0026apos;netdev_ops\u0026apos; on\nmultiple devices, and allows us to remove the now unused static buffer\nalong with removing the read access.(CVE-2025-39901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size\n\nThis is inspired by the check for data_offset + data_length.(CVE-2025-39942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/ksm: fix flag-dropping behavior in ksm_madvise\n\nsyzkaller discovered the following crash: (kernel BUG)\n\n[ 44.607039] ------------[ cut here ]------------\n[ 44.607422] kernel BUG at mm/userfaultfd.c:2067!\n[ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)\n[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460\n\n\u0026lt;snip other registers, drop unreliable trace\u0026gt;\n\n[ 44.617726] Call Trace:\n[ 44.617926] \u0026lt;TASK\u0026gt;\n[ 44.619284] userfaultfd_release+0xef/0x1b0\n[ 44.620976] __fput+0x3f9/0xb60\n[ 44.621240] fput_close_sync+0x110/0x210\n[ 44.622222] __x64_sys_close+0x8f/0x120\n[ 44.622530] do_syscall_64+0x5b/0x2f0\n[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 44.623244] RIP: 0033:0x7f365bb3f227\n\nKernel panics because it detects UFFD inconsistency during\nuserfaultfd_release_all(). Specifically, a VMA which has a valid pointer\nto vma-\u0026gt;vm_userfaultfd_ctx, but no UFFD flags in vma-\u0026gt;vm_flags.\n\nThe inconsistency is caused in ksm_madvise(): when user calls madvise()\nwith MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,\nit accidentally clears all flags stored in the upper 32 bits of\nvma-\u0026gt;vm_flags.\n\nAssuming x86_64 kernel build, unsigned long is 64-bit and unsigned int and\nint are 32-bit wide. This setup causes the following mishap during the \u0026amp;=\n~VM_MERGEABLE assignment.\n\nVM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000\u0026apos;0000. \nAfter ~ is applied, it becomes 0x7fff\u0026apos;ffff unsigned int, which is then\npromoted to unsigned long before the \u0026amp; operation. This promotion fills\nupper 32 bits with leading 0s, as we\u0026apos;re doing unsigned conversion (and\neven for a signed conversion, this wouldn\u0026apos;t help as the leading bit is 0).\n\u0026amp; operation thus ends up AND-ing vm_flags with 0x0000\u0026apos;0000\u0026apos;7fff\u0026apos;ffff\ninstead of intended 0xffff\u0026apos;ffff\u0026apos;7fff\u0026apos;ffff and hence accidentally clears\nthe upper 32-bits of its value.\n\nFix it by changing `VM_MERGEABLE` constant to unsigned long, using the\nBIT() macro.\n\nNote: other VM_* flags are not affected: This only happens to the\nVM_MERGEABLE flag, as the other VM_* flags are all constants of type int\nand after ~ operation, they end up with leading 1 and are thus converted\nto unsigned long with leading 1s.\n\nNote 2:\nAfter commit 31defc3b01d9 (\u0026quot;userfaultfd: remove (VM_)BUG_ON()s\u0026quot;), this is\nno longer a kernel BUG, but a WARNING at the same place:\n\n[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067\n\nbut the root-cause (flag-drop) remains the same.\n\n[(CVE-2025-40040)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: use dst_dev_rcu() in sk_setup_caps()\n\nUse RCU to protect accesses to dst-\u0026gt;dev from sk_setup_caps()\nand sk_dst_gso_max_size().\n\nAlso use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),\nand ip_dst_mtu_maybe_forward().\n\nip4_dst_hoplimit() can use dst_dev_net_rcu().(CVE-2025-40170)",
"id": "OESA-2025-2882",
"modified": "2026-08-06T11:10:00Z",
"published": "2025-12-30T11:10:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2882"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42154"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49878"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56599"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21905"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21922"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23158"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37756"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37775"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37776"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37850"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37927"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38560"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39942"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40040"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40170"
}
],
"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-2024-42154",
"CVE-2024-49878",
"CVE-2024-56599",
"CVE-2025-21905",
"CVE-2025-21922",
"CVE-2025-23158",
"CVE-2025-23160",
"CVE-2025-37756",
"CVE-2025-37775",
"CVE-2025-37776",
"CVE-2025-37850",
"CVE-2025-37927",
"CVE-2025-38560",
"CVE-2025-39901",
"CVE-2025-39942",
"CVE-2025-40040",
"CVE-2025-40170"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.