Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2025-37991 (GCVE-0-2025-37991)
Vulnerability from cvelistv5 – Published: 2025-05-20 17:18 – Updated: 2026-05-11 21:19| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6
(git)
Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 757ba4d17b868482837c566cfefca59e2296c608 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < ec4584495868bd465fe60a3f771915c0e7ce7951 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 6c639af49e9e5615a8395981eaf5943fb40acd6f (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < 6a098c51d18ec99485668da44294565c43dbc106 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < cf21e890f56b7d0038ddaf25224e4f4c69ecd143 (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < df3592e493d7f29bae4ffde9a9325de50ddf962e (git) Affected: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 , < de3629baf5a33af1919dec7136d643b0662e85ef (git) |
guessed | |
| Linux | Linux |
Affected:
2.6.12
Unaffected: 0 , < 2.6.12 (semver) Unaffected: 5.4.294 , ≤ 5.4.* (semver) Unaffected: 5.10.238 , ≤ 5.10.* (semver) Unaffected: 5.15.182 , ≤ 5.15.* (semver) Unaffected: 6.1.138 , ≤ 6.1.* (semver) Unaffected: 6.6.90 , ≤ 6.6.* (semver) Unaffected: 6.12.28 , ≤ 6.12.* (semver) Unaffected: 6.14.6 , ≤ 6.14.* (semver) Unaffected: 6.15 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T19:58:05.217Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/parisc/math-emu/driver.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "757ba4d17b868482837c566cfefca59e2296c608",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "ec4584495868bd465fe60a3f771915c0e7ce7951",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "6c639af49e9e5615a8395981eaf5943fb40acd6f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "6a098c51d18ec99485668da44294565c43dbc106",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "cf21e890f56b7d0038ddaf25224e4f4c69ecd143",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "df3592e493d7f29bae4ffde9a9325de50ddf962e",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "de3629baf5a33af1919dec7136d643b0662e85ef",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/parisc/math-emu/driver.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.12"
},
{
"lessThan": "2.6.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.294",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.238",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.182",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.138",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.90",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.28",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.294",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.238",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.182",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.138",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.90",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.28",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14.6",
"versionStartIncluding": "2.6.12",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.15",
"versionStartIncluding": "2.6.12",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler. Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0. The latter cancels all pending traps. Let\u0027s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n sigset_t set;\n sigemptyset(\u0026set);\n sigaddset(\u0026set, SIGFPE);\n sigprocmask(SIG_UNBLOCK, \u0026set, NULL);\n printf(\"GOT signal %d with si_code %ld\\n\", sig, i-\u003esi_code);\n}\n\nint main() {\n struct sigaction action = {\n .sa_sigaction = fpe_func,\n .sa_flags = SA_RESTART|SA_SIGINFO };\n sigaction(SIGFPE, \u0026action, 0);\n feenableexcept(FE_OVERFLOW);\n return printf(\"%lf\\n\",1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\"./a.out\", [\"./a.out\"], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception"
}
],
"providerMetadata": {
"dateUpdated": "2026-05-11T21:19:11.846Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6"
},
{
"url": "https://git.kernel.org/stable/c/757ba4d17b868482837c566cfefca59e2296c608"
},
{
"url": "https://git.kernel.org/stable/c/ec4584495868bd465fe60a3f771915c0e7ce7951"
},
{
"url": "https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f"
},
{
"url": "https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106"
},
{
"url": "https://git.kernel.org/stable/c/cf21e890f56b7d0038ddaf25224e4f4c69ecd143"
},
{
"url": "https://git.kernel.org/stable/c/df3592e493d7f29bae4ffde9a9325de50ddf962e"
},
{
"url": "https://git.kernel.org/stable/c/de3629baf5a33af1919dec7136d643b0662e85ef"
}
],
"title": "parisc: Fix double SIGFPE crash",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2025-37991",
"datePublished": "2025-05-20T17:18:45.988Z",
"dateReserved": "2025-04-16T04:51:23.976Z",
"dateUpdated": "2026-05-11T21:19:11.846Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2025-37991",
"date": "2026-09-17",
"epss": "0.00196",
"percentile": "0.09532"
},
"nvd": "{\"cve\":{\"id\":\"CVE-2025-37991\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2025-05-20T18:15:45.997\",\"lastModified\":\"2026-06-17T09:15:50.220\",\"vulnStatus\":\"Analyzed\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nparisc: Fix double SIGFPE crash\\n\\nCamm noticed that on parisc a SIGFPE exception will crash an application with\\na second SIGFPE in the signal handler. Dave analyzed it, and it happens\\nbecause glibc uses a double-word floating-point store to atomically update\\nfunction descriptors. As a result of lazy binding, we hit a floating-point\\nstore in fpe_func almost immediately.\\n\\nWhen the T bit is set, an assist exception trap occurs when when the\\nco-processor encounters *any* floating-point instruction except for a double\\nstore of register %fr0. The latter cancels all pending traps. Let\u0027s fix this\\nby clearing the Trap (T) bit in the FP status register before returning to the\\nsignal handler in userspace.\\n\\nThe issue can be reproduced with this test program:\\n\\nroot@parisc:~# cat fpe.c\\n\\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\\n sigset_t set;\\n sigemptyset(\u0026set);\\n sigaddset(\u0026set, SIGFPE);\\n sigprocmask(SIG_UNBLOCK, \u0026set, NULL);\\n printf(\\\"GOT signal %d with si_code %ld\\\\n\\\", sig, i-\u003esi_code);\\n}\\n\\nint main() {\\n struct sigaction action = {\\n .sa_sigaction = fpe_func,\\n .sa_flags = SA_RESTART|SA_SIGINFO };\\n sigaction(SIGFPE, \u0026action, 0);\\n feenableexcept(FE_OVERFLOW);\\n return printf(\\\"%lf\\\\n\\\",1.7976931348623158E308*1.7976931348623158E308);\\n}\\n\\nroot@parisc:~# gcc fpe.c -lm\\nroot@parisc:~# ./a.out\\n Floating point exception\\n\\nroot@parisc:~# strace -f ./a.out\\n execve(\\\"./a.out\\\", [\\\"./a.out\\\"], 0xf9ac7034 /* 20 vars */) = 0\\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\\n ...\\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\\n +++ killed by SIGFPE +++\\n Floating point exception\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: Se corrige el doble fallo de SIGFPE Camm not\u00f3 que en parisc una excepci\u00f3n SIGFPE bloquear\u00e1 una aplicaci\u00f3n con un segundo SIGFPE en el manejador de se\u00f1ales. Dave lo analiz\u00f3 y sucede porque glibc usa un almac\u00e9n de punto flotante de doble palabra para actualizar at\u00f3micamente los descriptores de funci\u00f3n. Como resultado del enlace diferido, llegamos a un almac\u00e9n de punto flotante en fpe_func casi inmediatamente. Cuando se establece el bit T, se produce una trampa de excepci\u00f3n de asistencia cuando el coprocesador encuentra *cualquier* instrucci\u00f3n de punto flotante excepto un almac\u00e9n doble del registro %fr0. Este \u00faltimo cancela todas las trampas pendientes. Arreglemos esto borrando el bit Trap (T) en el registro de estado FP antes de regresar al manejador de se\u00f1ales en el espacio de usuario. El problema se puede reproducir con este programa de prueba: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(\u0026amp;set); sigaddset(\u0026amp;set, SIGFPE); sigprocmask(SIG_UNBLOCK, \u0026amp;set, NULL); printf(\\\"Se\u00f1al GOT %d con c\u00f3digo si %ld\\\\n\\\", sig, i-\u0026gt;c\u00f3digo si); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, \u0026amp;action, 0); feenableexcept(FE_OVERFLOW); return printf(\\\"%lf\\\\n\\\",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Excepci\u00f3n de punto flotante root@parisc:~# strace -f ./a.out execve(\\\"./a.out\\\", [\\\"./a.out\\\"], 0xf9ac7034 /* 20 variables */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ eliminado por SIGFPE +++ Excepci\u00f3n de punto flotante\"}],\"affected\":[{\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"affectedData\":[{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"unaffected\",\"programFiles\":[\"arch/parisc/math-emu/driver.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\",\"lessThan\":\"2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\",\"lessThan\":\"757ba4d17b868482837c566cfefca59e2296c608\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\",\"lessThan\":\"ec4584495868bd465fe60a3f771915c0e7ce7951\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\",\"lessThan\":\"6c639af49e9e5615a8395981eaf5943fb40acd6f\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\",\"lessThan\":\"6a098c51d18ec99485668da44294565c43dbc106\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\",\"lessThan\":\"cf21e890f56b7d0038ddaf25224e4f4c69ecd143\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\",\"lessThan\":\"df3592e493d7f29bae4ffde9a9325de50ddf962e\",\"versionType\":\"git\",\"status\":\"affected\"},{\"version\":\"1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\",\"lessThan\":\"de3629baf5a33af1919dec7136d643b0662e85ef\",\"versionType\":\"git\",\"status\":\"affected\"}]},{\"vendor\":\"Linux\",\"product\":\"Linux\",\"defaultStatus\":\"affected\",\"programFiles\":[\"arch/parisc/math-emu/driver.c\"],\"repo\":\"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\",\"versions\":[{\"version\":\"2.6.12\",\"status\":\"affected\"},{\"version\":\"0\",\"lessThan\":\"2.6.12\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.4.294\",\"lessThanOrEqual\":\"5.4.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.10.238\",\"lessThanOrEqual\":\"5.10.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"5.15.182\",\"lessThanOrEqual\":\"5.15.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.1.138\",\"lessThanOrEqual\":\"6.1.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.6.90\",\"lessThanOrEqual\":\"6.6.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.12.28\",\"lessThanOrEqual\":\"6.12.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.14.6\",\"lessThanOrEqual\":\"6.14.*\",\"versionType\":\"semver\",\"status\":\"unaffected\"},{\"version\":\"6.15\",\"lessThanOrEqual\":\"*\",\"versionType\":\"original_commit_for_fix\",\"status\":\"unaffected\"}]}]}],\"metrics\":{\"cvssMetricV31\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"cvssData\":{\"version\":\"3.1\",\"vectorString\":\"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\",\"baseScore\":7.8,\"baseSeverity\":\"HIGH\",\"attackVector\":\"LOCAL\",\"attackComplexity\":\"LOW\",\"privilegesRequired\":\"LOW\",\"userInteraction\":\"NONE\",\"scope\":\"UNCHANGED\",\"confidentialityImpact\":\"HIGH\",\"integrityImpact\":\"HIGH\",\"availabilityImpact\":\"HIGH\"},\"exploitabilityScore\":1.8,\"impactScore\":5.9}]},\"weaknesses\":[{\"source\":\"nvd@nist.gov\",\"type\":\"Primary\",\"description\":[{\"lang\":\"en\",\"value\":\"CWE-415\"}]}],\"configurations\":[{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionEndExcluding\":\"5.4.294\",\"matchCriteriaId\":\"093AFCC1-07FE-4A32-A1F0-9B1F9197071E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.5\",\"versionEndExcluding\":\"5.10.238\",\"matchCriteriaId\":\"0DAAEF7F-D560-47FC-8B65-20404DB82432\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.11\",\"versionEndExcluding\":\"5.15.182\",\"matchCriteriaId\":\"57E76AE8-79D9-4EC8-9845-9A86B1ED152E\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"5.16\",\"versionEndExcluding\":\"6.1.138\",\"matchCriteriaId\":\"B6266F82-46B4-4D38-AC4A-54C92A1DFAB2\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.2\",\"versionEndExcluding\":\"6.6.90\",\"matchCriteriaId\":\"2BE1DB09-2D62-4C63-AF19-947300669741\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.7\",\"versionEndExcluding\":\"6.12.28\",\"matchCriteriaId\":\"5082CE19-0F3D-4521-AB3E-810D8255F500\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\",\"versionStartIncluding\":\"6.13\",\"versionEndExcluding\":\"6.14.6\",\"matchCriteriaId\":\"19E5095E-5950-43EA-8E78-FC860855293F\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*\",\"matchCriteriaId\":\"8D465631-2980-487A-8E65-40AE2B9F8ED1\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:*\",\"matchCriteriaId\":\"4C9D071F-B28E-46EC-AC61-22B913390211\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.15:rc3:*:*:*:*:*:*\",\"matchCriteriaId\":\"13FC0DDE-E513-465E-9E81-515702D49B74\"},{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:linux:linux_kernel:6.15:rc4:*:*:*:*:*:*\",\"matchCriteriaId\":\"8C7B5B0E-4EEB-48F5-B4CF-0935A7633845\"}]}]},{\"nodes\":[{\"operator\":\"OR\",\"negate\":false,\"cpeMatch\":[{\"vulnerable\":true,\"criteria\":\"cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*\",\"matchCriteriaId\":\"FA6FEEC2-9F11-4643-8827-749718254FED\"}]}]}],\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/757ba4d17b868482837c566cfefca59e2296c608\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/cf21e890f56b7d0038ddaf25224e4f4c69ecd143\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/de3629baf5a33af1919dec7136d643b0662e85ef\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/df3592e493d7f29bae4ffde9a9325de50ddf962e\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://git.kernel.org/stable/c/ec4584495868bd465fe60a3f771915c0e7ce7951\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"tags\":[\"Patch\"]},{\"url\":\"https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html\",\"source\":\"af854a3a-2127-422b-91ae-364da2661108\",\"tags\":[\"Third Party Advisory\"]}]}}",
"redhat_vex": {
"aggregate_severity": "None",
"current_release_date": "2026-06-30T10:17:34+00:00",
"cve": "CVE-2025-37991",
"id": "CVE-2025-37991",
"initial_release_date": "2025-05-20T00:00:00+00:00",
"product_status:known_not_affected": "274",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: parisc: Fix double SIGFPE crash",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2025/cve-2025-37991.json",
"version": "3"
}
}
}
CERTFR-2026-AVI-0194
Vulnerability from certfr_avis - Published: 2026-02-20 - Updated: 2026-02-20
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).
None{
"$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 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.10",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": null,
"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-40296",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40296"
},
{
"name": "CVE-2025-40225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40225"
},
{
"name": "CVE-2025-40166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40166"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2025-40064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40064"
},
{
"name": "CVE-2025-38490",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38490"
},
{
"name": "CVE-2025-37850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37850"
},
{
"name": "CVE-2025-38485",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38485"
},
{
"name": "CVE-2025-22026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22026"
},
{
"name": "CVE-2025-39987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39987"
},
{
"name": "CVE-2025-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38579"
},
{
"name": "CVE-2025-68196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68196"
},
{
"name": "CVE-2025-37761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37761"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-37865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37865"
},
{
"name": "CVE-2025-38328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38328"
},
{
"name": "CVE-2025-40156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40156"
},
{
"name": "CVE-2025-38711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38711"
},
{
"name": "CVE-2025-38487",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38487"
},
{
"name": "CVE-2025-40137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40137"
},
{
"name": "CVE-2025-37775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37775"
},
{
"name": "CVE-2025-38335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38335"
},
{
"name": "CVE-2025-38304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38304"
},
{
"name": "CVE-2025-37892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37892"
},
{
"name": "CVE-2025-38100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38100"
},
{
"name": "CVE-2025-37859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37859"
},
{
"name": "CVE-2025-40002",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40002"
},
{
"name": "CVE-2025-40057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40057"
},
{
"name": "CVE-2025-38043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38043"
},
{
"name": "CVE-2025-38471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38471"
},
{
"name": "CVE-2025-38520",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38520"
},
{
"name": "CVE-2025-37792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37792"
},
{
"name": "CVE-2025-68240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68240"
},
{
"name": "CVE-2025-38108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38108"
},
{
"name": "CVE-2025-38230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38230"
},
{
"name": "CVE-2025-38229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38229"
},
{
"name": "CVE-2025-40055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40055"
},
{
"name": "CVE-2025-38158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38158"
},
{
"name": "CVE-2025-40151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40151"
},
{
"name": "CVE-2025-37872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37872"
},
{
"name": "CVE-2025-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38588"
},
{
"name": "CVE-2025-39876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39876"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-40037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40037"
},
{
"name": "CVE-2025-38279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38279"
},
{
"name": "CVE-2025-38561",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38561"
},
{
"name": "CVE-2025-38574",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38574"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-68210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68210"
},
{
"name": "CVE-2025-40239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40239"
},
{
"name": "CVE-2025-40147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40147"
},
{
"name": "CVE-2025-40048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40048"
},
{
"name": "CVE-2025-38147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38147"
},
{
"name": "CVE-2025-23155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23155"
},
{
"name": "CVE-2025-38286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38286"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-39757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39757"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2025-38501",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38501"
},
{
"name": "CVE-2025-38474",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38474"
},
{
"name": "CVE-2025-37979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37979"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-37777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37777"
},
{
"name": "CVE-2025-39772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39772"
},
{
"name": "CVE-2025-68199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68199"
},
{
"name": "CVE-2025-37936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37936"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2025-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38601"
},
{
"name": "CVE-2025-37766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37766"
},
{
"name": "CVE-2025-38104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38104"
},
{
"name": "CVE-2025-37844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37844"
},
{
"name": "CVE-2025-21931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21931"
},
{
"name": "CVE-2025-37871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37871"
},
{
"name": "CVE-2025-37778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37778"
},
{
"name": "CVE-2025-39716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39716"
},
{
"name": "CVE-2025-39702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39702"
},
{
"name": "CVE-2025-39973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39973"
},
{
"name": "CVE-2025-38515",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38515"
},
{
"name": "CVE-2025-38645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38645"
},
{
"name": "CVE-2025-38163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38163"
},
{
"name": "CVE-2025-22126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22126"
},
{
"name": "CVE-2025-38444",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38444"
},
{
"name": "CVE-2025-38109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38109"
},
{
"name": "CVE-2025-39779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39779"
},
{
"name": "CVE-2025-37755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37755"
},
{
"name": "CVE-2025-39685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39685"
},
{
"name": "CVE-2025-38660",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38660"
},
{
"name": "CVE-2025-39761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39761"
},
{
"name": "CVE-2025-68246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68246"
},
{
"name": "CVE-2025-40287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40287"
},
{
"name": "CVE-2025-39943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39943"
},
{
"name": "CVE-2025-39945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39945"
},
{
"name": "CVE-2025-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39883"
},
{
"name": "CVE-2025-39720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39720"
},
{
"name": "CVE-2025-38624",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38624"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2025-40285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40285"
},
{
"name": "CVE-2025-38388",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38388"
},
{
"name": "CVE-2025-38157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38157"
},
{
"name": "CVE-2025-40063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40063"
},
{
"name": "CVE-2025-37790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37790"
},
{
"name": "CVE-2025-40208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40208"
},
{
"name": "CVE-2025-39746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39746"
},
{
"name": "CVE-2025-38323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38323"
},
{
"name": "CVE-2025-40019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40019"
},
{
"name": "CVE-2025-40039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40039"
},
{
"name": "CVE-2025-38208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38208"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-38219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38219"
},
{
"name": "CVE-2025-39889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39889"
},
{
"name": "CVE-2025-38099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38099"
},
{
"name": "CVE-2025-38524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38524"
},
{
"name": "CVE-2025-38466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38466"
},
{
"name": "CVE-2025-40117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40117"
},
{
"name": "CVE-2025-37758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37758"
},
{
"name": "CVE-2025-40081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40081"
},
{
"name": "CVE-2025-38087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38087"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2025-38039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38039"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40153"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2025-40294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40294"
},
{
"name": "CVE-2025-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38595"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2025-40356",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40356"
},
{
"name": "CVE-2025-40121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40121"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-40204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40204"
},
{
"name": "CVE-2025-37852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37852"
},
{
"name": "CVE-2025-37841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37841"
},
{
"name": "CVE-2025-40171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40171"
},
{
"name": "CVE-2025-37918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37918"
},
{
"name": "CVE-2025-37917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37917"
},
{
"name": "CVE-2025-38290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38290"
},
{
"name": "CVE-2025-68243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68243"
},
{
"name": "CVE-2025-38063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38063"
},
{
"name": "CVE-2025-37770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37770"
},
{
"name": "CVE-2025-37773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37773"
},
{
"name": "CVE-2025-68175",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68175"
},
{
"name": "CVE-2025-40221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40221"
},
{
"name": "CVE-2025-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38578"
},
{
"name": "CVE-2025-40139",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40139"
},
{
"name": "CVE-2025-40056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40056"
},
{
"name": "CVE-2025-38675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38675"
},
{
"name": "CVE-2025-39911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39911"
},
{
"name": "CVE-2025-38646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38646"
},
{
"name": "CVE-2025-38491",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38491"
},
{
"name": "CVE-2025-38708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38708"
},
{
"name": "CVE-2025-37961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37961"
},
{
"name": "CVE-2025-68248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68248"
},
{
"name": "CVE-2025-40125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40125"
},
{
"name": "CVE-2025-40350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40350"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2025-38313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38313"
},
{
"name": "CVE-2025-38336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38336"
},
{
"name": "CVE-2025-40349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40349"
},
{
"name": "CVE-2025-40052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40052"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2025-38644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38644"
},
{
"name": "CVE-2025-38692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38692"
},
{
"name": "CVE-2025-38061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38061"
},
{
"name": "CVE-2025-68173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68173"
},
{
"name": "CVE-2025-37983",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37983"
},
{
"name": "CVE-2025-38127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38127"
},
{
"name": "CVE-2025-38375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38375"
},
{
"name": "CVE-2025-37784",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37784"
},
{
"name": "CVE-2025-39701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39701"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2025-40187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40187"
},
{
"name": "CVE-2025-37920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37920"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2025-37815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37815"
},
{
"name": "CVE-2025-38686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38686"
},
{
"name": "CVE-2025-37819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37819"
},
{
"name": "CVE-2025-39913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39913"
},
{
"name": "CVE-2025-40092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40092"
},
{
"name": "CVE-2025-40298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40298"
},
{
"name": "CVE-2025-40355",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40355"
},
{
"name": "CVE-2025-38609",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38609"
},
{
"name": "CVE-2025-68186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68186"
},
{
"name": "CVE-2025-39967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39967"
},
{
"name": "CVE-2025-40054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40054"
},
{
"name": "CVE-2025-68184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68184"
},
{
"name": "CVE-2024-36357",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36357"
},
{
"name": "CVE-2025-38463",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38463"
},
{
"name": "CVE-2025-40115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40115"
},
{
"name": "CVE-2025-38112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38112"
},
{
"name": "CVE-2025-38521",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38521"
},
{
"name": "CVE-2025-38023",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38023"
},
{
"name": "CVE-2025-39709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39709"
},
{
"name": "CVE-2025-38282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38282"
},
{
"name": "CVE-2025-39689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39689"
},
{
"name": "CVE-2025-38215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38215"
},
{
"name": "CVE-2025-39787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39787"
},
{
"name": "CVE-2025-37943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37943"
},
{
"name": "CVE-2025-37745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37745"
},
{
"name": "CVE-2025-40058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40058"
},
{
"name": "CVE-2025-39731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39731"
},
{
"name": "CVE-2025-38734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38734"
},
{
"name": "CVE-2025-38653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38653"
},
{
"name": "CVE-2025-38571",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38571"
},
{
"name": "CVE-2025-37789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37789"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-38695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38695"
},
{
"name": "CVE-2025-38004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38004"
},
{
"name": "CVE-2025-39749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39749"
},
{
"name": "CVE-2025-40198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40198"
},
{
"name": "CVE-2025-68310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68310"
},
{
"name": "CVE-2025-68179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68179"
},
{
"name": "CVE-2025-40145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40145"
},
{
"name": "CVE-2025-39949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39949"
},
{
"name": "CVE-2025-38387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38387"
},
{
"name": "CVE-2025-68169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68169"
},
{
"name": "CVE-2025-38362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38362"
},
{
"name": "CVE-2025-40173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40173"
},
{
"name": "CVE-2025-68316",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68316"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2025-37924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37924"
},
{
"name": "CVE-2025-40004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40004"
},
{
"name": "CVE-2025-38371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38371"
},
{
"name": "CVE-2024-56538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56538"
},
{
"name": "CVE-2025-39923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39923"
},
{
"name": "CVE-2025-38445",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38445"
},
{
"name": "CVE-2025-38456",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38456"
},
{
"name": "CVE-2025-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38538"
},
{
"name": "CVE-2025-37867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37867"
},
{
"name": "CVE-2025-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23160"
},
{
"name": "CVE-2025-40311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40311"
},
{
"name": "CVE-2025-38295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38295"
},
{
"name": "CVE-2025-38461",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38461"
},
{
"name": "CVE-2025-37857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37857"
},
{
"name": "CVE-2025-37842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37842"
},
{
"name": "CVE-2025-40237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40237"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2025-39681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39681"
},
{
"name": "CVE-2025-38060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38060"
},
{
"name": "CVE-2025-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40167"
},
{
"name": "CVE-2025-38159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38159"
},
{
"name": "CVE-2025-38066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38066"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2025-39969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39969"
},
{
"name": "CVE-2025-37744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37744"
},
{
"name": "CVE-2025-38705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38705"
},
{
"name": "CVE-2025-40194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40194"
},
{
"name": "CVE-2025-38706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38706"
},
{
"name": "CVE-2025-40333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40333"
},
{
"name": "CVE-2025-38305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38305"
},
{
"name": "CVE-2025-37884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37884"
},
{
"name": "CVE-2025-38067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38067"
},
{
"name": "CVE-2025-39750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39750"
},
{
"name": "CVE-2025-38699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38699"
},
{
"name": "CVE-2025-37927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37927"
},
{
"name": "CVE-2025-38707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38707"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2025-37897",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37897"
},
{
"name": "CVE-2025-40256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40256"
},
{
"name": "CVE-2025-37911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37911"
},
{
"name": "CVE-2025-40245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40245"
},
{
"name": "CVE-2025-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38587"
},
{
"name": "CVE-2025-37869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37869"
},
{
"name": "CVE-2025-39692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39692"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2025-40332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40332"
},
{
"name": "CVE-2025-40082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40082"
},
{
"name": "CVE-2025-38068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38068"
},
{
"name": "CVE-2025-38436",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38436"
},
{
"name": "CVE-2025-37930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37930"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2025-38401",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38401"
},
{
"name": "CVE-2025-38677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38677"
},
{
"name": "CVE-2025-38097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38097"
},
{
"name": "CVE-2025-37810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37810"
},
{
"name": "CVE-2025-38253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38253"
},
{
"name": "CVE-2025-40097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40097"
},
{
"name": "CVE-2025-38123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38123"
},
{
"name": "CVE-2025-38338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38338"
},
{
"name": "CVE-2025-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38555"
},
{
"name": "CVE-2025-38239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38239"
},
{
"name": "CVE-2025-40001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40001"
},
{
"name": "CVE-2025-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38590"
},
{
"name": "CVE-2025-38027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38027"
},
{
"name": "CVE-2025-38102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38102"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-68187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68187"
},
{
"name": "CVE-2025-38283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38283"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2025-68209",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68209"
},
{
"name": "CVE-2025-40045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40045"
},
{
"name": "CVE-2025-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23159"
},
{
"name": "CVE-2025-39988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39988"
},
{
"name": "CVE-2025-38455",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38455"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2025-40089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40089"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2025-38015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38015"
},
{
"name": "CVE-2025-39675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39675"
},
{
"name": "CVE-2025-39679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39679"
},
{
"name": "CVE-2025-38527",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38527"
},
{
"name": "CVE-2025-38449",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38449"
},
{
"name": "CVE-2025-40233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40233"
},
{
"name": "CVE-2025-40172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40172"
},
{
"name": "CVE-2025-37853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37853"
},
{
"name": "CVE-2025-38126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38126"
},
{
"name": "CVE-2025-38149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38149"
},
{
"name": "CVE-2025-39763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39763"
},
{
"name": "CVE-2025-38399",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38399"
},
{
"name": "CVE-2025-40020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40020"
},
{
"name": "CVE-2025-38065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38065"
},
{
"name": "CVE-2025-38693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38693"
},
{
"name": "CVE-2025-38679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38679"
},
{
"name": "CVE-2025-38459",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38459"
},
{
"name": "CVE-2025-40188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40188"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2025-40291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40291"
},
{
"name": "CVE-2025-38685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38685"
},
{
"name": "CVE-2025-40359",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40359"
},
{
"name": "CVE-2025-38412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38412"
},
{
"name": "CVE-2025-38031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38031"
},
{
"name": "CVE-2025-40186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40186"
},
{
"name": "CVE-2025-38293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38293"
},
{
"name": "CVE-2025-40073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40073"
},
{
"name": "CVE-2025-38648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38648"
},
{
"name": "CVE-2025-38278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38278"
},
{
"name": "CVE-2025-37764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37764"
},
{
"name": "CVE-2025-38184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38184"
},
{
"name": "CVE-2025-37741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37741"
},
{
"name": "CVE-2025-38053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38053"
},
{
"name": "CVE-2025-40242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40242"
},
{
"name": "CVE-2025-37822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37822"
},
{
"name": "CVE-2025-37912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37912"
},
{
"name": "CVE-2025-38482",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38482"
},
{
"name": "CVE-2025-37820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37820"
},
{
"name": "CVE-2025-68198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68198"
},
{
"name": "CVE-2025-37985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37985"
},
{
"name": "CVE-2025-68314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68314"
},
{
"name": "CVE-2025-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38634"
},
{
"name": "CVE-2025-40212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40212"
},
{
"name": "CVE-2025-37787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37787"
},
{
"name": "CVE-2025-38008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38008"
},
{
"name": "CVE-2025-38458",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38458"
},
{
"name": "CVE-2025-39730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39730"
},
{
"name": "CVE-2025-38011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38011"
},
{
"name": "CVE-2025-68190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68190"
},
{
"name": "CVE-2025-38034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38034"
},
{
"name": "CVE-2025-40086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40086"
},
{
"name": "CVE-2025-68242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68242"
},
{
"name": "CVE-2025-38135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38135"
},
{
"name": "CVE-2025-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38619"
},
{
"name": "CVE-2025-40169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40169"
},
{
"name": "CVE-2025-38312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38312"
},
{
"name": "CVE-2025-38095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38095"
},
{
"name": "CVE-2025-37878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37878"
},
{
"name": "CVE-2025-39737",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39737"
},
{
"name": "CVE-2025-38464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38464"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2025-68322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68322"
},
{
"name": "CVE-2025-38363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38363"
},
{
"name": "CVE-2025-38702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38702"
},
{
"name": "CVE-2025-38319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38319"
},
{
"name": "CVE-2022-49698",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49698"
},
{
"name": "CVE-2025-40238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40238"
},
{
"name": "CVE-2025-38724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38724"
},
{
"name": "CVE-2025-68205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68205"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2025-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38457"
},
{
"name": "CVE-2025-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38582"
},
{
"name": "CVE-2025-37813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37813"
},
{
"name": "CVE-2025-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38543"
},
{
"name": "CVE-2025-38698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38698"
},
{
"name": "CVE-2025-38212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38212"
},
{
"name": "CVE-2025-40106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40106"
},
{
"name": "CVE-2025-68174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68174"
},
{
"name": "CVE-2025-38298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38298"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2025-39739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39739"
},
{
"name": "CVE-2025-38024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38024"
},
{
"name": "CVE-2025-40047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40047"
},
{
"name": "CVE-2025-38496",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38496"
},
{
"name": "CVE-2025-38078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38078"
},
{
"name": "CVE-2025-38419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38419"
},
{
"name": "CVE-2025-40136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40136"
},
{
"name": "CVE-2025-38533",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38533"
},
{
"name": "CVE-2025-40344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40344"
},
{
"name": "CVE-2025-40205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40205"
},
{
"name": "CVE-2025-40354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40354"
},
{
"name": "CVE-2025-38169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38169"
},
{
"name": "CVE-2025-37931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37931"
},
{
"name": "CVE-2025-38511",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38511"
},
{
"name": "CVE-2025-38537",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38537"
},
{
"name": "CVE-2025-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38546"
},
{
"name": "CVE-2025-38211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38211"
},
{
"name": "CVE-2025-40033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40033"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-40122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40122"
},
{
"name": "CVE-2025-68188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68188"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2025-37887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37887"
},
{
"name": "CVE-2025-38077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38077"
},
{
"name": "CVE-2025-38251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38251"
},
{
"name": "CVE-2025-37861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37861"
},
{
"name": "CVE-2025-68319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68319"
},
{
"name": "CVE-2025-40119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40119"
},
{
"name": "CVE-2025-38120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38120"
},
{
"name": "CVE-2025-38285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38285"
},
{
"name": "CVE-2025-39743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39743"
},
{
"name": "CVE-2025-39718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39718"
},
{
"name": "CVE-2025-37938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37938"
},
{
"name": "CVE-2025-38005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38005"
},
{
"name": "CVE-2025-38368",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38368"
},
{
"name": "CVE-2025-40075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40075"
},
{
"name": "CVE-2025-38161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38161"
},
{
"name": "CVE-2025-38331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38331"
},
{
"name": "CVE-2025-38354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38354"
},
{
"name": "CVE-2025-40138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40138"
},
{
"name": "CVE-2025-38712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38712"
},
{
"name": "CVE-2025-38732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38732"
},
{
"name": "CVE-2025-39773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39773"
},
{
"name": "CVE-2025-38696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38696"
},
{
"name": "CVE-2025-40143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40143"
},
{
"name": "CVE-2025-68189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68189"
},
{
"name": "CVE-2025-38274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38274"
},
{
"name": "CVE-2025-40076",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40076"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-39885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39885"
},
{
"name": "CVE-2025-68180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68180"
},
{
"name": "CVE-2025-37874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37874"
},
{
"name": "CVE-2025-38115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38115"
},
{
"name": "CVE-2025-38632",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38632"
},
{
"name": "CVE-2025-37988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37988"
},
{
"name": "CVE-2025-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23158"
},
{
"name": "CVE-2025-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23144"
},
{
"name": "CVE-2025-38153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38153"
},
{
"name": "CVE-2025-37969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37969"
},
{
"name": "CVE-2025-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38548"
},
{
"name": "CVE-2025-37816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37816"
},
{
"name": "CVE-2025-40362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40362"
},
{
"name": "CVE-2025-37742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37742"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2025-40289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40289"
},
{
"name": "CVE-2025-37765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37765"
},
{
"name": "CVE-2025-38395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38395"
},
{
"name": "CVE-2025-37921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37921"
},
{
"name": "CVE-2025-38507",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38507"
},
{
"name": "CVE-2025-40230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40230"
},
{
"name": "CVE-2025-39989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39989"
},
{
"name": "CVE-2025-38337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38337"
},
{
"name": "CVE-2025-38014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38014"
},
{
"name": "CVE-2025-38258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38258"
},
{
"name": "CVE-2025-37828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37828"
},
{
"name": "CVE-2025-37769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37769"
},
{
"name": "CVE-2025-38465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38465"
},
{
"name": "CVE-2025-38513",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38513"
},
{
"name": "CVE-2025-39970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39970"
},
{
"name": "CVE-2025-40292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40292"
},
{
"name": "CVE-2025-38086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38086"
},
{
"name": "CVE-2025-68181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68181"
},
{
"name": "CVE-2025-37935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37935"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2025-38396",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38396"
},
{
"name": "CVE-2025-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23161"
},
{
"name": "CVE-2025-38407",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38407"
},
{
"name": "CVE-2025-39994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39994"
},
{
"name": "CVE-2025-38493",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38493"
},
{
"name": "CVE-2025-37803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37803"
},
{
"name": "CVE-2025-40228",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40228"
},
{
"name": "CVE-2025-40150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40150"
},
{
"name": "CVE-2025-38670",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38670"
},
{
"name": "CVE-2025-39732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39732"
},
{
"name": "CVE-2025-37824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37824"
},
{
"name": "CVE-2025-40274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40274"
},
{
"name": "CVE-2025-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38602"
},
{
"name": "CVE-2025-38003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38003"
},
{
"name": "CVE-2025-38441",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38441"
},
{
"name": "CVE-2025-40206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40206"
},
{
"name": "CVE-2025-40218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40218"
},
{
"name": "CVE-2025-38007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38007"
},
{
"name": "CVE-2025-37923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37923"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40220"
},
{
"name": "CVE-2025-38142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38142"
},
{
"name": "CVE-2025-37739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37739"
},
{
"name": "CVE-2025-38478",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38478"
},
{
"name": "CVE-2025-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38568"
},
{
"name": "CVE-2025-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38583"
},
{
"name": "CVE-2025-39788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39788"
},
{
"name": "CVE-2025-22058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22058"
},
{
"name": "CVE-2025-37831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37831"
},
{
"name": "CVE-2025-38499",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38499"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-40062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40062"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2025-38269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38269"
},
{
"name": "CVE-2025-38079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38079"
},
{
"name": "CVE-2025-37940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37940"
},
{
"name": "CVE-2025-40336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40336"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2025-40067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40067"
},
{
"name": "CVE-2025-40109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40109"
},
{
"name": "CVE-2025-40101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40101"
},
{
"name": "CVE-2025-38735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38735"
},
{
"name": "CVE-2025-40006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40006"
},
{
"name": "CVE-2025-68251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68251"
},
{
"name": "CVE-2025-38652",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38652"
},
{
"name": "CVE-2025-38110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38110"
},
{
"name": "CVE-2025-38422",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38422"
},
{
"name": "CVE-2025-38402",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38402"
},
{
"name": "CVE-2025-39698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39698"
},
{
"name": "CVE-2025-40038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40038"
},
{
"name": "CVE-2025-37915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37915"
},
{
"name": "CVE-2025-68183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68183"
},
{
"name": "CVE-2025-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23146"
},
{
"name": "CVE-2025-37903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37903"
},
{
"name": "CVE-2025-40353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40353"
},
{
"name": "CVE-2025-40222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40222"
},
{
"name": "CVE-2025-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23142"
},
{
"name": "CVE-2025-37738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37738"
},
{
"name": "CVE-2025-40011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40011"
},
{
"name": "CVE-2025-38303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38303"
},
{
"name": "CVE-2025-38074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38074"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-38119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38119"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-38245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38245"
},
{
"name": "CVE-2025-40184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40184"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-40231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40231"
},
{
"name": "CVE-2025-38324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38324"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2025-38018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38018"
},
{
"name": "CVE-2025-40176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40176"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2025-37830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37830"
},
{
"name": "CVE-2025-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38614"
},
{
"name": "CVE-2025-37991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37991"
},
{
"name": "CVE-2025-38425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38425"
},
{
"name": "CVE-2025-40210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40210"
},
{
"name": "CVE-2025-37978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37978"
},
{
"name": "CVE-2025-37781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37781"
},
{
"name": "CVE-2025-38210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38210"
},
{
"name": "CVE-2025-38542",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38542"
},
{
"name": "CVE-2025-38664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38664"
},
{
"name": "CVE-2025-38344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38344"
},
{
"name": "CVE-2025-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23145"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2025-38322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38322"
},
{
"name": "CVE-2025-38088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38088"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2025-40193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40193"
},
{
"name": "CVE-2025-37823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37823"
},
{
"name": "CVE-2025-38332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38332"
},
{
"name": "CVE-2025-40148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40148"
},
{
"name": "CVE-2025-40326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40326"
},
{
"name": "CVE-2025-38386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38386"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2025-38385",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38385"
},
{
"name": "CVE-2025-40201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40201"
},
{
"name": "CVE-2025-37952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37952"
},
{
"name": "CVE-2025-38694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38694"
},
{
"name": "CVE-2025-37793",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37793"
},
{
"name": "CVE-2025-40084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40084"
},
{
"name": "CVE-2025-68311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68311"
},
{
"name": "CVE-2025-37740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37740"
},
{
"name": "CVE-2025-38676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38676"
},
{
"name": "CVE-2025-38530",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38530"
},
{
"name": "CVE-2025-38174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38174"
},
{
"name": "CVE-2025-37826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37826"
},
{
"name": "CVE-2025-37986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37986"
},
{
"name": "CVE-2025-37829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37829"
},
{
"name": "CVE-2025-68320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68320"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2025-38409",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38409"
},
{
"name": "CVE-2025-40199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40199"
},
{
"name": "CVE-2025-40183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40183"
},
{
"name": "CVE-2025-38019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38019"
},
{
"name": "CVE-2025-38729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38729"
},
{
"name": "CVE-2025-68172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68172"
},
{
"name": "CVE-2025-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23151"
},
{
"name": "CVE-2025-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38037"
},
{
"name": "CVE-2025-39998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39998"
},
{
"name": "CVE-2025-40338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40338"
},
{
"name": "CVE-2025-40195",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40195"
},
{
"name": "CVE-2025-37796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37796"
},
{
"name": "CVE-2025-37962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37962"
},
{
"name": "CVE-2025-40134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40134"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2025-37799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37799"
},
{
"name": "CVE-2025-38593",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38593"
},
{
"name": "CVE-2025-39968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39968"
},
{
"name": "CVE-2025-38342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38342"
},
{
"name": "CVE-2025-39795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39795"
},
{
"name": "CVE-2025-37801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37801"
},
{
"name": "CVE-2025-38167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38167"
},
{
"name": "CVE-2025-37883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37883"
},
{
"name": "CVE-2025-40302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40302"
},
{
"name": "CVE-2025-37863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37863"
},
{
"name": "CVE-2025-37901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37901"
},
{
"name": "CVE-2025-38687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38687"
},
{
"name": "CVE-2025-40358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40358"
},
{
"name": "CVE-2025-37811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37811"
},
{
"name": "CVE-2025-40165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40165"
},
{
"name": "CVE-2025-38257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38257"
},
{
"name": "CVE-2025-68318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68318"
},
{
"name": "CVE-2025-37864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37864"
},
{
"name": "CVE-2025-38307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38307"
},
{
"name": "CVE-2025-40161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40161"
},
{
"name": "CVE-2025-40357",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40357"
},
{
"name": "CVE-2025-40328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40328"
},
{
"name": "CVE-2025-37916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37916"
},
{
"name": "CVE-2025-40340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40340"
},
{
"name": "CVE-2025-38111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38111"
},
{
"name": "CVE-2025-39986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39986"
},
{
"name": "CVE-2025-37767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37767"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-37989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37989"
},
{
"name": "CVE-2025-38529",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38529"
},
{
"name": "CVE-2025-40131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40131"
},
{
"name": "CVE-2025-40146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40146"
},
{
"name": "CVE-2025-38326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38326"
},
{
"name": "CVE-2025-40177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40177"
},
{
"name": "CVE-2025-38055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38055"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2025-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38384"
},
{
"name": "CVE-2025-38334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38334"
},
{
"name": "CVE-2025-38728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38728"
},
{
"name": "CVE-2025-38424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38424"
},
{
"name": "CVE-2025-38430",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38430"
},
{
"name": "CVE-2025-38715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38715"
},
{
"name": "CVE-2025-39734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39734"
},
{
"name": "CVE-2025-38089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38089"
},
{
"name": "CVE-2025-40226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40226"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-38382",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38382"
},
{
"name": "CVE-2025-40074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40074"
},
{
"name": "CVE-2025-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38608"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2025-38650",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38650"
},
{
"name": "CVE-2025-40069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40069"
},
{
"name": "CVE-2025-39710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39710"
},
{
"name": "CVE-2025-40116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40116"
},
{
"name": "CVE-2025-68249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68249"
},
{
"name": "CVE-2025-38124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38124"
},
{
"name": "CVE-2025-39934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39934"
},
{
"name": "CVE-2025-37925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37925"
},
{
"name": "CVE-2025-40158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40158"
},
{
"name": "CVE-2025-39683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39683"
},
{
"name": "CVE-2025-38420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38420"
},
{
"name": "CVE-2025-38071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38071"
},
{
"name": "CVE-2025-40327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40327"
},
{
"name": "CVE-2025-40130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40130"
},
{
"name": "CVE-2025-40179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40179"
},
{
"name": "CVE-2025-37972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37972"
},
{
"name": "CVE-2025-38183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38183"
},
{
"name": "CVE-2025-40127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40127"
},
{
"name": "CVE-2025-37768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37768"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2025-39794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39794"
},
{
"name": "CVE-2025-38160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38160"
},
{
"name": "CVE-2025-37984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37984"
},
{
"name": "CVE-2025-38528",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38528"
},
{
"name": "CVE-2025-39996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39996"
},
{
"name": "CVE-2025-40168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40168"
},
{
"name": "CVE-2025-37856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37856"
},
{
"name": "CVE-2025-38107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38107"
},
{
"name": "CVE-2025-38292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38292"
},
{
"name": "CVE-2025-40053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40053"
},
{
"name": "CVE-2025-38085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38085"
},
{
"name": "CVE-2025-38222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38222"
},
{
"name": "CVE-2025-38010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38010"
},
{
"name": "CVE-2025-38197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38197"
},
{
"name": "CVE-2025-39951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39951"
},
{
"name": "CVE-2025-38468",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38468"
},
{
"name": "CVE-2025-40120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40120"
},
{
"name": "CVE-2025-40185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40185"
},
{
"name": "CVE-2025-38688",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38688"
},
{
"name": "CVE-2025-38333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38333"
},
{
"name": "CVE-2025-40295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40295"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2025-37970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37970"
},
{
"name": "CVE-2025-21884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21884"
},
{
"name": "CVE-2025-37905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37905"
},
{
"name": "CVE-2025-38390",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38390"
},
{
"name": "CVE-2025-38013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38013"
},
{
"name": "CVE-2025-40098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40098"
},
{
"name": "CVE-2025-38059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38059"
},
{
"name": "CVE-2025-38713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38713"
},
{
"name": "CVE-2025-37956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37956"
},
{
"name": "CVE-2025-40243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40243"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2025-38148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38148"
},
{
"name": "CVE-2025-40129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40129"
},
{
"name": "CVE-2025-38467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38467"
},
{
"name": "CVE-2025-38117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38117"
},
{
"name": "CVE-2025-38094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38094"
},
{
"name": "CVE-2025-68171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68171"
},
{
"name": "CVE-2025-38072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38072"
},
{
"name": "CVE-2025-37967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37967"
},
{
"name": "CVE-2025-40301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40301"
},
{
"name": "CVE-2025-38300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38300"
},
{
"name": "CVE-2025-40040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40040"
},
{
"name": "CVE-2025-38289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38289"
},
{
"name": "CVE-2025-39782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39782"
},
{
"name": "CVE-2025-68207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68207"
},
{
"name": "CVE-2025-40066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40066"
},
{
"name": "CVE-2025-38075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38075"
},
{
"name": "CVE-2025-37885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37885"
},
{
"name": "CVE-2025-38697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38697"
},
{
"name": "CVE-2025-37949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37949"
},
{
"name": "CVE-2025-68167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68167"
},
{
"name": "CVE-2025-38691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38691"
},
{
"name": "CVE-2025-40207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40207"
},
{
"name": "CVE-2025-38373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38373"
},
{
"name": "CVE-2025-38489",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38489"
},
{
"name": "CVE-2025-40095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40095"
},
{
"name": "CVE-2025-37957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37957"
},
{
"name": "CVE-2025-38058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38058"
},
{
"name": "CVE-2025-38483",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38483"
},
{
"name": "CVE-2025-38369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38369"
},
{
"name": "CVE-2025-39759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39759"
},
{
"name": "CVE-2025-38639",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38639"
},
{
"name": "CVE-2025-38122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38122"
},
{
"name": "CVE-2025-38612",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38612"
},
{
"name": "CVE-2025-40299",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40299"
},
{
"name": "CVE-2025-38173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38173"
},
{
"name": "CVE-2025-40286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40286"
},
{
"name": "CVE-2025-38143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38143"
},
{
"name": "CVE-2025-38098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38098"
},
{
"name": "CVE-2025-40091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40091"
},
{
"name": "CVE-2025-40318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40318"
},
{
"name": "CVE-2025-38566",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38566"
},
{
"name": "CVE-2025-39721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39721"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2025-39760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39760"
},
{
"name": "CVE-2025-40118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40118"
},
{
"name": "CVE-2025-38718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38718"
},
{
"name": "CVE-2025-38392",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38392"
},
{
"name": "CVE-2025-39673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39673"
},
{
"name": "CVE-2025-38259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38259"
},
{
"name": "CVE-2025-38663",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38663"
},
{
"name": "CVE-2025-40021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40021"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2025-38156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38156"
},
{
"name": "CVE-2025-37951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37951"
},
{
"name": "CVE-2025-37840",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37840"
},
{
"name": "CVE-2025-68253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68253"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2025-37947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37947"
},
{
"name": "CVE-2025-38416",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38416"
},
{
"name": "CVE-2025-37846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37846"
},
{
"name": "CVE-2025-38722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38722"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2025-39800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39800"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-38343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38343"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2025-38202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38202"
},
{
"name": "CVE-2025-40050",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40050"
},
{
"name": "CVE-2025-40072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40072"
},
{
"name": "CVE-2025-40112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40112"
},
{
"name": "CVE-2025-40079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40079"
},
{
"name": "CVE-2025-22101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22101"
},
{
"name": "CVE-2025-38374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38374"
},
{
"name": "CVE-2025-39703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39703"
},
{
"name": "CVE-2025-38194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38194"
},
{
"name": "CVE-2025-68182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68182"
},
{
"name": "CVE-2025-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38549"
},
{
"name": "CVE-2025-40310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40310"
},
{
"name": "CVE-2025-38665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38665"
},
{
"name": "CVE-2025-38101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38101"
},
{
"name": "CVE-2025-37982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37982"
},
{
"name": "CVE-2025-37992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37992"
},
{
"name": "CVE-2025-38577",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38577"
},
{
"name": "CVE-2025-38671",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38671"
},
{
"name": "CVE-2025-68317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68317"
},
{
"name": "CVE-2025-39971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39971"
},
{
"name": "CVE-2025-38299",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38299"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2025-38635",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38635"
},
{
"name": "CVE-2025-38704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38704"
},
{
"name": "CVE-2025-38348",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38348"
},
{
"name": "CVE-2025-40270",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40270"
},
{
"name": "CVE-2025-40191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40191"
},
{
"name": "CVE-2025-38488",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38488"
},
{
"name": "CVE-2025-40189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40189"
},
{
"name": "CVE-2025-40093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40093"
},
{
"name": "CVE-2025-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38540"
},
{
"name": "CVE-2025-38040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38040"
},
{
"name": "CVE-2025-38265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38265"
},
{
"name": "CVE-2025-23149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23149"
},
{
"name": "CVE-2025-38403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38403"
},
{
"name": "CVE-2025-21726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21726"
},
{
"name": "CVE-2025-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38552"
},
{
"name": "CVE-2025-40335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40335"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2025-37914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37914"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2025-37873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37873"
},
{
"name": "CVE-2025-37928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37928"
},
{
"name": "CVE-2025-40267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40267"
},
{
"name": "CVE-2025-40235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40235"
},
{
"name": "CVE-2025-39766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39766"
},
{
"name": "CVE-2025-39801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39801"
},
{
"name": "CVE-2025-37922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37922"
},
{
"name": "CVE-2025-38146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38146"
},
{
"name": "CVE-2025-68208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68208"
},
{
"name": "CVE-2025-39724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39724"
},
{
"name": "CVE-2025-39687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39687"
},
{
"name": "CVE-2025-37794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37794"
},
{
"name": "CVE-2025-38510",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38510"
},
{
"name": "CVE-2025-38246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38246"
},
{
"name": "CVE-2025-39758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39758"
},
{
"name": "CVE-2025-39694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39694"
},
{
"name": "CVE-2025-38220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38220"
},
{
"name": "CVE-2025-38405",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38405"
},
{
"name": "CVE-2025-38418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38418"
},
{
"name": "CVE-2025-40352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40352"
},
{
"name": "CVE-2025-38090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38090"
},
{
"name": "CVE-2025-38429",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38429"
},
{
"name": "CVE-2025-38225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38225"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2025-38155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38155"
},
{
"name": "CVE-2025-40099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40099"
},
{
"name": "CVE-2025-71162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-71162"
},
{
"name": "CVE-2025-37977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37977"
},
{
"name": "CVE-2025-38365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38365"
},
{
"name": "CVE-2025-38415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38415"
},
{
"name": "CVE-2025-40031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40031"
},
{
"name": "CVE-2025-40180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40180"
},
{
"name": "CVE-2025-40293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40293"
},
{
"name": "CVE-2025-38668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38668"
},
{
"name": "CVE-2025-37973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37973"
},
{
"name": "CVE-2025-40330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40330"
},
{
"name": "CVE-2025-68750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68750"
},
{
"name": "CVE-2025-38260",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38260"
},
{
"name": "CVE-2025-37827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37827"
},
{
"name": "CVE-2025-38721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38721"
},
{
"name": "CVE-2025-38244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38244"
},
{
"name": "CVE-2025-38080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38080"
},
{
"name": "CVE-2025-40126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40126"
},
{
"name": "CVE-2025-39972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39972"
},
{
"name": "CVE-2025-37748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37748"
},
{
"name": "CVE-2025-38364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38364"
},
{
"name": "CVE-2025-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38615"
},
{
"name": "CVE-2025-39684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39684"
},
{
"name": "CVE-2025-37836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37836"
},
{
"name": "CVE-2025-38526",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38526"
},
{
"name": "CVE-2025-38472",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38472"
},
{
"name": "CVE-2025-37944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37944"
},
{
"name": "CVE-2025-38506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38506"
},
{
"name": "CVE-2025-40320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40320"
},
{
"name": "CVE-2025-38703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38703"
},
{
"name": "CVE-2025-38494",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38494"
},
{
"name": "CVE-2025-39753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39753"
},
{
"name": "CVE-2025-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38604"
},
{
"name": "CVE-2025-40203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40203"
},
{
"name": "CVE-2025-38623",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38623"
},
{
"name": "CVE-2025-38193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38193"
},
{
"name": "CVE-2025-38400",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38400"
},
{
"name": "CVE-2025-38136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38136"
},
{
"name": "CVE-2025-40192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40192"
},
{
"name": "CVE-2025-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38544"
},
{
"name": "CVE-2025-37771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37771"
},
{
"name": "CVE-2025-39797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39797"
},
{
"name": "CVE-2025-40200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40200"
},
{
"name": "CVE-2025-38236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38236"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2025-37975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37975"
},
{
"name": "CVE-2025-40124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40124"
},
{
"name": "CVE-2025-38347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38347"
},
{
"name": "CVE-2025-39776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39776"
},
{
"name": "CVE-2025-39880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39880"
},
{
"name": "CVE-2025-37998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37998"
},
{
"name": "CVE-2025-38198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38198"
},
{
"name": "CVE-2025-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23163"
},
{
"name": "CVE-2025-40094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40094"
},
{
"name": "CVE-2025-37968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37968"
},
{
"name": "CVE-2025-38376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38376"
},
{
"name": "CVE-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2025-40102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40102"
},
{
"name": "CVE-2025-40170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40170"
},
{
"name": "CVE-2025-38437",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38437"
},
{
"name": "CVE-2025-40160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40160"
},
{
"name": "CVE-2025-40284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40284"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-40209",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40209"
},
{
"name": "CVE-2025-40077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40077"
},
{
"name": "CVE-2025-38351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38351"
},
{
"name": "CVE-2025-38048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38048"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2025-38683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38683"
},
{
"name": "CVE-2025-40113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40113"
},
{
"name": "CVE-2025-39736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39736"
},
{
"name": "CVE-2025-40234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40234"
},
{
"name": "CVE-2025-37757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37757"
},
{
"name": "CVE-2025-68247",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68247"
},
{
"name": "CVE-2025-40305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40305"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-40041",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40041"
},
{
"name": "CVE-2025-38009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38009"
},
{
"name": "CVE-2025-40215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40215"
},
{
"name": "CVE-2025-40307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40307"
},
{
"name": "CVE-2025-40111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40111"
},
{
"name": "CVE-2025-38081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38081"
},
{
"name": "CVE-2025-37809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37809"
},
{
"name": "CVE-2024-36350",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36350"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2025-40068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40068"
},
{
"name": "CVE-2025-38185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38185"
},
{
"name": "CVE-2025-39691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39691"
},
{
"name": "CVE-2025-38406",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38406"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2025-40163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40163"
},
{
"name": "CVE-2025-40042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40042"
},
{
"name": "CVE-2025-37817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37817"
},
{
"name": "CVE-2025-40155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40155"
},
{
"name": "CVE-2025-39890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39890"
},
{
"name": "CVE-2025-39742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39742"
},
{
"name": "CVE-2025-40217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40217"
},
{
"name": "CVE-2025-22102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22102"
},
{
"name": "CVE-2025-37987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37987"
},
{
"name": "CVE-2025-37749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37749"
},
{
"name": "CVE-2024-36331",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36331"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2025-40133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40133"
},
{
"name": "CVE-2025-38263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38263"
},
{
"name": "CVE-2025-38610",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38610"
},
{
"name": "CVE-2025-37772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37772"
},
{
"name": "CVE-2025-38214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38214"
},
{
"name": "CVE-2025-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38560"
},
{
"name": "CVE-2025-37994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37994"
},
{
"name": "CVE-2025-38551",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38551"
},
{
"name": "CVE-2025-38701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38701"
},
{
"name": "CVE-2025-38218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38218"
},
{
"name": "CVE-2025-40329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40329"
},
{
"name": "CVE-2025-38349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38349"
},
{
"name": "CVE-2025-39726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39726"
},
{
"name": "CVE-2025-38393",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38393"
},
{
"name": "CVE-2025-37891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37891"
},
{
"name": "CVE-2025-38249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38249"
},
{
"name": "CVE-2025-38716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38716"
},
{
"name": "CVE-2025-39937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39937"
},
{
"name": "CVE-2025-37858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37858"
},
{
"name": "CVE-2025-38154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38154"
},
{
"name": "CVE-2025-38469",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38469"
},
{
"name": "CVE-2025-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38581"
},
{
"name": "CVE-2025-40034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40034"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2025-39790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39790"
},
{
"name": "CVE-2025-38389",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38389"
},
{
"name": "CVE-2025-38448",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38448"
},
{
"name": "CVE-2025-37780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37780"
},
{
"name": "CVE-2025-37995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37995"
},
{
"name": "CVE-2025-38680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38680"
},
{
"name": "CVE-2025-37754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37754"
},
{
"name": "CVE-2025-40059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40059"
},
{
"name": "CVE-2025-38497",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38497"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-23156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23156"
},
{
"name": "CVE-2025-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23157"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2025-68309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68309"
},
{
"name": "CVE-2025-38684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38684"
},
{
"name": "CVE-2025-38165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38165"
},
{
"name": "CVE-2025-40003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40003"
},
{
"name": "CVE-2025-39686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39686"
},
{
"name": "CVE-2025-39798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39798"
},
{
"name": "CVE-2025-38495",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38495"
},
{
"name": "CVE-2025-37808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37808"
},
{
"name": "CVE-2025-38730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38730"
},
{
"name": "CVE-2025-38052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38052"
},
{
"name": "CVE-2025-38377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38377"
},
{
"name": "CVE-2025-40175",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40175"
},
{
"name": "CVE-2025-68170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68170"
},
{
"name": "CVE-2025-39747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39747"
},
{
"name": "CVE-2025-68313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68313"
},
{
"name": "CVE-2025-38516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38516"
},
{
"name": "CVE-2025-38462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38462"
},
{
"name": "CVE-2025-38428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38428"
},
{
"name": "CVE-2025-39714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39714"
},
{
"name": "CVE-2025-38262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38262"
},
{
"name": "CVE-2025-38138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38138"
},
{
"name": "CVE-2025-38035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38035"
},
{
"name": "CVE-2025-37759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37759"
},
{
"name": "CVE-2025-38414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38414"
},
{
"name": "CVE-2025-68197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68197"
},
{
"name": "CVE-2025-40123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40123"
},
{
"name": "CVE-2025-37933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37933"
},
{
"name": "CVE-2025-38310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38310"
},
{
"name": "CVE-2025-37886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37886"
},
{
"name": "CVE-2025-37963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37963"
},
{
"name": "CVE-2025-40297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40297"
},
{
"name": "CVE-2025-38226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38226"
},
{
"name": "CVE-2025-39706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39706"
},
{
"name": "CVE-2025-40178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40178"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2025-38443",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38443"
},
{
"name": "CVE-2025-38576",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38576"
},
{
"name": "CVE-2025-39869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39869"
},
{
"name": "CVE-2025-37800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37800"
},
{
"name": "CVE-2025-39985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
},
{
"name": "CVE-2025-40276",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40276"
},
{
"name": "CVE-2025-37900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37900"
},
{
"name": "CVE-2025-40224",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40224"
},
{
"name": "CVE-2025-38439",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38439"
},
{
"name": "CVE-2025-37805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37805"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2025-39719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39719"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2025-40236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40236"
},
{
"name": "CVE-2025-37990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37990"
},
{
"name": "CVE-2025-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38553"
},
{
"name": "CVE-2025-38190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38190"
},
{
"name": "CVE-2025-38180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38180"
},
{
"name": "CVE-2025-39738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39738"
},
{
"name": "CVE-2025-68202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68202"
},
{
"name": "CVE-2025-38145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38145"
},
{
"name": "CVE-2025-40174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40174"
},
{
"name": "CVE-2025-37948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37948"
},
{
"name": "CVE-2025-38166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38166"
},
{
"name": "CVE-2025-40227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40227"
},
{
"name": "CVE-2025-37862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37862"
},
{
"name": "CVE-2025-38321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38321"
},
{
"name": "CVE-2025-39705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39705"
},
{
"name": "CVE-2025-40316",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40316"
},
{
"name": "CVE-2025-37960",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37960"
},
{
"name": "CVE-2025-38045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38045"
},
{
"name": "CVE-2025-38051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38051"
},
{
"name": "CVE-2025-39713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39713"
},
{
"name": "CVE-2025-37763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37763"
},
{
"name": "CVE-2025-37954",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37954"
},
{
"name": "CVE-2025-22128",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22128"
},
{
"name": "CVE-2025-40065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40065"
},
{
"name": "CVE-2025-37839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37839"
},
{
"name": "CVE-2025-39744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39744"
},
{
"name": "CVE-2025-38277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38277"
},
{
"name": "CVE-2025-37913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37913"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38539"
},
{
"name": "CVE-2025-40181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40181"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2025-38044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38044"
},
{
"name": "CVE-2025-68250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68250"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2025-40141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40141"
},
{
"name": "CVE-2025-38200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38200"
},
{
"name": "CVE-2025-38480",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38480"
},
{
"name": "CVE-2025-40132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40132"
},
{
"name": "CVE-2025-38346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38346"
},
{
"name": "CVE-2025-40152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40152"
},
{
"name": "CVE-2025-37959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37959"
},
{
"name": "CVE-2025-38191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38191"
},
{
"name": "CVE-2025-39946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39946"
},
{
"name": "CVE-2025-38062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38062"
},
{
"name": "CVE-2025-38531",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38531"
},
{
"name": "CVE-2025-40288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40288"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2025-39693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39693"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-38503",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38503"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2025-40162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40162"
},
{
"name": "CVE-2025-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38630"
},
{
"name": "CVE-2025-38131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38131"
},
{
"name": "CVE-2025-40268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40268"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2025-37851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37851"
},
{
"name": "CVE-2025-38481",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38481"
},
{
"name": "CVE-2025-38585",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38585"
},
{
"name": "CVE-2025-38320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38320"
},
{
"name": "CVE-2025-38625",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38625"
},
{
"name": "CVE-2025-38164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38164"
},
{
"name": "CVE-2025-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40303"
},
{
"name": "CVE-2025-68178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68178"
},
{
"name": "CVE-2025-40337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40337"
},
{
"name": "CVE-2025-40346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40346"
},
{
"name": "CVE-2025-38264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38264"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2025-39676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39676"
},
{
"name": "CVE-2025-40241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40241"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2025-38280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38280"
},
{
"name": "CVE-2025-37788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37788"
},
{
"name": "CVE-2025-38427",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38427"
},
{
"name": "CVE-2025-38084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38084"
},
{
"name": "CVE-2025-40046",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40046"
},
{
"name": "CVE-2025-37879",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37879"
},
{
"name": "CVE-2025-38217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38217"
},
{
"name": "CVE-2025-40030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40030"
},
{
"name": "CVE-2025-40244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40244"
},
{
"name": "CVE-2025-37881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37881"
},
{
"name": "CVE-2025-39995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39995"
},
{
"name": "CVE-2025-38103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38103"
},
{
"name": "CVE-2025-38514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38514"
},
{
"name": "CVE-2025-39783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39783"
},
{
"name": "CVE-2025-39715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39715"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38569"
},
{
"name": "CVE-2025-38255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38255"
},
{
"name": "CVE-2025-38512",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38512"
},
{
"name": "CVE-2025-40096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40096"
},
{
"name": "CVE-2025-38622",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38622"
},
{
"name": "CVE-2025-37909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37909"
},
{
"name": "CVE-2025-38700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38700"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2025-38532",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38532"
},
{
"name": "CVE-2025-39712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39712"
},
{
"name": "CVE-2025-37812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37812"
},
{
"name": "CVE-2025-39707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39707"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2025-37875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37875"
},
{
"name": "CVE-2025-38410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38410"
},
{
"name": "CVE-2025-39907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39907"
},
{
"name": "CVE-2025-40182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40182"
},
{
"name": "CVE-2025-68211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68211"
},
{
"name": "CVE-2025-39781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39781"
},
{
"name": "CVE-2025-38640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38640"
},
{
"name": "CVE-2025-38476",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38476"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2025-40339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40339"
},
{
"name": "CVE-2025-40140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40140"
},
{
"name": "CVE-2025-38020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38020"
},
{
"name": "CVE-2025-40223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40223"
},
{
"name": "CVE-2025-38572",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38572"
},
{
"name": "CVE-2025-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23140"
},
{
"name": "CVE-2025-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23150"
},
{
"name": "CVE-2025-38460",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38460"
},
{
"name": "CVE-2025-40061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40061"
},
{
"name": "CVE-2025-38182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38182"
},
{
"name": "CVE-2025-38550",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38550"
},
{
"name": "CVE-2024-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53114"
},
{
"name": "CVE-2025-38275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38275"
},
{
"name": "CVE-2025-40213",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40213"
},
{
"name": "CVE-2025-38345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38345"
},
{
"name": "CVE-2025-40334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40334"
},
{
"name": "CVE-2025-38170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38170"
},
{
"name": "CVE-2025-39711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39711"
},
{
"name": "CVE-2025-22115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22115"
},
{
"name": "CVE-2025-22120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22120"
},
{
"name": "CVE-2025-38535",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38535"
},
{
"name": "CVE-2025-38231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38231"
},
{
"name": "CVE-2025-37854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37854"
},
{
"name": "CVE-2025-40142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40142"
},
{
"name": "CVE-2025-39873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39873"
},
{
"name": "CVE-2025-40159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40159"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2025-68193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68193"
},
{
"name": "CVE-2025-38473",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38473"
},
{
"name": "CVE-2025-38113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38113"
},
{
"name": "CVE-2025-38714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38714"
},
{
"name": "CVE-2025-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23148"
},
{
"name": "CVE-2025-38361",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38361"
},
{
"name": "CVE-2025-38470",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38470"
},
{
"name": "CVE-2025-38181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38181"
},
{
"name": "CVE-2025-40051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40051"
},
{
"name": "CVE-2025-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38391"
},
{
"name": "CVE-2025-38248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38248"
},
{
"name": "CVE-2025-40351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40351"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-40229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40229"
},
{
"name": "CVE-2025-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23147"
},
{
"name": "CVE-2025-39752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39752"
}
],
"initial_release_date": "2026-02-20T00:00:00",
"last_revision_date": "2026-02-20T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0194",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-02-20T00: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": "2026-02-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8048-1",
"url": "https://ubuntu.com/security/notices/USN-8048-1"
},
{
"published_at": "2026-02-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8028-5",
"url": "https://ubuntu.com/security/notices/USN-8028-5"
},
{
"published_at": "2026-02-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8052-1",
"url": "https://ubuntu.com/security/notices/USN-8052-1"
},
{
"published_at": "2026-02-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8028-7",
"url": "https://ubuntu.com/security/notices/USN-8028-7"
},
{
"published_at": "2026-02-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8033-5",
"url": "https://ubuntu.com/security/notices/USN-8033-5"
},
{
"published_at": "2026-02-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8033-6",
"url": "https://ubuntu.com/security/notices/USN-8033-6"
},
{
"published_at": "2026-02-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8028-3",
"url": "https://ubuntu.com/security/notices/USN-8028-3"
},
{
"published_at": "2026-02-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7990-5",
"url": "https://ubuntu.com/security/notices/USN-7990-5"
},
{
"published_at": "2026-02-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8029-2",
"url": "https://ubuntu.com/security/notices/USN-8029-2"
},
{
"published_at": "2026-02-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8034-2",
"url": "https://ubuntu.com/security/notices/USN-8034-2"
},
{
"published_at": "2026-02-17",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8028-4",
"url": "https://ubuntu.com/security/notices/USN-8028-4"
},
{
"published_at": "2026-02-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8031-3",
"url": "https://ubuntu.com/security/notices/USN-8031-3"
},
{
"published_at": "2026-02-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8031-2",
"url": "https://ubuntu.com/security/notices/USN-8031-2"
},
{
"published_at": "2026-02-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8028-6",
"url": "https://ubuntu.com/security/notices/USN-8028-6"
},
{
"published_at": "2026-02-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8033-7",
"url": "https://ubuntu.com/security/notices/USN-8033-7"
},
{
"published_at": "2026-02-19",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8033-8",
"url": "https://ubuntu.com/security/notices/USN-8033-8"
}
]
}
CERTFR-2026-AVI-0218
Vulnerability from certfr_avis - Published: 2026-02-26 - Updated: 2026-02-26
De multiples vulnérabilités ont été découvertes dans les produits VMware. Certaines d'entre elles permettent à un attaquant de provoquer un déni de service à distance, une atteinte à la confidentialité 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).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| VMware | Tanzu Kubernetes Runtime | Platform Services pour Tanzu Platform versions antérieures à 10.3.5 | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Hub versions antérieures à 10.3.5 | ||
| VMware | Tanzu Data Intelligence | Tanzu pour Postgres versions 16.x antérieures à 16.12.0 | ||
| VMware | Tanzu Data Intelligence | Tanzu pour Postgres versions antérieures à 4.3.2 sur Kubernetes | ||
| VMware | Tanzu Data Intelligence | Tanzu pour Postgres versions 18.x antérieures à 18.2.0 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Noble) versions antérieures à 1.238.x | ||
| VMware | Workstation | Workstation versions antérieures à 25H2u1 | ||
| VMware | Fusion | Fusion versions antérieures à 25H2u1 sur MacOS | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy) versions antérieures à 1.1065.x | ||
| VMware | Tanzu Data Intelligence | Tanzu pour Postgres versions 15.x antérieures à 15.16.0 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Windows) versions antérieures à 2019.95.x | ||
| VMware | Tanzu Data Intelligence | Tanzu pour Postgres versions 17.x antérieures à 17.8.0 | ||
| VMware | Tanzu Data Intelligence | Tanzu pour Postgres versions antérieures à 14.21.0 |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "Platform Services pour Tanzu Platform versions ant\u00e9rieures \u00e0 10.3.5",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Hub versions ant\u00e9rieures \u00e0 10.3.5",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu pour Postgres versions 16.x ant\u00e9rieures \u00e0 16.12.0",
"product": {
"name": "Tanzu Data Intelligence",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu pour Postgres versions ant\u00e9rieures \u00e0 4.3.2 sur Kubernetes",
"product": {
"name": "Tanzu Data Intelligence",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu pour Postgres versions 18.x ant\u00e9rieures \u00e0 18.2.0",
"product": {
"name": "Tanzu Data Intelligence",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Noble) versions ant\u00e9rieures \u00e0 1.238.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Workstation versions ant\u00e9rieures \u00e0 25H2u1",
"product": {
"name": "Workstation",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Fusion versions ant\u00e9rieures \u00e0 25H2u1 sur MacOS",
"product": {
"name": "Fusion",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy) versions ant\u00e9rieures \u00e0 1.1065.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu pour Postgres versions 15.x ant\u00e9rieures \u00e0 15.16.0",
"product": {
"name": "Tanzu Data Intelligence",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Windows) versions ant\u00e9rieures \u00e0 2019.95.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu pour Postgres versions 17.x ant\u00e9rieures \u00e0 17.8.0",
"product": {
"name": "Tanzu Data Intelligence",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu pour Postgres versions ant\u00e9rieures \u00e0 14.21.0",
"product": {
"name": "Tanzu Data Intelligence",
"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-2019-25013",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-25013"
},
{
"name": "CVE-2017-9937",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-9937"
},
{
"name": "CVE-2025-6395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6395"
},
{
"name": "CVE-2026-22722",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22722"
},
{
"name": "CVE-2023-52356",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52356"
},
{
"name": "CVE-2013-4235",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-4235"
},
{
"name": "CVE-2025-8715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8715"
},
{
"name": "CVE-2017-3613",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3613"
},
{
"name": "CVE-2021-22898",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22898"
},
{
"name": "CVE-2025-38490",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38490"
},
{
"name": "CVE-2025-37850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37850"
},
{
"name": "CVE-2025-66865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66865"
},
{
"name": "CVE-2022-35252",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-35252"
},
{
"name": "CVE-2005-0602",
"url": "https://www.cve.org/CVERecord?id=CVE-2005-0602"
},
{
"name": "CVE-2025-61730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61730"
},
{
"name": "CVE-2025-38485",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38485"
},
{
"name": "CVE-2025-22026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22026"
},
{
"name": "CVE-2025-39987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39987"
},
{
"name": "CVE-2025-62727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62727"
},
{
"name": "CVE-2015-4789",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4789"
},
{
"name": "CVE-2025-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38579"
},
{
"name": "CVE-2025-37761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37761"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-37865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37865"
},
{
"name": "CVE-2025-38328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38328"
},
{
"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-2024-7006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7006"
},
{
"name": "CVE-2026-21932",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21932"
},
{
"name": "CVE-2023-3316",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3316"
},
{
"name": "CVE-2025-15282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15282"
},
{
"name": "CVE-2025-38711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38711"
},
{
"name": "CVE-2025-38487",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38487"
},
{
"name": "CVE-2024-9681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9681"
},
{
"name": "CVE-2025-58190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58190"
},
{
"name": "CVE-2025-37775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37775"
},
{
"name": "CVE-2025-38335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38335"
},
{
"name": "CVE-2024-11168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11168"
},
{
"name": "CVE-2025-38304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38304"
},
{
"name": "CVE-2025-37892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37892"
},
{
"name": "CVE-2025-38100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38100"
},
{
"name": "CVE-2025-37859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37859"
},
{
"name": "CVE-2025-9231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9231"
},
{
"name": "CVE-2025-1372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1372"
},
{
"name": "CVE-2025-8851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8851"
},
{
"name": "CVE-2025-38043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38043"
},
{
"name": "CVE-2025-68973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68973"
},
{
"name": "CVE-2025-38471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38471"
},
{
"name": "CVE-2025-38520",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38520"
},
{
"name": "CVE-2025-37792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37792"
},
{
"name": "CVE-2022-3626",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3626"
},
{
"name": "CVE-2024-28834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28834"
},
{
"name": "CVE-2021-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38604"
},
{
"name": "CVE-2001-1268",
"url": "https://www.cve.org/CVERecord?id=CVE-2001-1268"
},
{
"name": "CVE-2024-37891",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37891"
},
{
"name": "CVE-2025-38108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38108"
},
{
"name": "CVE-2025-38230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38230"
},
{
"name": "CVE-2025-38229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38229"
},
{
"name": "CVE-2023-46218",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46218"
},
{
"name": "CVE-2025-40055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40055"
},
{
"name": "CVE-2025-38158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38158"
},
{
"name": "CVE-2025-37872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37872"
},
{
"name": "CVE-2025-9714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9714"
},
{
"name": "CVE-2025-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38588"
},
{
"name": "CVE-2026-22801",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22801"
},
{
"name": "CVE-2025-39876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39876"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-38279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38279"
},
{
"name": "CVE-2025-38561",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38561"
},
{
"name": "CVE-2014-8141",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-8141"
},
{
"name": "CVE-2025-38574",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38574"
},
{
"name": "CVE-2022-2255",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2255"
},
{
"name": "CVE-2025-10148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10148"
},
{
"name": "CVE-2025-25724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25724"
},
{
"name": "CVE-2025-27818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27818"
},
{
"name": "CVE-2025-14087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14087"
},
{
"name": "CVE-2025-40048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40048"
},
{
"name": "CVE-2025-5222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5222"
},
{
"name": "CVE-2025-38147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38147"
},
{
"name": "CVE-2023-6780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6780"
},
{
"name": "CVE-2022-48468",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48468"
},
{
"name": "CVE-2025-23155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23155"
},
{
"name": "CVE-2025-38286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38286"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-39757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39757"
},
{
"name": "CVE-2025-38501",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38501"
},
{
"name": "CVE-2025-38474",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38474"
},
{
"name": "CVE-2025-7545",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7545"
},
{
"name": "CVE-2025-37979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37979"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2024-3220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3220"
},
{
"name": "CVE-2022-3599",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3599"
},
{
"name": "CVE-2025-37777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37777"
},
{
"name": "CVE-2021-39537",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-39537"
},
{
"name": "CVE-2025-39772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39772"
},
{
"name": "CVE-2025-37936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37936"
},
{
"name": "CVE-2015-4787",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4787"
},
{
"name": "CVE-2022-27781",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27781"
},
{
"name": "CVE-2025-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38601"
},
{
"name": "CVE-2021-22925",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22925"
},
{
"name": "CVE-2025-37766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37766"
},
{
"name": "CVE-2022-47008",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-47008"
},
{
"name": "CVE-2023-0796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0796"
},
{
"name": "CVE-2025-38104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38104"
},
{
"name": "CVE-2025-37844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37844"
},
{
"name": "CVE-2016-0682",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0682"
},
{
"name": "CVE-2025-21931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21931"
},
{
"name": "CVE-2025-37871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37871"
},
{
"name": "CVE-2025-37778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37778"
},
{
"name": "CVE-2025-39716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39716"
},
{
"name": "CVE-2025-39702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39702"
},
{
"name": "CVE-2025-39973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39973"
},
{
"name": "CVE-2025-38515",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38515"
},
{
"name": "CVE-2025-22872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22872"
},
{
"name": "CVE-2025-38645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38645"
},
{
"name": "CVE-2025-8941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8941"
},
{
"name": "CVE-2023-52425",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52425"
},
{
"name": "CVE-2025-38163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38163"
},
{
"name": "CVE-2025-22126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22126"
},
{
"name": "CVE-2025-38444",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38444"
},
{
"name": "CVE-2025-38109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38109"
},
{
"name": "CVE-2023-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38546"
},
{
"name": "CVE-2025-39779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39779"
},
{
"name": "CVE-2025-66866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66866"
},
{
"name": "CVE-2025-28164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-28164"
},
{
"name": "CVE-2025-37755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37755"
},
{
"name": "CVE-2025-39685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39685"
},
{
"name": "CVE-2025-38660",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38660"
},
{
"name": "CVE-2025-39761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39761"
},
{
"name": "CVE-2025-39943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39943"
},
{
"name": "CVE-2025-39945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39945"
},
{
"name": "CVE-2025-11840",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11840"
},
{
"name": "CVE-2025-11731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11731"
},
{
"name": "CVE-2024-33602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33602"
},
{
"name": "CVE-2022-47629",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-47629"
},
{
"name": "CVE-2025-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39883"
},
{
"name": "CVE-2025-39720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39720"
},
{
"name": "CVE-2025-38624",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38624"
},
{
"name": "CVE-2025-38388",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38388"
},
{
"name": "CVE-2022-48554",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48554"
},
{
"name": "CVE-2022-0563",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0563"
},
{
"name": "CVE-2025-38157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38157"
},
{
"name": "CVE-2025-4056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4056"
},
{
"name": "CVE-2025-37790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37790"
},
{
"name": "CVE-2024-28757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28757"
},
{
"name": "CVE-2020-29562",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-29562"
},
{
"name": "CVE-2025-38417",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38417"
},
{
"name": "CVE-2025-0913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0913"
},
{
"name": "CVE-2025-39746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39746"
},
{
"name": "CVE-2015-4776",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4776"
},
{
"name": "CVE-2025-38323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38323"
},
{
"name": "CVE-2025-40019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40019"
},
{
"name": "CVE-2017-3616",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3616"
},
{
"name": "CVE-2025-38208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38208"
},
{
"name": "CVE-2025-27817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27817"
},
{
"name": "CVE-2023-30086",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30086"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-38219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38219"
},
{
"name": "CVE-2025-39889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39889"
},
{
"name": "CVE-2015-4785",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4785"
},
{
"name": "CVE-2025-38099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38099"
},
{
"name": "CVE-2025-38524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38524"
},
{
"name": "CVE-2025-38466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38466"
},
{
"name": "CVE-2025-37758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37758"
},
{
"name": "CVE-2022-32208",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32208"
},
{
"name": "CVE-2025-40081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40081"
},
{
"name": "CVE-2025-38087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38087"
},
{
"name": "CVE-2025-47907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47907"
},
{
"name": "CVE-2025-1181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1181"
},
{
"name": "CVE-2022-41409",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41409"
},
{
"name": "CVE-2023-25586",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25586"
},
{
"name": "CVE-2024-12797",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12797"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2025-12084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12084"
},
{
"name": "CVE-2025-38039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38039"
},
{
"name": "CVE-2017-20052",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-20052"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40153"
},
{
"name": "CVE-2025-0840",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0840"
},
{
"name": "CVE-2022-2057",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2057"
},
{
"name": "CVE-2023-45853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45853"
},
{
"name": "CVE-2025-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38595"
},
{
"name": "CVE-2024-47611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47611"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2025-40121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40121"
},
{
"name": "CVE-2025-45582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-45582"
},
{
"name": "CVE-2025-11468",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11468"
},
{
"name": "CVE-2025-40204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40204"
},
{
"name": "CVE-2025-37852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37852"
},
{
"name": "CVE-2025-37841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37841"
},
{
"name": "CVE-2025-40171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40171"
},
{
"name": "CVE-2025-37918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37918"
},
{
"name": "CVE-2025-37917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37917"
},
{
"name": "CVE-2025-38290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38290"
},
{
"name": "CVE-2021-22901",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22901"
},
{
"name": "CVE-2025-38063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38063"
},
{
"name": "CVE-2021-3998",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3998"
},
{
"name": "CVE-2025-1179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1179"
},
{
"name": "CVE-2025-37770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37770"
},
{
"name": "CVE-2025-37773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37773"
},
{
"name": "CVE-2023-26965",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26965"
},
{
"name": "CVE-2023-2602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2602"
},
{
"name": "CVE-2025-6069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6069"
},
{
"name": "CVE-2017-10140",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-10140"
},
{
"name": "CVE-2024-6232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6232"
},
{
"name": "CVE-2025-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38578"
},
{
"name": "CVE-2025-38675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38675"
},
{
"name": "CVE-2025-39911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39911"
},
{
"name": "CVE-2025-69419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69419"
},
{
"name": "CVE-2025-6052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6052"
},
{
"name": "CVE-2025-38646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38646"
},
{
"name": "CVE-2025-38491",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38491"
},
{
"name": "CVE-2025-38708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38708"
},
{
"name": "CVE-2025-37961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37961"
},
{
"name": "CVE-2025-40125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40125"
},
{
"name": "CVE-2023-52426",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52426"
},
{
"name": "CVE-2025-38313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38313"
},
{
"name": "CVE-2025-38336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38336"
},
{
"name": "CVE-2025-40349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40349"
},
{
"name": "CVE-2025-6075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6075"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2022-2058",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2058"
},
{
"name": "CVE-2025-38644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38644"
},
{
"name": "CVE-2025-38692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38692"
},
{
"name": "CVE-2025-38061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38061"
},
{
"name": "CVE-2024-45492",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45492"
},
{
"name": "CVE-2025-37983",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37983"
},
{
"name": "CVE-2015-4764",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4764"
},
{
"name": "CVE-2025-38127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38127"
},
{
"name": "CVE-2026-22715",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22715"
},
{
"name": "CVE-2020-1752",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-1752"
},
{
"name": "CVE-2025-38375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38375"
},
{
"name": "CVE-2025-37784",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37784"
},
{
"name": "CVE-2025-39701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39701"
},
{
"name": "CVE-2015-4779",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4779"
},
{
"name": "CVE-2025-4330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4330"
},
{
"name": "CVE-2025-40187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40187"
},
{
"name": "CVE-2025-37920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37920"
},
{
"name": "CVE-2025-58185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58185"
},
{
"name": "CVE-2025-37815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37815"
},
{
"name": "CVE-2025-38686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38686"
},
{
"name": "CVE-2025-37819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37819"
},
{
"name": "CVE-2025-49794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49794"
},
{
"name": "CVE-2024-57970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57970"
},
{
"name": "CVE-2025-39913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39913"
},
{
"name": "CVE-2024-9287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9287"
},
{
"name": "CVE-2022-32207",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32207"
},
{
"name": "CVE-2025-40092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40092"
},
{
"name": "CVE-2022-47007",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-47007"
},
{
"name": "CVE-2025-4138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4138"
},
{
"name": "CVE-2025-61731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61731"
},
{
"name": "CVE-2022-3627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3627"
},
{
"name": "CVE-2025-38609",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38609"
},
{
"name": "CVE-2025-39967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39967"
},
{
"name": "CVE-2023-36632",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36632"
},
{
"name": "CVE-2025-38463",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38463"
},
{
"name": "CVE-2025-40115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40115"
},
{
"name": "CVE-2023-25433",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25433"
},
{
"name": "CVE-2025-38112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38112"
},
{
"name": "CVE-2025-66863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66863"
},
{
"name": "CVE-2015-4780",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4780"
},
{
"name": "CVE-2025-38521",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38521"
},
{
"name": "CVE-2025-38023",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38023"
},
{
"name": "CVE-2025-39709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39709"
},
{
"name": "CVE-2025-38282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38282"
},
{
"name": "CVE-2024-56171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56171"
},
{
"name": "CVE-2025-39689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39689"
},
{
"name": "CVE-2025-38215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38215"
},
{
"name": "CVE-2022-3598",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3598"
},
{
"name": "CVE-2023-0798",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0798"
},
{
"name": "CVE-2025-39787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39787"
},
{
"name": "CVE-2025-37943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37943"
},
{
"name": "CVE-2025-37745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37745"
},
{
"name": "CVE-2025-8176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8176"
},
{
"name": "CVE-2025-13837",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13837"
},
{
"name": "CVE-2025-39731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39731"
},
{
"name": "CVE-2025-38734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38734"
},
{
"name": "CVE-2025-38653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38653"
},
{
"name": "CVE-2025-38571",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38571"
},
{
"name": "CVE-2025-37789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37789"
},
{
"name": "CVE-2025-24970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24970"
},
{
"name": "CVE-2022-38476",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38476"
},
{
"name": "CVE-2021-45078",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-45078"
},
{
"name": "CVE-2025-38695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38695"
},
{
"name": "CVE-2022-3515",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3515"
},
{
"name": "CVE-2025-38004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38004"
},
{
"name": "CVE-2025-39749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39749"
},
{
"name": "CVE-2025-39949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39949"
},
{
"name": "CVE-2015-7696",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7696"
},
{
"name": "CVE-2022-4285",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4285"
},
{
"name": "CVE-2025-38387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38387"
},
{
"name": "CVE-2015-4754",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4754"
},
{
"name": "CVE-2025-38362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38362"
},
{
"name": "CVE-2022-27776",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27776"
},
{
"name": "CVE-2023-45322",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45322"
},
{
"name": "CVE-2025-40173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40173"
},
{
"name": "CVE-2025-37924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37924"
},
{
"name": "CVE-2026-22716",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22716"
},
{
"name": "CVE-2024-8176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8176"
},
{
"name": "CVE-2025-38371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38371"
},
{
"name": "CVE-2023-2731",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2731"
},
{
"name": "CVE-2025-58767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58767"
},
{
"name": "CVE-2024-56538",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56538"
},
{
"name": "CVE-2025-39923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39923"
},
{
"name": "CVE-2021-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35939"
},
{
"name": "CVE-2025-38445",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38445"
},
{
"name": "CVE-2025-38456",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38456"
},
{
"name": "CVE-2025-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38538"
},
{
"name": "CVE-2024-38819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38819"
},
{
"name": "CVE-2023-0803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0803"
},
{
"name": "CVE-2025-37867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37867"
},
{
"name": "CVE-2025-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23160"
},
{
"name": "CVE-2025-6176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6176"
},
{
"name": "CVE-2022-47695",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-47695"
},
{
"name": "CVE-2025-38295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38295"
},
{
"name": "CVE-2025-15367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15367"
},
{
"name": "CVE-2025-38461",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38461"
},
{
"name": "CVE-2025-37857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37857"
},
{
"name": "CVE-2023-30774",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30774"
},
{
"name": "CVE-2024-13176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-13176"
},
{
"name": "CVE-2025-37842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37842"
},
{
"name": "CVE-2025-39953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39953"
},
{
"name": "CVE-2022-50458",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50458"
},
{
"name": "CVE-2025-15467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15467"
},
{
"name": "CVE-2024-58251",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58251"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2026-2006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2006"
},
{
"name": "CVE-2023-28322",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28322"
},
{
"name": "CVE-2025-39681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39681"
},
{
"name": "CVE-2025-1180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1180"
},
{
"name": "CVE-2025-38060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38060"
},
{
"name": "CVE-2025-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40167"
},
{
"name": "CVE-2025-38159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38159"
},
{
"name": "CVE-2021-3421",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3421"
},
{
"name": "CVE-2025-38066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38066"
},
{
"name": "CVE-2025-4373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4373"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2015-4790",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4790"
},
{
"name": "CVE-2026-0994",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0994"
},
{
"name": "CVE-2025-39969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39969"
},
{
"name": "CVE-2025-37744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37744"
},
{
"name": "CVE-2025-4598",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4598"
},
{
"name": "CVE-2025-38705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38705"
},
{
"name": "CVE-2025-40194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40194"
},
{
"name": "CVE-2025-38706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38706"
},
{
"name": "CVE-2025-38305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38305"
},
{
"name": "CVE-2025-37884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37884"
},
{
"name": "CVE-2025-38067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38067"
},
{
"name": "CVE-2025-39750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39750"
},
{
"name": "CVE-2025-38699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38699"
},
{
"name": "CVE-2025-37927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37927"
},
{
"name": "CVE-2025-38707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38707"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2025-37897",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37897"
},
{
"name": "CVE-2016-9840",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-9840"
},
{
"name": "CVE-2025-37911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37911"
},
{
"name": "CVE-2025-40245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40245"
},
{
"name": "CVE-2025-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38587"
},
{
"name": "CVE-2023-6779",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6779"
},
{
"name": "CVE-2025-37869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37869"
},
{
"name": "CVE-2025-39692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39692"
},
{
"name": "CVE-2025-5115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5115"
},
{
"name": "CVE-2023-53107",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53107"
},
{
"name": "CVE-2024-13009",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-13009"
},
{
"name": "CVE-2022-49043",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49043"
},
{
"name": "CVE-2025-55198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55198"
},
{
"name": "CVE-2021-46195",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46195"
},
{
"name": "CVE-2015-2624",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2624"
},
{
"name": "CVE-2023-29491",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29491"
},
{
"name": "CVE-2025-38068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38068"
},
{
"name": "CVE-2025-38436",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38436"
},
{
"name": "CVE-2025-37930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37930"
},
{
"name": "CVE-2025-38401",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38401"
},
{
"name": "CVE-2025-38677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38677"
},
{
"name": "CVE-2025-38097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38097"
},
{
"name": "CVE-2021-20266",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20266"
},
{
"name": "CVE-2025-1182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1182"
},
{
"name": "CVE-2025-37810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37810"
},
{
"name": "CVE-2025-38253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38253"
},
{
"name": "CVE-2025-38123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38123"
},
{
"name": "CVE-2025-38338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38338"
},
{
"name": "CVE-2025-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38555"
},
{
"name": "CVE-2025-38239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38239"
},
{
"name": "CVE-2025-1371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1371"
},
{
"name": "CVE-2025-40001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40001"
},
{
"name": "CVE-2022-40897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
},
{
"name": "CVE-2026-1485",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1485"
},
{
"name": "CVE-2025-0938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0938"
},
{
"name": "CVE-2022-27782",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27782"
},
{
"name": "CVE-2008-0888",
"url": "https://www.cve.org/CVERecord?id=CVE-2008-0888"
},
{
"name": "CVE-2019-13232",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-13232"
},
{
"name": "CVE-2025-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38590"
},
{
"name": "CVE-2025-38027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38027"
},
{
"name": "CVE-2025-38102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38102"
},
{
"name": "CVE-2024-33600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33600"
},
{
"name": "CVE-2015-2654",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2654"
},
{
"name": "CVE-2022-1210",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1210"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-38283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38283"
},
{
"name": "CVE-2023-25584",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25584"
},
{
"name": "CVE-2025-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23159"
},
{
"name": "CVE-2025-39988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39988"
},
{
"name": "CVE-2026-2005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2005"
},
{
"name": "CVE-2025-38455",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38455"
},
{
"name": "CVE-2015-4778",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4778"
},
{
"name": "CVE-2025-1152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1152"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2025-38015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38015"
},
{
"name": "CVE-2025-39675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39675"
},
{
"name": "CVE-2025-39679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39679"
},
{
"name": "CVE-2025-11082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11082"
},
{
"name": "CVE-2025-38527",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38527"
},
{
"name": "CVE-2025-38449",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38449"
},
{
"name": "CVE-2025-40233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40233"
},
{
"name": "CVE-2023-32636",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32636"
},
{
"name": "CVE-2025-37853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37853"
},
{
"name": "CVE-2023-6277",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6277"
},
{
"name": "CVE-2025-38126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38126"
},
{
"name": "CVE-2025-48060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48060"
},
{
"name": "CVE-2025-38149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38149"
},
{
"name": "CVE-2025-39763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39763"
},
{
"name": "CVE-2025-38399",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38399"
},
{
"name": "CVE-2025-40020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40020"
},
{
"name": "CVE-2025-38065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38065"
},
{
"name": "CVE-2025-38693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38693"
},
{
"name": "CVE-2025-38679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38679"
},
{
"name": "CVE-2025-38459",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38459"
},
{
"name": "CVE-2025-40188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40188"
},
{
"name": "CVE-2025-38685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38685"
},
{
"name": "CVE-2023-3618",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3618"
},
{
"name": "CVE-2025-38412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38412"
},
{
"name": "CVE-2025-38031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38031"
},
{
"name": "CVE-2023-4813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4813"
},
{
"name": "CVE-2017-3617",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3617"
},
{
"name": "CVE-2025-14512",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14512"
},
{
"name": "CVE-2025-38293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38293"
},
{
"name": "CVE-2025-58057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58057"
},
{
"name": "CVE-2025-1149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1149"
},
{
"name": "CVE-2025-38648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38648"
},
{
"name": "CVE-2025-38278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38278"
},
{
"name": "CVE-2025-8291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8291"
},
{
"name": "CVE-2025-37764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37764"
},
{
"name": "CVE-2025-38184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38184"
},
{
"name": "CVE-2017-3615",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3615"
},
{
"name": "CVE-2022-44840",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44840"
},
{
"name": "CVE-2023-28320",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28320"
},
{
"name": "CVE-2025-37741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37741"
},
{
"name": "CVE-2026-22795",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22795"
},
{
"name": "CVE-2025-38053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38053"
},
{
"name": "CVE-2025-27587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27587"
},
{
"name": "CVE-2026-0988",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0988"
},
{
"name": "CVE-2025-8534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8534"
},
{
"name": "CVE-2025-37822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37822"
},
{
"name": "CVE-2025-61727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61727"
},
{
"name": "CVE-2025-37912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37912"
},
{
"name": "CVE-2025-38482",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38482"
},
{
"name": "CVE-2023-39810",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39810"
},
{
"name": "CVE-2025-37820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37820"
},
{
"name": "CVE-2025-37985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37985"
},
{
"name": "CVE-2025-1390",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1390"
},
{
"name": "CVE-2024-33599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33599"
},
{
"name": "CVE-2024-0743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0743"
},
{
"name": "CVE-2025-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38634"
},
{
"name": "CVE-2025-37787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37787"
},
{
"name": "CVE-2026-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21925"
},
{
"name": "CVE-2025-38008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38008"
},
{
"name": "CVE-2025-38458",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38458"
},
{
"name": "CVE-2025-39730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39730"
},
{
"name": "CVE-2025-38011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38011"
},
{
"name": "CVE-2025-64718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64718"
},
{
"name": "CVE-2022-50444",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50444"
},
{
"name": "CVE-2025-38034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38034"
},
{
"name": "CVE-2017-3608",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3608"
},
{
"name": "CVE-2025-38135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38135"
},
{
"name": "CVE-2023-28484",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28484"
},
{
"name": "CVE-2025-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38619"
},
{
"name": "CVE-2019-2708",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-2708"
},
{
"name": "CVE-2025-38312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38312"
},
{
"name": "CVE-2025-38095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38095"
},
{
"name": "CVE-2016-0692",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0692"
},
{
"name": "CVE-2025-37878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37878"
},
{
"name": "CVE-2025-39737",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39737"
},
{
"name": "CVE-2025-38464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38464"
},
{
"name": "CVE-2021-46174",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46174"
},
{
"name": "CVE-2026-0861",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0861"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2023-0802",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0802"
},
{
"name": "CVE-2023-53164",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53164"
},
{
"name": "CVE-2025-47910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47910"
},
{
"name": "CVE-2021-22924",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22924"
},
{
"name": "CVE-2023-47038",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47038"
},
{
"name": "CVE-2025-38363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38363"
},
{
"name": "CVE-2025-38702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38702"
},
{
"name": "CVE-2025-38319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38319"
},
{
"name": "CVE-2020-10878",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10878"
},
{
"name": "CVE-2022-0529",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0529"
},
{
"name": "CVE-2015-4782",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4782"
},
{
"name": "CVE-2025-38724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38724"
},
{
"name": "CVE-2022-2056",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2056"
},
{
"name": "CVE-2023-26966",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26966"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2025-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38457"
},
{
"name": "CVE-2025-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38582"
},
{
"name": "CVE-2025-37813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37813"
},
{
"name": "CVE-2025-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38543"
},
{
"name": "CVE-2025-38698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38698"
},
{
"name": "CVE-2025-38212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38212"
},
{
"name": "CVE-2025-40106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40106"
},
{
"name": "CVE-2017-3610",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3610"
},
{
"name": "CVE-2025-38298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38298"
},
{
"name": "CVE-2022-43552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43552"
},
{
"name": "CVE-2025-5915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5915"
},
{
"name": "CVE-2025-39739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39739"
},
{
"name": "CVE-2022-48065",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48065"
},
{
"name": "CVE-2025-38024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38024"
},
{
"name": "CVE-2025-38496",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38496"
},
{
"name": "CVE-2022-49063",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49063"
},
{
"name": "CVE-2025-5917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5917"
},
{
"name": "CVE-2025-38078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38078"
},
{
"name": "CVE-2022-47696",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-47696"
},
{
"name": "CVE-2025-38419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38419"
},
{
"name": "CVE-2024-45490",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45490"
},
{
"name": "CVE-2024-51744",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-51744"
},
{
"name": "CVE-2025-38533",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38533"
},
{
"name": "CVE-2021-22947",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22947"
},
{
"name": "CVE-2025-40205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40205"
},
{
"name": "CVE-2015-4788",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4788"
},
{
"name": "CVE-2025-38169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38169"
},
{
"name": "CVE-2025-37931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37931"
},
{
"name": "CVE-2025-38511",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38511"
},
{
"name": "CVE-2025-38537",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38537"
},
{
"name": "CVE-2025-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38546"
},
{
"name": "CVE-2025-38211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38211"
},
{
"name": "CVE-2025-6965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6965"
},
{
"name": "CVE-2023-28319",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28319"
},
{
"name": "CVE-2025-10966",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10966"
},
{
"name": "CVE-2021-22922",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22922"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2024-45491",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45491"
},
{
"name": "CVE-2025-50182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50182"
},
{
"name": "CVE-2025-47906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47906"
},
{
"name": "CVE-2020-2981",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2981"
},
{
"name": "CVE-2025-37887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37887"
},
{
"name": "CVE-2025-38077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38077"
},
{
"name": "CVE-2025-38251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38251"
},
{
"name": "CVE-2022-22576",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22576"
},
{
"name": "CVE-2025-37861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37861"
},
{
"name": "CVE-2025-38120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38120"
},
{
"name": "CVE-2025-38285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38285"
},
{
"name": "CVE-2025-39743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39743"
},
{
"name": "CVE-2025-39718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39718"
},
{
"name": "CVE-2025-37938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37938"
},
{
"name": "CVE-2025-38005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38005"
},
{
"name": "CVE-2025-38368",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38368"
},
{
"name": "CVE-2025-59375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59375"
},
{
"name": "CVE-2025-31133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31133"
},
{
"name": "CVE-2022-35205",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-35205"
},
{
"name": "CVE-2025-8194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8194"
},
{
"name": "CVE-2025-38161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38161"
},
{
"name": "CVE-2025-38331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38331"
},
{
"name": "CVE-2025-38354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38354"
},
{
"name": "CVE-2016-3418",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-3418"
},
{
"name": "CVE-2025-38712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38712"
},
{
"name": "CVE-2025-38732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38732"
},
{
"name": "CVE-2022-29824",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29824"
},
{
"name": "CVE-2025-39773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39773"
},
{
"name": "CVE-2024-11053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11053"
},
{
"name": "CVE-2025-38696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38696"
},
{
"name": "CVE-2024-7264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7264"
},
{
"name": "CVE-2025-38274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38274"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-64505",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64505"
},
{
"name": "CVE-2025-39885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39885"
},
{
"name": "CVE-2021-4214",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4214"
},
{
"name": "CVE-2025-50181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50181"
},
{
"name": "CVE-2015-2656",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2656"
},
{
"name": "CVE-2025-37874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37874"
},
{
"name": "CVE-2025-38115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38115"
},
{
"name": "CVE-2025-66382",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66382"
},
{
"name": "CVE-2025-38632",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38632"
},
{
"name": "CVE-2021-22946",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22946"
},
{
"name": "CVE-2023-0767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0767"
},
{
"name": "CVE-2025-37988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37988"
},
{
"name": "CVE-2025-1795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1795"
},
{
"name": "CVE-2025-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23158"
},
{
"name": "CVE-2017-3612",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3612"
},
{
"name": "CVE-2025-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23144"
},
{
"name": "CVE-2025-38153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38153"
},
{
"name": "CVE-2025-37969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37969"
},
{
"name": "CVE-2025-69421",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69421"
},
{
"name": "CVE-2025-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38548"
},
{
"name": "CVE-2025-37816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37816"
},
{
"name": "CVE-2025-37742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37742"
},
{
"name": "CVE-2025-4517",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4517"
},
{
"name": "CVE-2025-58188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58188"
},
{
"name": "CVE-2025-37765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37765"
},
{
"name": "CVE-2016-9843",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-9843"
},
{
"name": "CVE-2025-1178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1178"
},
{
"name": "CVE-2025-38395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38395"
},
{
"name": "CVE-2025-37921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37921"
},
{
"name": "CVE-2023-29499",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29499"
},
{
"name": "CVE-2025-38507",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38507"
},
{
"name": "CVE-2025-39989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39989"
},
{
"name": "CVE-2025-38337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38337"
},
{
"name": "CVE-2025-38014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38014"
},
{
"name": "CVE-2025-38258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38258"
},
{
"name": "CVE-2024-1013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1013"
},
{
"name": "CVE-2025-37828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37828"
},
{
"name": "CVE-2025-4674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4674"
},
{
"name": "CVE-2025-30258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30258"
},
{
"name": "CVE-2025-1176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1176"
},
{
"name": "CVE-2025-37769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37769"
},
{
"name": "CVE-2025-38465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38465"
},
{
"name": "CVE-2024-56406",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56406"
},
{
"name": "CVE-2025-38513",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38513"
},
{
"name": "CVE-2025-39970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39970"
},
{
"name": "CVE-2025-38086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38086"
},
{
"name": "CVE-2025-37935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37935"
},
{
"name": "CVE-2025-38396",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38396"
},
{
"name": "CVE-2025-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23161"
},
{
"name": "CVE-2025-38407",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38407"
},
{
"name": "CVE-2025-39994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39994"
},
{
"name": "CVE-2015-4784",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4784"
},
{
"name": "CVE-2025-12119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12119"
},
{
"name": "CVE-2023-4527",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4527"
},
{
"name": "CVE-2025-38493",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38493"
},
{
"name": "CVE-2025-37803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37803"
},
{
"name": "CVE-2025-38670",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38670"
},
{
"name": "CVE-2025-39732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39732"
},
{
"name": "CVE-2024-56433",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56433"
},
{
"name": "CVE-2025-37824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37824"
},
{
"name": "CVE-2023-34410",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34410"
},
{
"name": "CVE-2025-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38602"
},
{
"name": "CVE-2023-4156",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4156"
},
{
"name": "CVE-2014-8139",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-8139"
},
{
"name": "CVE-2025-47911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47911"
},
{
"name": "CVE-2022-29526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29526"
},
{
"name": "CVE-2025-38003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38003"
},
{
"name": "CVE-2025-38441",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38441"
},
{
"name": "CVE-2025-28162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-28162"
},
{
"name": "CVE-2025-38007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38007"
},
{
"name": "CVE-2025-37923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37923"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40220"
},
{
"name": "CVE-2022-2519",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2519"
},
{
"name": "CVE-2025-38142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38142"
},
{
"name": "CVE-2022-23990",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23990"
},
{
"name": "CVE-2022-49920",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49920"
},
{
"name": "CVE-2025-37739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37739"
},
{
"name": "CVE-2022-0530",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0530"
},
{
"name": "CVE-2025-13151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13151"
},
{
"name": "CVE-2025-38478",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38478"
},
{
"name": "CVE-2025-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38568"
},
{
"name": "CVE-2025-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38583"
},
{
"name": "CVE-2025-39788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39788"
},
{
"name": "CVE-2025-22058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22058"
},
{
"name": "CVE-2025-37831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37831"
},
{
"name": "CVE-2025-38499",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38499"
},
{
"name": "CVE-2025-4435",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4435"
},
{
"name": "CVE-2025-38269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38269"
},
{
"name": "CVE-2025-38079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38079"
},
{
"name": "CVE-2025-37940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37940"
},
{
"name": "CVE-2022-28391",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28391"
},
{
"name": "CVE-2021-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46828"
},
{
"name": "CVE-2023-2804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2804"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2025-6141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6141"
},
{
"name": "CVE-2025-40109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40109"
},
{
"name": "CVE-2024-13978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-13978"
},
{
"name": "CVE-2025-38735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38735"
},
{
"name": "CVE-2022-50247",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50247"
},
{
"name": "CVE-2025-40006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40006"
},
{
"name": "CVE-2025-12383",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12383"
},
{
"name": "CVE-2025-38652",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38652"
},
{
"name": "CVE-2025-38110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38110"
},
{
"name": "CVE-2025-38422",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38422"
},
{
"name": "CVE-2025-38402",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38402"
},
{
"name": "CVE-2021-3520",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3520"
},
{
"name": "CVE-2025-39698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39698"
},
{
"name": "CVE-2025-64506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64506"
},
{
"name": "CVE-2025-37915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37915"
},
{
"name": "CVE-2025-6020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6020"
},
{
"name": "CVE-2015-2626",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2626"
},
{
"name": "CVE-2025-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23146"
},
{
"name": "CVE-2022-48064",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48064"
},
{
"name": "CVE-2025-37903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37903"
},
{
"name": "CVE-2025-52881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52881"
},
{
"name": "CVE-2025-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23142"
},
{
"name": "CVE-2020-10029",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10029"
},
{
"name": "CVE-2025-7425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7425"
},
{
"name": "CVE-2022-36227",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36227"
},
{
"name": "CVE-2025-37738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37738"
},
{
"name": "CVE-2025-40011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40011"
},
{
"name": "CVE-2025-21883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21883"
},
{
"name": "CVE-2025-38303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38303"
},
{
"name": "CVE-2023-29469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29469"
},
{
"name": "CVE-2024-5535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5535"
},
{
"name": "CVE-2025-38074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38074"
},
{
"name": "CVE-2023-52355",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52355"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-38119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38119"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-38245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38245"
},
{
"name": "CVE-2025-40231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40231"
},
{
"name": "CVE-2021-36770",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36770"
},
{
"name": "CVE-2025-38324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38324"
},
{
"name": "CVE-2025-22868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22868"
},
{
"name": "CVE-2021-36976",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36976"
},
{
"name": "CVE-2025-38018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38018"
},
{
"name": "CVE-2023-3164",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3164"
},
{
"name": "CVE-2022-3597",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3597"
},
{
"name": "CVE-2023-27535",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27535"
},
{
"name": "CVE-2022-27775",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27775"
},
{
"name": "CVE-2024-12718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12718"
},
{
"name": "CVE-2025-37830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37830"
},
{
"name": "CVE-2018-25032",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-25032"
},
{
"name": "CVE-2025-3360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3360"
},
{
"name": "CVE-2025-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38614"
},
{
"name": "CVE-2025-37991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37991"
},
{
"name": "CVE-2026-22796",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22796"
},
{
"name": "CVE-2025-64720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64720"
},
{
"name": "CVE-2025-38425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38425"
},
{
"name": "CVE-2022-3970",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3970"
},
{
"name": "CVE-2025-9165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9165"
},
{
"name": "CVE-2023-30571",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30571"
},
{
"name": "CVE-2022-50249",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50249"
},
{
"name": "CVE-2025-61724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61724"
},
{
"name": "CVE-2025-37978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37978"
},
{
"name": "CVE-2025-37781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37781"
},
{
"name": "CVE-2024-5642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5642"
},
{
"name": "CVE-2024-3219",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3219"
},
{
"name": "CVE-2015-4781",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4781"
},
{
"name": "CVE-2025-38210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38210"
},
{
"name": "CVE-2025-38542",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38542"
},
{
"name": "CVE-2025-38664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38664"
},
{
"name": "CVE-2025-38344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38344"
},
{
"name": "CVE-2025-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23145"
},
{
"name": "CVE-2025-23143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23143"
},
{
"name": "CVE-2021-3999",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3999"
},
{
"name": "CVE-2023-53182",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53182"
},
{
"name": "CVE-2025-38322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38322"
},
{
"name": "CVE-2025-38088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38088"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2025-37823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37823"
},
{
"name": "CVE-2022-27774",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27774"
},
{
"name": "CVE-2025-38332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38332"
},
{
"name": "CVE-2025-38386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38386"
},
{
"name": "CVE-2025-61732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61732"
},
{
"name": "CVE-2017-3605",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3605"
},
{
"name": "CVE-2025-61723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61723"
},
{
"name": "CVE-2025-38385",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38385"
},
{
"name": "CVE-2022-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40303"
},
{
"name": "CVE-2025-11083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11083"
},
{
"name": "CVE-2025-37952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37952"
},
{
"name": "CVE-2023-45803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45803"
},
{
"name": "CVE-2024-6763",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6763"
},
{
"name": "CVE-2023-0801",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0801"
},
{
"name": "CVE-2025-38694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38694"
},
{
"name": "CVE-2025-37793",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37793"
},
{
"name": "CVE-2020-10543",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10543"
},
{
"name": "CVE-2025-1377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1377"
},
{
"name": "CVE-2025-37740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37740"
},
{
"name": "CVE-2025-38676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38676"
},
{
"name": "CVE-2025-38530",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38530"
},
{
"name": "CVE-2022-4645",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4645"
},
{
"name": "CVE-2025-38174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38174"
},
{
"name": "CVE-2025-8713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8713"
},
{
"name": "CVE-2025-37826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37826"
},
{
"name": "CVE-2025-37986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37986"
},
{
"name": "CVE-2025-37829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37829"
},
{
"name": "CVE-2025-46394",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46394"
},
{
"name": "CVE-2025-66471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66471"
},
{
"name": "CVE-2025-38409",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38409"
},
{
"name": "CVE-2025-6170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6170"
},
{
"name": "CVE-2022-3479",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3479"
},
{
"name": "CVE-2021-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35937"
},
{
"name": "CVE-2025-9900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9900"
},
{
"name": "CVE-2025-40183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40183"
},
{
"name": "CVE-2025-38019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38019"
},
{
"name": "CVE-2025-38729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38729"
},
{
"name": "CVE-2025-14017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14017"
},
{
"name": "CVE-2023-40745",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40745"
},
{
"name": "CVE-2026-21441",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21441"
},
{
"name": "CVE-2024-45337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45337"
},
{
"name": "CVE-2025-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23151"
},
{
"name": "CVE-2025-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38037"
},
{
"name": "CVE-2017-3609",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3609"
},
{
"name": "CVE-2025-39998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39998"
},
{
"name": "CVE-2014-9636",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9636"
},
{
"name": "CVE-2025-13836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13836"
},
{
"name": "CVE-2017-3611",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3611"
},
{
"name": "CVE-2022-2521",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2521"
},
{
"name": "CVE-2023-28321",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28321"
},
{
"name": "CVE-2025-37796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37796"
},
{
"name": "CVE-2025-37962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37962"
},
{
"name": "CVE-2026-1002",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1002"
},
{
"name": "CVE-2025-40134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40134"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2023-25435",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25435"
},
{
"name": "CVE-2025-37799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37799"
},
{
"name": "CVE-2022-29155",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29155"
},
{
"name": "CVE-2025-61725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61725"
},
{
"name": "CVE-2025-38593",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38593"
},
{
"name": "CVE-2026-25210",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25210"
},
{
"name": "CVE-2022-2309",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2309"
},
{
"name": "CVE-2025-39968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39968"
},
{
"name": "CVE-2023-33285",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-33285"
},
{
"name": "CVE-2024-52533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52533"
},
{
"name": "CVE-2025-38342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38342"
},
{
"name": "CVE-2025-65018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-65018"
},
{
"name": "CVE-2025-39795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39795"
},
{
"name": "CVE-2015-4777",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4777"
},
{
"name": "CVE-2025-37801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37801"
},
{
"name": "CVE-2025-7039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7039"
},
{
"name": "CVE-2025-38167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38167"
},
{
"name": "CVE-2025-37883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37883"
},
{
"name": "CVE-2025-37863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37863"
},
{
"name": "CVE-2023-0687",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0687"
},
{
"name": "CVE-2025-37901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37901"
},
{
"name": "CVE-2025-38687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38687"
},
{
"name": "CVE-2022-32221",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32221"
},
{
"name": "CVE-2025-37811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37811"
},
{
"name": "CVE-2022-37434",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-37434"
},
{
"name": "CVE-2025-38257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38257"
},
{
"name": "CVE-2022-29458",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29458"
},
{
"name": "CVE-2023-5156",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5156"
},
{
"name": "CVE-2025-22104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22104"
},
{
"name": "CVE-2025-37864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37864"
},
{
"name": "CVE-2021-32256",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32256"
},
{
"name": "CVE-2025-38307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38307"
},
{
"name": "CVE-2025-11081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11081"
},
{
"name": "CVE-2025-55163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55163"
},
{
"name": "CVE-2025-37916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37916"
},
{
"name": "CVE-2025-38111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38111"
},
{
"name": "CVE-2025-39986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39986"
},
{
"name": "CVE-2026-22184",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22184"
},
{
"name": "CVE-2025-37767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37767"
},
{
"name": "CVE-2025-5918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5918"
},
{
"name": "CVE-2025-39955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39955"
},
{
"name": "CVE-2025-66293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66293"
},
{
"name": "CVE-2017-3614",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3614"
},
{
"name": "CVE-2025-37989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37989"
},
{
"name": "CVE-2025-38529",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38529"
},
{
"name": "CVE-2025-38326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38326"
},
{
"name": "CVE-2025-38055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38055"
},
{
"name": "CVE-2025-12818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12818"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2025-32990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32990"
},
{
"name": "CVE-2025-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38384"
},
{
"name": "CVE-2025-38334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38334"
},
{
"name": "CVE-2025-38728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38728"
},
{
"name": "CVE-2025-38424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38424"
},
{
"name": "CVE-2025-38430",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38430"
},
{
"name": "CVE-2025-38715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38715"
},
{
"name": "CVE-2021-22897",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22897"
},
{
"name": "CVE-2025-39734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39734"
},
{
"name": "CVE-2025-38089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38089"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-38382",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38382"
},
{
"name": "CVE-2025-15366",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15366"
},
{
"name": "CVE-2023-2603",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2603"
},
{
"name": "CVE-2025-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38608"
},
{
"name": "CVE-2025-38650",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38650"
},
{
"name": "CVE-2025-4802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4802"
},
{
"name": "CVE-2025-39710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39710"
},
{
"name": "CVE-2025-40116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40116"
},
{
"name": "CVE-2025-68249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68249"
},
{
"name": "CVE-2026-0990",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0990"
},
{
"name": "CVE-2025-38124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38124"
},
{
"name": "CVE-2025-39934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39934"
},
{
"name": "CVE-2025-37925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37925"
},
{
"name": "CVE-2026-0865",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0865"
},
{
"name": "CVE-2024-9143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9143"
},
{
"name": "CVE-2023-0799",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0799"
},
{
"name": "CVE-2020-12723",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-12723"
},
{
"name": "CVE-2025-39683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39683"
},
{
"name": "CVE-2025-38420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38420"
},
{
"name": "CVE-2025-38071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38071"
},
{
"name": "CVE-2021-3521",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3521"
},
{
"name": "CVE-2025-40179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40179"
},
{
"name": "CVE-2025-37972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37972"
},
{
"name": "CVE-2025-38183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38183"
},
{
"name": "CVE-2025-40127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40127"
},
{
"name": "CVE-2025-37768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37768"
},
{
"name": "CVE-2025-39794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39794"
},
{
"name": "CVE-2025-38160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38160"
},
{
"name": "CVE-2024-33601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33601"
},
{
"name": "CVE-2025-32989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32989"
},
{
"name": "CVE-2022-48063",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48063"
},
{
"name": "CVE-2024-53589",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53589"
},
{
"name": "CVE-2025-37984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37984"
},
{
"name": "CVE-2025-38528",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38528"
},
{
"name": "CVE-2025-39996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39996"
},
{
"name": "CVE-2025-37856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37856"
},
{
"name": "CVE-2025-38107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38107"
},
{
"name": "CVE-2025-22874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22874"
},
{
"name": "CVE-2023-32181",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32181"
},
{
"name": "CVE-2025-38292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38292"
},
{
"name": "CVE-2025-40053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40053"
},
{
"name": "CVE-2025-38085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38085"
},
{
"name": "CVE-2026-24515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24515"
},
{
"name": "CVE-2025-38222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38222"
},
{
"name": "CVE-2025-38010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38010"
},
{
"name": "CVE-2025-38197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38197"
},
{
"name": "CVE-2025-39951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39951"
},
{
"name": "CVE-2025-38468",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38468"
},
{
"name": "CVE-2022-1271",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1271"
},
{
"name": "CVE-2025-40120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40120"
},
{
"name": "CVE-2024-28085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28085"
},
{
"name": "CVE-2025-11495",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11495"
},
{
"name": "CVE-2025-38688",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38688"
},
{
"name": "CVE-2025-38333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38333"
},
{
"name": "CVE-2019-9076",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-9076"
},
{
"name": "CVE-2025-37970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37970"
},
{
"name": "CVE-2025-55199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55199"
},
{
"name": "CVE-2025-21884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21884"
},
{
"name": "CVE-2025-37905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37905"
},
{
"name": "CVE-2025-38390",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38390"
},
{
"name": "CVE-2025-38013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38013"
},
{
"name": "CVE-2021-20205",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20205"
},
{
"name": "CVE-2025-38059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38059"
},
{
"name": "CVE-2025-5025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5025"
},
{
"name": "CVE-2025-38713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38713"
},
{
"name": "CVE-2025-37956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37956"
},
{
"name": "CVE-2025-40243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40243"
},
{
"name": "CVE-2025-38148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38148"
},
{
"name": "CVE-2025-38467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38467"
},
{
"name": "CVE-2024-34459",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34459"
},
{
"name": "CVE-2025-38117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38117"
},
{
"name": "CVE-2025-38094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38094"
},
{
"name": "CVE-2025-49795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49795"
},
{
"name": "CVE-2025-14104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14104"
},
{
"name": "CVE-2014-9913",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9913"
},
{
"name": "CVE-2025-38072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38072"
},
{
"name": "CVE-2024-37407",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37407"
},
{
"name": "CVE-2015-4775",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4775"
},
{
"name": "CVE-2025-37967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37967"
},
{
"name": "CVE-2025-38300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38300"
},
{
"name": "CVE-2016-0694",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0694"
},
{
"name": "CVE-2025-38289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38289"
},
{
"name": "CVE-2023-6228",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6228"
},
{
"name": "CVE-2021-46848",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46848"
},
{
"name": "CVE-2025-39782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39782"
},
{
"name": "CVE-2025-38075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38075"
},
{
"name": "CVE-2025-37885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37885"
},
{
"name": "CVE-2025-38697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38697"
},
{
"name": "CVE-2025-1376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1376"
},
{
"name": "CVE-2025-47912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47912"
},
{
"name": "CVE-2025-37949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37949"
},
{
"name": "CVE-2001-1269",
"url": "https://www.cve.org/CVERecord?id=CVE-2001-1269"
},
{
"name": "CVE-2025-38691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38691"
},
{
"name": "CVE-2025-38373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38373"
},
{
"name": "CVE-2025-11414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11414"
},
{
"name": "CVE-2025-38489",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38489"
},
{
"name": "CVE-2025-66861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66861"
},
{
"name": "CVE-2025-37957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37957"
},
{
"name": "CVE-2024-22365",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22365"
},
{
"name": "CVE-2025-38058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38058"
},
{
"name": "CVE-2025-38483",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38483"
},
{
"name": "CVE-2025-38369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38369"
},
{
"name": "CVE-2024-47535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47535"
},
{
"name": "CVE-2025-39759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39759"
},
{
"name": "CVE-2025-38639",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38639"
},
{
"name": "CVE-2025-38122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38122"
},
{
"name": "CVE-2025-38612",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38612"
},
{
"name": "CVE-2022-50250",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-50250"
},
{
"name": "CVE-2023-0795",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0795"
},
{
"name": "CVE-2025-68160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68160"
},
{
"name": "CVE-2015-2583",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2583"
},
{
"name": "CVE-2025-38173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38173"
},
{
"name": "CVE-2021-29390",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-29390"
},
{
"name": "CVE-2024-2236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2236"
},
{
"name": "CVE-2025-38143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38143"
},
{
"name": "CVE-2025-45768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-45768"
},
{
"name": "CVE-2025-38098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38098"
},
{
"name": "CVE-2025-38566",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38566"
},
{
"name": "CVE-2025-1365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1365"
},
{
"name": "CVE-2025-39721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39721"
},
{
"name": "CVE-2024-25062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25062"
},
{
"name": "CVE-2025-39760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39760"
},
{
"name": "CVE-2025-40118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40118"
},
{
"name": "CVE-2022-32205",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32205"
},
{
"name": "CVE-2025-38718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38718"
},
{
"name": "CVE-2023-27534",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27534"
},
{
"name": "CVE-2024-2398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2398"
},
{
"name": "CVE-2025-38392",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38392"
},
{
"name": "CVE-2025-60753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-60753"
},
{
"name": "CVE-2025-39673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39673"
},
{
"name": "CVE-2023-27536",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27536"
},
{
"name": "CVE-2025-52565",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52565"
},
{
"name": "CVE-2025-38259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38259"
},
{
"name": "CVE-2025-38663",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38663"
},
{
"name": "CVE-2015-4783",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4783"
},
{
"name": "CVE-2025-40021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40021"
},
{
"name": "CVE-2025-67735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-67735"
},
{
"name": "CVE-2025-38156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38156"
},
{
"name": "CVE-2015-4774",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4774"
},
{
"name": "CVE-2025-37951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37951"
},
{
"name": "CVE-2023-50495",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50495"
},
{
"name": "CVE-2025-37840",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37840"
},
{
"name": "CVE-2017-11164",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-11164"
},
{
"name": "CVE-2025-37947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37947"
},
{
"name": "CVE-2025-61728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61728"
},
{
"name": "CVE-2022-43551",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43551"
},
{
"name": "CVE-2025-68972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68972"
},
{
"name": "CVE-2025-26519",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-26519"
},
{
"name": "CVE-2025-38416",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38416"
},
{
"name": "CVE-2025-58186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58186"
},
{
"name": "CVE-2025-37846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37846"
},
{
"name": "CVE-2025-38722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38722"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2025-39800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39800"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-13034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13034"
},
{
"name": "CVE-2021-20284",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20284"
},
{
"name": "CVE-2025-8714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8714"
},
{
"name": "CVE-2025-38343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38343"
},
{
"name": "CVE-2023-27533",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27533"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2025-38202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38202"
},
{
"name": "CVE-2017-7500",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7500"
},
{
"name": "CVE-2025-9086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9086"
},
{
"name": "CVE-2025-40112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40112"
},
{
"name": "CVE-2025-22101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22101"
},
{
"name": "CVE-2021-32292",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32292"
},
{
"name": "CVE-2025-38374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38374"
},
{
"name": "CVE-2025-39703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39703"
},
{
"name": "CVE-2025-38194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38194"
},
{
"name": "CVE-2025-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38549"
},
{
"name": "CVE-2024-10041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10041"
},
{
"name": "CVE-2023-1972",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1972"
},
{
"name": "CVE-2025-8869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8869"
},
{
"name": "CVE-2025-58187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58187"
},
{
"name": "CVE-2022-34903",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34903"
},
{
"name": "CVE-2022-2953",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2953"
},
{
"name": "CVE-2025-38665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38665"
},
{
"name": "CVE-2024-20696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20696"
},
{
"name": "CVE-2025-38101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38101"
},
{
"name": "CVE-2023-32573",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32573"
},
{
"name": "CVE-2025-37982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37982"
},
{
"name": "CVE-2025-37992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37992"
},
{
"name": "CVE-2025-38577",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38577"
},
{
"name": "CVE-2025-38671",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38671"
},
{
"name": "CVE-2020-19726",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-19726"
},
{
"name": "CVE-2022-3219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3219"
},
{
"name": "CVE-2025-39971",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39971"
},
{
"name": "CVE-2025-38299",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38299"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-13601",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13601"
},
{
"name": "CVE-2025-12817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12817"
},
{
"name": "CVE-2025-38635",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38635"
},
{
"name": "CVE-2025-4673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4673"
},
{
"name": "CVE-2022-47010",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-47010"
},
{
"name": "CVE-2025-38704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38704"
},
{
"name": "CVE-2025-38348",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38348"
},
{
"name": "CVE-2020-22916",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-22916"
},
{
"name": "CVE-2025-38488",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38488"
},
{
"name": "CVE-2025-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38540"
},
{
"name": "CVE-2025-5916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5916"
},
{
"name": "CVE-2025-38040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38040"
},
{
"name": "CVE-2025-38265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38265"
},
{
"name": "CVE-2025-23149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23149"
},
{
"name": "CVE-2022-33070",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-33070"
},
{
"name": "CVE-2025-38403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38403"
},
{
"name": "CVE-2022-23308",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23308"
},
{
"name": "CVE-2025-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38552"
},
{
"name": "CVE-2025-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58056"
},
{
"name": "CVE-2025-37914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37914"
},
{
"name": "CVE-2025-22871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22871"
},
{
"name": "CVE-2025-10911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10911"
},
{
"name": "CVE-2025-32988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32988"
},
{
"name": "CVE-2022-28805",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28805"
},
{
"name": "CVE-2025-37873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37873"
},
{
"name": "CVE-2024-57360",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57360"
},
{
"name": "CVE-2025-37928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37928"
},
{
"name": "CVE-2017-3604",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3604"
},
{
"name": "CVE-2023-0804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0804"
},
{
"name": "CVE-2025-39766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39766"
},
{
"name": "CVE-2025-39801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39801"
},
{
"name": "CVE-2025-37922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37922"
},
{
"name": "CVE-2025-38146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38146"
},
{
"name": "CVE-2024-38828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38828"
},
{
"name": "CVE-2025-39724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39724"
},
{
"name": "CVE-2023-27538",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27538"
},
{
"name": "CVE-2025-39687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39687"
},
{
"name": "CVE-2025-37794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37794"
},
{
"name": "CVE-2023-4641",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4641"
},
{
"name": "CVE-2025-14524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14524"
},
{
"name": "CVE-2025-38510",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38510"
},
{
"name": "CVE-2025-27113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27113"
},
{
"name": "CVE-2025-38246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38246"
},
{
"name": "CVE-2025-39758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39758"
},
{
"name": "CVE-2025-39694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39694"
},
{
"name": "CVE-2025-38220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38220"
},
{
"name": "CVE-2025-38405",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38405"
},
{
"name": "CVE-2026-0915",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0915"
},
{
"name": "CVE-2025-15281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15281"
},
{
"name": "CVE-2025-38418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38418"
},
{
"name": "CVE-2025-38090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38090"
},
{
"name": "CVE-2022-23218",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23218"
},
{
"name": "CVE-2025-38429",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38429"
},
{
"name": "CVE-2022-25236",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25236"
},
{
"name": "CVE-2023-30775",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30775"
},
{
"name": "CVE-2025-38225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38225"
},
{
"name": "CVE-2025-47913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47913"
},
{
"name": "CVE-2025-38155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38155"
},
{
"name": "CVE-2023-0797",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0797"
},
{
"name": "CVE-2025-37977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37977"
},
{
"name": "CVE-2023-37369",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-37369"
},
{
"name": "CVE-2024-48615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-48615"
},
{
"name": "CVE-2025-38365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38365"
},
{
"name": "CVE-2025-38415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38415"
},
{
"name": "CVE-2024-55549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55549"
},
{
"name": "CVE-2025-38668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38668"
},
{
"name": "CVE-2025-37973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37973"
},
{
"name": "CVE-2025-68750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68750"
},
{
"name": "CVE-2025-38260",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38260"
},
{
"name": "CVE-2024-6119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6119"
},
{
"name": "CVE-2025-37827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37827"
},
{
"name": "CVE-2025-38721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38721"
},
{
"name": "CVE-2025-38244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38244"
},
{
"name": "CVE-2023-1916",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1916"
},
{
"name": "CVE-2025-38080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38080"
},
{
"name": "CVE-2025-40126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40126"
},
{
"name": "CVE-2025-39972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39972"
},
{
"name": "CVE-2025-37748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37748"
},
{
"name": "CVE-2025-38364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38364"
},
{
"name": "CVE-2025-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38615"
},
{
"name": "CVE-2025-58181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58181"
},
{
"name": "CVE-2025-40909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40909"
},
{
"name": "CVE-2023-25588",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25588"
},
{
"name": "CVE-2025-39684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39684"
},
{
"name": "CVE-2025-37836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37836"
},
{
"name": "CVE-2025-38526",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38526"
},
{
"name": "CVE-2017-3607",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3607"
},
{
"name": "CVE-2025-38472",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38472"
},
{
"name": "CVE-2022-2520",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2520"
},
{
"name": "CVE-2025-8959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8959"
},
{
"name": "CVE-2025-37944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37944"
},
{
"name": "CVE-2025-47914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47914"
},
{
"name": "CVE-2025-38506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38506"
},
{
"name": "CVE-2025-38703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38703"
},
{
"name": "CVE-2025-38494",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38494"
},
{
"name": "CVE-2025-39753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39753"
},
{
"name": "CVE-2025-69418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69418"
},
{
"name": "CVE-2025-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38604"
},
{
"name": "CVE-2025-38623",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38623"
},
{
"name": "CVE-2025-38193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38193"
},
{
"name": "CVE-2025-38400",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38400"
},
{
"name": "CVE-2025-4516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4516"
},
{
"name": "CVE-2025-38136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38136"
},
{
"name": "CVE-2025-66864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66864"
},
{
"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-2025-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38544"
},
{
"name": "CVE-2025-37771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37771"
},
{
"name": "CVE-2025-39797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39797"
},
{
"name": "CVE-2025-40200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40200"
},
{
"name": "CVE-2025-38236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38236"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2025-37975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37975"
},
{
"name": "CVE-2023-41175",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-41175"
},
{
"name": "CVE-2025-40124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40124"
},
{
"name": "CVE-2025-38347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38347"
},
{
"name": "CVE-2025-39776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39776"
},
{
"name": "CVE-2025-1150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1150"
},
{
"name": "CVE-2025-39880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39880"
},
{
"name": "CVE-2025-37998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37998"
},
{
"name": "CVE-2025-38198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38198"
},
{
"name": "CVE-2025-58189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58189"
},
{
"name": "CVE-2025-6021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6021"
},
{
"name": "CVE-2025-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23163"
},
{
"name": "CVE-2025-40094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40094"
},
{
"name": "CVE-2025-37968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37968"
},
{
"name": "CVE-2025-38376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38376"
},
{
"name": "CVE-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2022-26280",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26280"
},
{
"name": "CVE-2025-0665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0665"
},
{
"name": "CVE-2025-38437",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38437"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2024-4603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4603"
},
{
"name": "CVE-2025-38351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38351"
},
{
"name": "CVE-2025-38048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38048"
},
{
"name": "CVE-2025-25193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25193"
},
{
"name": "CVE-2024-8096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8096"
},
{
"name": "CVE-2012-0880",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-0880"
},
{
"name": "CVE-2023-3576",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3576"
},
{
"name": "CVE-2023-4806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4806"
},
{
"name": "CVE-2025-38683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38683"
},
{
"name": "CVE-2026-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21945"
},
{
"name": "CVE-2023-47039",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47039"
},
{
"name": "CVE-2025-39736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39736"
},
{
"name": "CVE-2025-37757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37757"
},
{
"name": "CVE-2018-9996",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-9996"
},
{
"name": "CVE-2023-31484",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31484"
},
{
"name": "CVE-2025-8225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8225"
},
{
"name": "CVE-2023-29383",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29383"
},
{
"name": "CVE-2022-32206",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32206"
},
{
"name": "CVE-2025-8224",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8224"
},
{
"name": "CVE-2024-50602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50602"
},
{
"name": "CVE-2015-7697",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7697"
},
{
"name": "CVE-2025-38009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38009"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2025-40215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40215"
},
{
"name": "CVE-2025-40111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40111"
},
{
"name": "CVE-2025-38081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38081"
},
{
"name": "CVE-2025-37809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37809"
},
{
"name": "CVE-2025-40068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40068"
},
{
"name": "CVE-2025-5245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5245"
},
{
"name": "CVE-2025-38185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38185"
},
{
"name": "CVE-2025-39691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39691"
},
{
"name": "CVE-2025-38406",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38406"
},
{
"name": "CVE-2021-35942",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35942"
},
{
"name": "CVE-2025-40042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40042"
},
{
"name": "CVE-2025-32415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32415"
},
{
"name": "CVE-2025-24855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24855"
},
{
"name": "CVE-2025-37817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37817"
},
{
"name": "CVE-2025-39890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39890"
},
{
"name": "CVE-2025-39742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39742"
},
{
"name": "CVE-2025-5889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5889"
},
{
"name": "CVE-2025-22102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22102"
},
{
"name": "CVE-2025-37987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37987"
},
{
"name": "CVE-2024-23337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23337"
},
{
"name": "CVE-2016-0689",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0689"
},
{
"name": "CVE-2025-37749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37749"
},
{
"name": "CVE-2026-22695",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22695"
},
{
"name": "CVE-2026-23490",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-23490"
},
{
"name": "CVE-2025-11966",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11966"
},
{
"name": "CVE-2024-36331",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36331"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2014-8140",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-8140"
},
{
"name": "CVE-2026-0992",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0992"
},
{
"name": "CVE-2025-38263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38263"
},
{
"name": "CVE-2022-47011",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-47011"
},
{
"name": "CVE-2025-38610",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38610"
},
{
"name": "CVE-2025-37772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37772"
},
{
"name": "CVE-2025-9230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9230"
},
{
"name": "CVE-2025-38214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38214"
},
{
"name": "CVE-2025-12194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12194"
},
{
"name": "CVE-2021-3549",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3549"
},
{
"name": "CVE-2025-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38560"
},
{
"name": "CVE-2025-37994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37994"
},
{
"name": "CVE-2025-38551",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38551"
},
{
"name": "CVE-2025-38701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38701"
},
{
"name": "CVE-2025-38218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38218"
},
{
"name": "CVE-2025-66564",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66564"
},
{
"name": "CVE-2025-38349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38349"
},
{
"name": "CVE-2025-5244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5244"
},
{
"name": "CVE-2021-37972",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37972"
},
{
"name": "CVE-2025-1352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1352"
},
{
"name": "CVE-2024-4741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4741"
},
{
"name": "CVE-2021-33574",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33574"
},
{
"name": "CVE-2018-1000035",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000035"
},
{
"name": "CVE-2025-39726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39726"
},
{
"name": "CVE-2023-4863",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4863"
},
{
"name": "CVE-2025-48924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48924"
},
{
"name": "CVE-2025-38393",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38393"
},
{
"name": "CVE-2024-26256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26256"
},
{
"name": "CVE-2021-3326",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3326"
},
{
"name": "CVE-2021-22926",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22926"
},
{
"name": "CVE-2025-32414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32414"
},
{
"name": "CVE-2025-37891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37891"
},
{
"name": "CVE-2025-38249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38249"
},
{
"name": "CVE-2025-38716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38716"
},
{
"name": "CVE-2025-39937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39937"
},
{
"name": "CVE-2025-37858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37858"
},
{
"name": "CVE-2023-40403",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40403"
},
{
"name": "CVE-2025-22013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22013"
},
{
"name": "CVE-2025-38154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38154"
},
{
"name": "CVE-2025-38469",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38469"
},
{
"name": "CVE-2025-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38581"
},
{
"name": "CVE-2021-30560",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-30560"
},
{
"name": "CVE-2025-1153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1153"
},
{
"name": "CVE-2025-62408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62408"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2026-2003",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2003"
},
{
"name": "CVE-2025-39790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39790"
},
{
"name": "CVE-2025-38389",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38389"
},
{
"name": "CVE-2025-38448",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38448"
},
{
"name": "CVE-2022-48281",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48281"
},
{
"name": "CVE-2021-35938",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35938"
},
{
"name": "CVE-2025-15079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15079"
},
{
"name": "CVE-2025-37780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37780"
},
{
"name": "CVE-2025-37995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37995"
},
{
"name": "CVE-2025-38680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38680"
},
{
"name": "CVE-2025-37754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37754"
},
{
"name": "CVE-2025-1632",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1632"
},
{
"name": "CVE-2025-11412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11412"
},
{
"name": "CVE-2025-38497",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38497"
},
{
"name": "CVE-2025-23156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23156"
},
{
"name": "CVE-2025-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23157"
},
{
"name": "CVE-2025-38684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38684"
},
{
"name": "CVE-2025-38165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38165"
},
{
"name": "CVE-2022-28321",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28321"
},
{
"name": "CVE-2025-39686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39686"
},
{
"name": "CVE-2025-39798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39798"
},
{
"name": "CVE-2025-38495",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38495"
},
{
"name": "CVE-2025-37808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37808"
},
{
"name": "CVE-2017-3606",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3606"
},
{
"name": "CVE-2025-38730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38730"
},
{
"name": "CVE-2025-38052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38052"
},
{
"name": "CVE-2025-38377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38377"
},
{
"name": "CVE-2024-3651",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3651"
},
{
"name": "CVE-2025-39747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39747"
},
{
"name": "CVE-2022-40090",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40090"
},
{
"name": "CVE-2025-68121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68121"
},
{
"name": "CVE-2023-25434",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25434"
},
{
"name": "CVE-2024-12243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12243"
},
{
"name": "CVE-2025-38516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38516"
},
{
"name": "CVE-2025-38462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38462"
},
{
"name": "CVE-2025-38428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38428"
},
{
"name": "CVE-2018-13410",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-13410"
},
{
"name": "CVE-2025-39714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39714"
},
{
"name": "CVE-2025-38262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38262"
},
{
"name": "CVE-2025-60876",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-60876"
},
{
"name": "CVE-2025-38138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38138"
},
{
"name": "CVE-2025-38035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38035"
},
{
"name": "CVE-2025-14819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14819"
},
{
"name": "CVE-2025-37759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37759"
},
{
"name": "CVE-2025-24928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24928"
},
{
"name": "CVE-2025-38414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38414"
},
{
"name": "CVE-2022-35206",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-35206"
},
{
"name": "CVE-2025-0395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0395"
},
{
"name": "CVE-2025-11065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11065"
},
{
"name": "CVE-2025-37933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37933"
},
{
"name": "CVE-2025-38310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38310"
},
{
"name": "CVE-2015-4786",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4786"
},
{
"name": "CVE-2025-37886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37886"
},
{
"name": "CVE-2022-38533",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38533"
},
{
"name": "CVE-2025-37963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37963"
},
{
"name": "CVE-2025-40297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40297"
},
{
"name": "CVE-2026-1484",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1484"
},
{
"name": "CVE-2022-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40304"
},
{
"name": "CVE-2025-38226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38226"
},
{
"name": "CVE-2025-4947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4947"
},
{
"name": "CVE-2025-39706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39706"
},
{
"name": "CVE-2025-40178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40178"
},
{
"name": "CVE-2023-4911",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4911"
},
{
"name": "CVE-2025-38443",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38443"
},
{
"name": "CVE-2025-38576",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38576"
},
{
"name": "CVE-2025-39869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39869"
},
{
"name": "CVE-2025-0725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0725"
},
{
"name": "CVE-2025-37800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37800"
},
{
"name": "CVE-2025-39985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39985"
},
{
"name": "CVE-2025-61726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61726"
},
{
"name": "CVE-2023-36660",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36660"
},
{
"name": "CVE-2025-37900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37900"
},
{
"name": "CVE-2025-7424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7424"
},
{
"name": "CVE-2025-1094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1094"
},
{
"name": "CVE-2023-25585",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25585"
},
{
"name": "CVE-2025-38439",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38439"
},
{
"name": "CVE-2025-37805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37805"
},
{
"name": "CVE-2021-22923",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22923"
},
{
"name": "CVE-2025-41254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41254"
},
{
"name": "CVE-2025-39719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39719"
},
{
"name": "CVE-2025-37990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37990"
},
{
"name": "CVE-2020-12762",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-12762"
},
{
"name": "CVE-2025-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38553"
},
{
"name": "CVE-2025-38190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38190"
},
{
"name": "CVE-2025-3198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3198"
},
{
"name": "CVE-2025-38180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38180"
},
{
"name": "CVE-2025-53864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53864"
},
{
"name": "CVE-2025-39738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39738"
},
{
"name": "CVE-2026-2007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2007"
},
{
"name": "CVE-2025-38145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38145"
},
{
"name": "CVE-2023-2953",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2953"
},
{
"name": "CVE-2024-4032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4032"
},
{
"name": "CVE-2025-37948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37948"
},
{
"name": "CVE-2021-27645",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-27645"
},
{
"name": "CVE-2025-38166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38166"
},
{
"name": "CVE-2025-37862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37862"
},
{
"name": "CVE-2025-38321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38321"
},
{
"name": "CVE-2024-28835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28835"
},
{
"name": "CVE-2025-39705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39705"
},
{
"name": "CVE-2025-37960",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37960"
},
{
"name": "CVE-2025-38045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38045"
},
{
"name": "CVE-2025-38051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38051"
},
{
"name": "CVE-2025-59419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59419"
},
{
"name": "CVE-2025-49796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49796"
},
{
"name": "CVE-2022-34526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34526"
},
{
"name": "CVE-2025-8058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8058"
},
{
"name": "CVE-2025-39713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39713"
},
{
"name": "CVE-2025-37763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37763"
},
{
"name": "CVE-2025-11839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11839"
},
{
"name": "CVE-2025-37954",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37954"
},
{
"name": "CVE-2024-8244",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8244"
},
{
"name": "CVE-2025-22128",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22128"
},
{
"name": "CVE-2026-1489",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1489"
},
{
"name": "CVE-2025-37839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37839"
},
{
"name": "CVE-2025-39744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39744"
},
{
"name": "CVE-2025-38277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38277"
},
{
"name": "CVE-2025-37913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37913"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38539"
},
{
"name": "CVE-2026-2004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2004"
},
{
"name": "CVE-2026-0672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0672"
},
{
"name": "CVE-2025-8732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8732"
},
{
"name": "CVE-2025-38044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38044"
},
{
"name": "CVE-2022-1586",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1586"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2026-0900",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0900"
},
{
"name": "CVE-2020-16599",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-16599"
},
{
"name": "CVE-2021-46822",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46822"
},
{
"name": "CVE-2022-45703",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45703"
},
{
"name": "CVE-2025-38200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38200"
},
{
"name": "CVE-2025-38480",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38480"
},
{
"name": "CVE-2025-38346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38346"
},
{
"name": "CVE-2025-30204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30204"
},
{
"name": "CVE-2025-37959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37959"
},
{
"name": "CVE-2025-38191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38191"
},
{
"name": "CVE-2025-39946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39946"
},
{
"name": "CVE-2025-38062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38062"
},
{
"name": "CVE-2025-38531",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38531"
},
{
"name": "CVE-2025-5914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5914"
},
{
"name": "CVE-2023-39804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39804"
},
{
"name": "CVE-2025-21919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21919"
},
{
"name": "CVE-2025-39693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39693"
},
{
"name": "CVE-2025-38503",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38503"
},
{
"name": "CVE-2025-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38630"
},
{
"name": "CVE-2025-38131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38131"
},
{
"name": "CVE-2023-2908",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2908"
},
{
"name": "CVE-2023-39615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39615"
},
{
"name": "CVE-2017-7501",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7501"
},
{
"name": "CVE-2022-47673",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-47673"
},
{
"name": "CVE-2023-31486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31486"
},
{
"name": "CVE-2025-39980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39980"
},
{
"name": "CVE-2021-20197",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20197"
},
{
"name": "CVE-2023-24056",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24056"
},
{
"name": "CVE-2026-0902",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0902"
},
{
"name": "CVE-2013-0340",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-0340"
},
{
"name": "CVE-2025-37851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37851"
},
{
"name": "CVE-2025-38481",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38481"
},
{
"name": "CVE-2025-38585",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38585"
},
{
"name": "CVE-2023-32611",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32611"
},
{
"name": "CVE-2024-38816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38816"
},
{
"name": "CVE-2026-22717",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22717"
},
{
"name": "CVE-2024-34397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34397"
},
{
"name": "CVE-2025-38320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38320"
},
{
"name": "CVE-2025-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53057"
},
{
"name": "CVE-2025-1151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1151"
},
{
"name": "CVE-2025-38625",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38625"
},
{
"name": "CVE-2025-38164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38164"
},
{
"name": "CVE-2025-8177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8177"
},
{
"name": "CVE-2025-29480",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29480"
},
{
"name": "CVE-2025-40346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40346"
},
{
"name": "CVE-2025-38264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38264"
},
{
"name": "CVE-2023-1999",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1999"
},
{
"name": "CVE-2020-27618",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27618"
},
{
"name": "CVE-2025-39676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39676"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2023-0800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0800"
},
{
"name": "CVE-2025-7546",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7546"
},
{
"name": "CVE-2025-38280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38280"
},
{
"name": "CVE-2023-5388",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5388"
},
{
"name": "CVE-2025-1148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1148"
},
{
"name": "CVE-2025-37788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37788"
},
{
"name": "CVE-2025-38427",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38427"
},
{
"name": "CVE-2025-38084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38084"
},
{
"name": "CVE-2022-23219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23219"
},
{
"name": "CVE-2015-2640",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2640"
},
{
"name": "CVE-2025-37879",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37879"
},
{
"name": "CVE-2025-38217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38217"
},
{
"name": "CVE-2023-5752",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5752"
},
{
"name": "CVE-2025-40030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40030"
},
{
"name": "CVE-2025-40244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40244"
},
{
"name": "CVE-2025-66862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66862"
},
{
"name": "CVE-2025-37881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37881"
},
{
"name": "CVE-2025-39995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39995"
},
{
"name": "CVE-2025-38103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38103"
},
{
"name": "CVE-2025-38514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38514"
},
{
"name": "CVE-2025-39783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39783"
},
{
"name": "CVE-2025-39715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39715"
},
{
"name": "CVE-2025-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38569"
},
{
"name": "CVE-2025-38255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38255"
},
{
"name": "CVE-2025-38512",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38512"
},
{
"name": "CVE-2023-1579",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1579"
},
{
"name": "CVE-2025-68119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68119"
},
{
"name": "CVE-2025-38622",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38622"
},
{
"name": "CVE-2021-4217",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4217"
},
{
"name": "CVE-2023-32643",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32643"
},
{
"name": "CVE-2025-37909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37909"
},
{
"name": "CVE-2025-38700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38700"
},
{
"name": "CVE-2021-43396",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43396"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2025-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53066"
},
{
"name": "CVE-2025-22873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22873"
},
{
"name": "CVE-2025-38532",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38532"
},
{
"name": "CVE-2024-2961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2961"
},
{
"name": "CVE-2025-39712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39712"
},
{
"name": "CVE-2024-12133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12133"
},
{
"name": "CVE-2025-37812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37812"
},
{
"name": "CVE-2025-39707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39707"
},
{
"name": "CVE-2021-22945",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-22945"
},
{
"name": "CVE-2025-37875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37875"
},
{
"name": "CVE-2025-38410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38410"
},
{
"name": "CVE-2025-39907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39907"
},
{
"name": "CVE-2023-42366",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-42366"
},
{
"name": "CVE-2025-39781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39781"
},
{
"name": "CVE-2025-0167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0167"
},
{
"name": "CVE-2026-25547",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25547"
},
{
"name": "CVE-2025-38640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38640"
},
{
"name": "CVE-2023-38197",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38197"
},
{
"name": "CVE-2025-38476",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38476"
},
{
"name": "CVE-2025-69420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69420"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2025-64702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-64702"
},
{
"name": "CVE-2025-47273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47273"
},
{
"name": "CVE-2025-40140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40140"
},
{
"name": "CVE-2025-38020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38020"
},
{
"name": "CVE-2025-15224",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15224"
},
{
"name": "CVE-2025-40223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40223"
},
{
"name": "CVE-2025-38572",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38572"
},
{
"name": "CVE-2025-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23140"
},
{
"name": "CVE-2025-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23150"
},
{
"name": "CVE-2025-38460",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38460"
},
{
"name": "CVE-2025-38182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38182"
},
{
"name": "CVE-2025-38550",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38550"
},
{
"name": "CVE-2024-53114",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53114"
},
{
"name": "CVE-2025-38275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38275"
},
{
"name": "CVE-2022-48303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48303"
},
{
"name": "CVE-2025-38345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38345"
},
{
"name": "CVE-2024-37371",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37371"
},
{
"name": "CVE-2023-38545",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38545"
},
{
"name": "CVE-2021-43618",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43618"
},
{
"name": "CVE-2026-0989",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0989"
},
{
"name": "CVE-2025-38170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38170"
},
{
"name": "CVE-2025-39711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39711"
},
{
"name": "CVE-2025-22115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22115"
},
{
"name": "CVE-2025-22120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22120"
},
{
"name": "CVE-2025-61729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61729"
},
{
"name": "CVE-2025-38535",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38535"
},
{
"name": "CVE-2025-38231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38231"
},
{
"name": "CVE-2022-26488",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26488"
},
{
"name": "CVE-2025-37854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37854"
},
{
"name": "CVE-2025-11494",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11494"
},
{
"name": "CVE-2024-6345",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6345"
},
{
"name": "CVE-2025-39873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39873"
},
{
"name": "CVE-2018-18384",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-18384"
},
{
"name": "CVE-2025-38473",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38473"
},
{
"name": "CVE-2025-38113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38113"
},
{
"name": "CVE-2020-11023",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-11023"
},
{
"name": "CVE-2025-38714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38714"
},
{
"name": "CVE-2023-32665",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32665"
},
{
"name": "CVE-2025-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23148"
},
{
"name": "CVE-2025-38361",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38361"
},
{
"name": "CVE-2025-38470",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38470"
},
{
"name": "CVE-2023-23916",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23916"
},
{
"name": "CVE-2025-38181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38181"
},
{
"name": "CVE-2025-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38391"
},
{
"name": "CVE-2025-38248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38248"
},
{
"name": "CVE-2025-66418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66418"
},
{
"name": "CVE-2025-40351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40351"
},
{
"name": "CVE-2022-3570",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3570"
},
{
"name": "CVE-2016-9844",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-9844"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23147"
},
{
"name": "CVE-2024-8088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8088"
},
{
"name": "CVE-2025-48734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48734"
},
{
"name": "CVE-2025-39752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39752"
},
{
"name": "CVE-2026-25646",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25646"
}
],
"initial_release_date": "2026-02-26T00:00:00",
"last_revision_date": "2026-02-26T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0218",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-02-26T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits VMware. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer un d\u00e9ni de service \u00e0 distance, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et un contournement de la politique de s\u00e9curit\u00e9.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits VMware",
"vendor_advisories": [
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37096",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37096"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37092",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37092"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37102",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37102"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37078",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37078"
},
{
"published_at": "2026-02-26",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37109",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37109"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37087",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37087"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37090",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37090"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37077",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37077"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37098",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37098"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37079",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37079"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37101",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37101"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37104",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37104"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37080",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37080"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37097",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37097"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37083",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37083"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37086",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37086"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37082",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37082"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37100",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37100"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37099",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37099"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37081",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37081"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37089",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37089"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37076",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37076"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37088",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37088"
},
{
"published_at": "2026-02-26",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36986",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36986"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-27",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37103"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37084",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37084"
},
{
"published_at": "2026-02-26",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37110",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37110"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37093",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37093"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37085",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37085"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37095",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37095"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 37094",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/37094"
}
]
}
CERTFR-2026-AVI-0227
Vulnerability from certfr_avis - Published: 2026-02-27 - Updated: 2026-02-27
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).
None| 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.10",
"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": null,
"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-40296",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40296"
},
{
"name": "CVE-2025-40225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40225"
},
{
"name": "CVE-2025-40166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40166"
},
{
"name": "CVE-2025-40273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40273"
},
{
"name": "CVE-2025-40064",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40064"
},
{
"name": "CVE-2025-38490",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38490"
},
{
"name": "CVE-2025-37850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37850"
},
{
"name": "CVE-2025-38485",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38485"
},
{
"name": "CVE-2025-22026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22026"
},
{
"name": "CVE-2025-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38579"
},
{
"name": "CVE-2025-68196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68196"
},
{
"name": "CVE-2025-37761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37761"
},
{
"name": "CVE-2025-37865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37865"
},
{
"name": "CVE-2025-38328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38328"
},
{
"name": "CVE-2025-40156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40156"
},
{
"name": "CVE-2025-38711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38711"
},
{
"name": "CVE-2025-38487",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38487"
},
{
"name": "CVE-2025-40137",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40137"
},
{
"name": "CVE-2025-37775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37775"
},
{
"name": "CVE-2025-38335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38335"
},
{
"name": "CVE-2025-38304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38304"
},
{
"name": "CVE-2025-37892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37892"
},
{
"name": "CVE-2025-38100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38100"
},
{
"name": "CVE-2025-37859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37859"
},
{
"name": "CVE-2025-40002",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40002"
},
{
"name": "CVE-2025-40057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40057"
},
{
"name": "CVE-2025-38043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38043"
},
{
"name": "CVE-2025-38471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38471"
},
{
"name": "CVE-2025-38520",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38520"
},
{
"name": "CVE-2025-37792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37792"
},
{
"name": "CVE-2025-68240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68240"
},
{
"name": "CVE-2025-38108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38108"
},
{
"name": "CVE-2025-38230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38230"
},
{
"name": "CVE-2025-38229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38229"
},
{
"name": "CVE-2025-40055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40055"
},
{
"name": "CVE-2025-38158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38158"
},
{
"name": "CVE-2025-37872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37872"
},
{
"name": "CVE-2025-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38588"
},
{
"name": "CVE-2025-40314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40314"
},
{
"name": "CVE-2025-40029",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40029"
},
{
"name": "CVE-2025-40037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40037"
},
{
"name": "CVE-2025-38279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38279"
},
{
"name": "CVE-2025-38561",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38561"
},
{
"name": "CVE-2025-38574",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38574"
},
{
"name": "CVE-2025-40306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40306"
},
{
"name": "CVE-2025-68210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68210"
},
{
"name": "CVE-2025-40239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40239"
},
{
"name": "CVE-2025-40147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40147"
},
{
"name": "CVE-2025-40048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40048"
},
{
"name": "CVE-2025-38147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38147"
},
{
"name": "CVE-2025-23155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23155"
},
{
"name": "CVE-2025-38286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38286"
},
{
"name": "CVE-2025-40219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40219"
},
{
"name": "CVE-2025-39757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39757"
},
{
"name": "CVE-2025-68200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68200"
},
{
"name": "CVE-2025-38501",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38501"
},
{
"name": "CVE-2025-38474",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38474"
},
{
"name": "CVE-2025-37979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37979"
},
{
"name": "CVE-2025-40043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40043"
},
{
"name": "CVE-2025-68176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68176"
},
{
"name": "CVE-2025-37777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37777"
},
{
"name": "CVE-2025-39772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39772"
},
{
"name": "CVE-2025-68199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68199"
},
{
"name": "CVE-2025-37936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37936"
},
{
"name": "CVE-2025-68204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68204"
},
{
"name": "CVE-2025-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38601"
},
{
"name": "CVE-2025-37766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37766"
},
{
"name": "CVE-2025-38104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38104"
},
{
"name": "CVE-2025-37844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37844"
},
{
"name": "CVE-2025-21931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21931"
},
{
"name": "CVE-2025-37871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37871"
},
{
"name": "CVE-2025-37778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37778"
},
{
"name": "CVE-2025-39716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39716"
},
{
"name": "CVE-2025-39702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39702"
},
{
"name": "CVE-2025-38515",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38515"
},
{
"name": "CVE-2025-38645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38645"
},
{
"name": "CVE-2025-38163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38163"
},
{
"name": "CVE-2025-22126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22126"
},
{
"name": "CVE-2025-38444",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38444"
},
{
"name": "CVE-2025-38109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38109"
},
{
"name": "CVE-2025-39779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39779"
},
{
"name": "CVE-2025-37755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37755"
},
{
"name": "CVE-2025-39685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39685"
},
{
"name": "CVE-2025-38660",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38660"
},
{
"name": "CVE-2025-39761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39761"
},
{
"name": "CVE-2025-68246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68246"
},
{
"name": "CVE-2025-40287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40287"
},
{
"name": "CVE-2025-39720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39720"
},
{
"name": "CVE-2025-38624",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38624"
},
{
"name": "CVE-2025-40100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40100"
},
{
"name": "CVE-2025-40285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40285"
},
{
"name": "CVE-2025-38388",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38388"
},
{
"name": "CVE-2025-38157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38157"
},
{
"name": "CVE-2025-40063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40063"
},
{
"name": "CVE-2025-37790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37790"
},
{
"name": "CVE-2025-40208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40208"
},
{
"name": "CVE-2025-39746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39746"
},
{
"name": "CVE-2025-38323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38323"
},
{
"name": "CVE-2025-40019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40019"
},
{
"name": "CVE-2025-40039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40039"
},
{
"name": "CVE-2025-38208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38208"
},
{
"name": "CVE-2025-40240",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40240"
},
{
"name": "CVE-2025-38219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38219"
},
{
"name": "CVE-2025-39889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39889"
},
{
"name": "CVE-2025-38099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38099"
},
{
"name": "CVE-2025-38524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38524"
},
{
"name": "CVE-2025-38466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38466"
},
{
"name": "CVE-2025-40117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40117"
},
{
"name": "CVE-2025-37758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37758"
},
{
"name": "CVE-2025-40081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40081"
},
{
"name": "CVE-2025-38087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38087"
},
{
"name": "CVE-2025-38039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38039"
},
{
"name": "CVE-2025-40153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40153"
},
{
"name": "CVE-2025-40103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40103"
},
{
"name": "CVE-2025-40294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40294"
},
{
"name": "CVE-2025-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38595"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2025-40356",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40356"
},
{
"name": "CVE-2025-40121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40121"
},
{
"name": "CVE-2025-40312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40312"
},
{
"name": "CVE-2025-40204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40204"
},
{
"name": "CVE-2025-37852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37852"
},
{
"name": "CVE-2025-37841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37841"
},
{
"name": "CVE-2025-40171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40171"
},
{
"name": "CVE-2025-37918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37918"
},
{
"name": "CVE-2025-37917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37917"
},
{
"name": "CVE-2025-38290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38290"
},
{
"name": "CVE-2025-68243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68243"
},
{
"name": "CVE-2025-38063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38063"
},
{
"name": "CVE-2025-37770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37770"
},
{
"name": "CVE-2025-37773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37773"
},
{
"name": "CVE-2025-68175",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68175"
},
{
"name": "CVE-2025-40221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40221"
},
{
"name": "CVE-2025-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38578"
},
{
"name": "CVE-2025-40139",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40139"
},
{
"name": "CVE-2025-40056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40056"
},
{
"name": "CVE-2025-38675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38675"
},
{
"name": "CVE-2025-38646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38646"
},
{
"name": "CVE-2025-38491",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38491"
},
{
"name": "CVE-2025-38708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38708"
},
{
"name": "CVE-2025-37961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37961"
},
{
"name": "CVE-2025-68248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68248"
},
{
"name": "CVE-2025-40125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40125"
},
{
"name": "CVE-2025-40350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40350"
},
{
"name": "CVE-2025-40309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40309"
},
{
"name": "CVE-2025-38313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38313"
},
{
"name": "CVE-2025-38336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38336"
},
{
"name": "CVE-2025-40349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40349"
},
{
"name": "CVE-2025-40052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40052"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2025-40343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40343"
},
{
"name": "CVE-2025-38644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38644"
},
{
"name": "CVE-2025-38692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38692"
},
{
"name": "CVE-2025-38061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38061"
},
{
"name": "CVE-2025-68173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68173"
},
{
"name": "CVE-2025-37983",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37983"
},
{
"name": "CVE-2025-38127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38127"
},
{
"name": "CVE-2025-38375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38375"
},
{
"name": "CVE-2025-37784",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37784"
},
{
"name": "CVE-2025-39701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39701"
},
{
"name": "CVE-2025-40308",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40308"
},
{
"name": "CVE-2025-40187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40187"
},
{
"name": "CVE-2025-37920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37920"
},
{
"name": "CVE-2025-40315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40315"
},
{
"name": "CVE-2025-37815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37815"
},
{
"name": "CVE-2025-38686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38686"
},
{
"name": "CVE-2025-37819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37819"
},
{
"name": "CVE-2025-40092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40092"
},
{
"name": "CVE-2025-40298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40298"
},
{
"name": "CVE-2025-40355",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40355"
},
{
"name": "CVE-2025-38609",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38609"
},
{
"name": "CVE-2025-68186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68186"
},
{
"name": "CVE-2025-40054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40054"
},
{
"name": "CVE-2025-68184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68184"
},
{
"name": "CVE-2024-36357",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36357"
},
{
"name": "CVE-2025-38463",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38463"
},
{
"name": "CVE-2025-40115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40115"
},
{
"name": "CVE-2025-38112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38112"
},
{
"name": "CVE-2025-38521",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38521"
},
{
"name": "CVE-2025-38023",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38023"
},
{
"name": "CVE-2025-39709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39709"
},
{
"name": "CVE-2025-38282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38282"
},
{
"name": "CVE-2025-39689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39689"
},
{
"name": "CVE-2025-38215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38215"
},
{
"name": "CVE-2025-39787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39787"
},
{
"name": "CVE-2025-37943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37943"
},
{
"name": "CVE-2025-37745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37745"
},
{
"name": "CVE-2025-40058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40058"
},
{
"name": "CVE-2025-39731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39731"
},
{
"name": "CVE-2025-38734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38734"
},
{
"name": "CVE-2025-38653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38653"
},
{
"name": "CVE-2025-38571",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38571"
},
{
"name": "CVE-2025-37789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37789"
},
{
"name": "CVE-2025-40347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40347"
},
{
"name": "CVE-2025-38695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38695"
},
{
"name": "CVE-2025-38004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38004"
},
{
"name": "CVE-2025-39749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39749"
},
{
"name": "CVE-2025-40198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40198"
},
{
"name": "CVE-2025-68310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68310"
},
{
"name": "CVE-2025-68179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68179"
},
{
"name": "CVE-2025-40145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40145"
},
{
"name": "CVE-2025-38387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38387"
},
{
"name": "CVE-2025-68169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68169"
},
{
"name": "CVE-2025-38362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38362"
},
{
"name": "CVE-2025-40173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40173"
},
{
"name": "CVE-2025-68316",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68316"
},
{
"name": "CVE-2025-68321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68321"
},
{
"name": "CVE-2025-37924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37924"
},
{
"name": "CVE-2025-40004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40004"
},
{
"name": "CVE-2025-38371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38371"
},
{
"name": "CVE-2025-38445",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38445"
},
{
"name": "CVE-2025-38456",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38456"
},
{
"name": "CVE-2025-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38538"
},
{
"name": "CVE-2025-37867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37867"
},
{
"name": "CVE-2025-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23160"
},
{
"name": "CVE-2025-40311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40311"
},
{
"name": "CVE-2025-38295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38295"
},
{
"name": "CVE-2025-38461",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38461"
},
{
"name": "CVE-2025-37857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37857"
},
{
"name": "CVE-2025-37842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37842"
},
{
"name": "CVE-2025-40237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40237"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2025-39681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39681"
},
{
"name": "CVE-2025-38060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38060"
},
{
"name": "CVE-2025-40167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40167"
},
{
"name": "CVE-2025-38159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38159"
},
{
"name": "CVE-2025-38066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38066"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2025-37744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37744"
},
{
"name": "CVE-2025-38705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38705"
},
{
"name": "CVE-2025-40194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40194"
},
{
"name": "CVE-2025-38706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38706"
},
{
"name": "CVE-2025-40333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40333"
},
{
"name": "CVE-2025-38305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38305"
},
{
"name": "CVE-2025-37884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37884"
},
{
"name": "CVE-2025-38067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38067"
},
{
"name": "CVE-2025-39750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39750"
},
{
"name": "CVE-2025-38699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38699"
},
{
"name": "CVE-2025-37927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37927"
},
{
"name": "CVE-2025-38707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38707"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2025-37897",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37897"
},
{
"name": "CVE-2025-40256",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40256"
},
{
"name": "CVE-2025-37911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37911"
},
{
"name": "CVE-2025-40245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40245"
},
{
"name": "CVE-2025-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38587"
},
{
"name": "CVE-2025-37869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37869"
},
{
"name": "CVE-2025-39692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39692"
},
{
"name": "CVE-2025-40360",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40360"
},
{
"name": "CVE-2025-40332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40332"
},
{
"name": "CVE-2025-40082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40082"
},
{
"name": "CVE-2025-38068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38068"
},
{
"name": "CVE-2025-38436",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38436"
},
{
"name": "CVE-2025-37930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37930"
},
{
"name": "CVE-2025-40104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40104"
},
{
"name": "CVE-2025-38401",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38401"
},
{
"name": "CVE-2025-38677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38677"
},
{
"name": "CVE-2025-38097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38097"
},
{
"name": "CVE-2025-37810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37810"
},
{
"name": "CVE-2025-38253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38253"
},
{
"name": "CVE-2025-40097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40097"
},
{
"name": "CVE-2025-38123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38123"
},
{
"name": "CVE-2025-38338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38338"
},
{
"name": "CVE-2025-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38555"
},
{
"name": "CVE-2025-38239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38239"
},
{
"name": "CVE-2025-40001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40001"
},
{
"name": "CVE-2025-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38590"
},
{
"name": "CVE-2025-38027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38027"
},
{
"name": "CVE-2025-38102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38102"
},
{
"name": "CVE-2025-40035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40035"
},
{
"name": "CVE-2025-68187",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68187"
},
{
"name": "CVE-2025-38283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38283"
},
{
"name": "CVE-2025-40322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40322"
},
{
"name": "CVE-2025-68209",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68209"
},
{
"name": "CVE-2025-40045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40045"
},
{
"name": "CVE-2025-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23159"
},
{
"name": "CVE-2025-38455",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38455"
},
{
"name": "CVE-2025-40313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40313"
},
{
"name": "CVE-2025-40089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40089"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2025-38015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38015"
},
{
"name": "CVE-2025-39675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39675"
},
{
"name": "CVE-2025-39679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39679"
},
{
"name": "CVE-2025-38527",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38527"
},
{
"name": "CVE-2025-38449",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38449"
},
{
"name": "CVE-2025-40233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40233"
},
{
"name": "CVE-2025-40172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40172"
},
{
"name": "CVE-2025-37853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37853"
},
{
"name": "CVE-2025-38126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38126"
},
{
"name": "CVE-2025-38149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38149"
},
{
"name": "CVE-2025-39763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39763"
},
{
"name": "CVE-2025-38399",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38399"
},
{
"name": "CVE-2025-38065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38065"
},
{
"name": "CVE-2025-38693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38693"
},
{
"name": "CVE-2025-38679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38679"
},
{
"name": "CVE-2025-38459",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38459"
},
{
"name": "CVE-2025-40188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40188"
},
{
"name": "CVE-2025-40271",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40271"
},
{
"name": "CVE-2025-40291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40291"
},
{
"name": "CVE-2025-38685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38685"
},
{
"name": "CVE-2025-40359",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40359"
},
{
"name": "CVE-2025-38412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38412"
},
{
"name": "CVE-2025-38031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38031"
},
{
"name": "CVE-2025-40186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40186"
},
{
"name": "CVE-2025-38293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38293"
},
{
"name": "CVE-2025-40073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40073"
},
{
"name": "CVE-2025-38648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38648"
},
{
"name": "CVE-2025-38278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38278"
},
{
"name": "CVE-2025-37764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37764"
},
{
"name": "CVE-2025-38184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38184"
},
{
"name": "CVE-2025-37741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37741"
},
{
"name": "CVE-2025-38053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38053"
},
{
"name": "CVE-2025-40242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40242"
},
{
"name": "CVE-2025-37822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37822"
},
{
"name": "CVE-2025-37912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37912"
},
{
"name": "CVE-2025-38482",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38482"
},
{
"name": "CVE-2025-37820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37820"
},
{
"name": "CVE-2025-68198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68198"
},
{
"name": "CVE-2025-37985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37985"
},
{
"name": "CVE-2025-68314",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68314"
},
{
"name": "CVE-2025-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38634"
},
{
"name": "CVE-2025-40212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40212"
},
{
"name": "CVE-2025-37787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37787"
},
{
"name": "CVE-2025-38008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38008"
},
{
"name": "CVE-2025-38458",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38458"
},
{
"name": "CVE-2025-39730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39730"
},
{
"name": "CVE-2025-38011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38011"
},
{
"name": "CVE-2025-68190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68190"
},
{
"name": "CVE-2025-38034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38034"
},
{
"name": "CVE-2025-40086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40086"
},
{
"name": "CVE-2025-68242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68242"
},
{
"name": "CVE-2025-38135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38135"
},
{
"name": "CVE-2025-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38619"
},
{
"name": "CVE-2025-40169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40169"
},
{
"name": "CVE-2025-38312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38312"
},
{
"name": "CVE-2025-38095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38095"
},
{
"name": "CVE-2025-37878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37878"
},
{
"name": "CVE-2025-39737",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39737"
},
{
"name": "CVE-2025-38464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38464"
},
{
"name": "CVE-2025-40049",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40049"
},
{
"name": "CVE-2025-68322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68322"
},
{
"name": "CVE-2025-38363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38363"
},
{
"name": "CVE-2025-38702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38702"
},
{
"name": "CVE-2025-38319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38319"
},
{
"name": "CVE-2025-40238",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40238"
},
{
"name": "CVE-2025-38724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38724"
},
{
"name": "CVE-2025-68205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68205"
},
{
"name": "CVE-2025-40277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40277"
},
{
"name": "CVE-2025-40070",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40070"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2025-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38457"
},
{
"name": "CVE-2025-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38582"
},
{
"name": "CVE-2025-37813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37813"
},
{
"name": "CVE-2025-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38543"
},
{
"name": "CVE-2025-38698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38698"
},
{
"name": "CVE-2025-38212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38212"
},
{
"name": "CVE-2025-40106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40106"
},
{
"name": "CVE-2025-68174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68174"
},
{
"name": "CVE-2025-38298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38298"
},
{
"name": "CVE-2025-40272",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40272"
},
{
"name": "CVE-2025-39739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39739"
},
{
"name": "CVE-2025-38024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38024"
},
{
"name": "CVE-2025-40047",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40047"
},
{
"name": "CVE-2025-38496",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38496"
},
{
"name": "CVE-2025-38078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38078"
},
{
"name": "CVE-2025-38419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38419"
},
{
"name": "CVE-2025-40136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40136"
},
{
"name": "CVE-2025-38533",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38533"
},
{
"name": "CVE-2025-40344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40344"
},
{
"name": "CVE-2025-40205",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40205"
},
{
"name": "CVE-2025-40354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40354"
},
{
"name": "CVE-2025-38169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38169"
},
{
"name": "CVE-2025-37931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37931"
},
{
"name": "CVE-2025-38511",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38511"
},
{
"name": "CVE-2025-38537",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38537"
},
{
"name": "CVE-2025-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38546"
},
{
"name": "CVE-2025-38211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38211"
},
{
"name": "CVE-2025-40033",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40033"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-40122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40122"
},
{
"name": "CVE-2025-68188",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68188"
},
{
"name": "CVE-2025-40269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40269"
},
{
"name": "CVE-2025-37887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37887"
},
{
"name": "CVE-2025-38077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38077"
},
{
"name": "CVE-2025-38251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38251"
},
{
"name": "CVE-2025-37861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37861"
},
{
"name": "CVE-2025-68319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68319"
},
{
"name": "CVE-2025-40119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40119"
},
{
"name": "CVE-2025-38120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38120"
},
{
"name": "CVE-2025-38285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38285"
},
{
"name": "CVE-2025-39743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39743"
},
{
"name": "CVE-2025-39718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39718"
},
{
"name": "CVE-2025-37938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37938"
},
{
"name": "CVE-2025-38005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38005"
},
{
"name": "CVE-2025-38368",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38368"
},
{
"name": "CVE-2025-40075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40075"
},
{
"name": "CVE-2025-38161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38161"
},
{
"name": "CVE-2025-38331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38331"
},
{
"name": "CVE-2025-38354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38354"
},
{
"name": "CVE-2025-40138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40138"
},
{
"name": "CVE-2025-38712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38712"
},
{
"name": "CVE-2025-38732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38732"
},
{
"name": "CVE-2025-39773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39773"
},
{
"name": "CVE-2025-38696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38696"
},
{
"name": "CVE-2025-40143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40143"
},
{
"name": "CVE-2025-68189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68189"
},
{
"name": "CVE-2025-38274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38274"
},
{
"name": "CVE-2025-40076",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40076"
},
{
"name": "CVE-2025-68180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68180"
},
{
"name": "CVE-2025-37874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37874"
},
{
"name": "CVE-2025-38115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38115"
},
{
"name": "CVE-2025-38632",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38632"
},
{
"name": "CVE-2025-37988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37988"
},
{
"name": "CVE-2025-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23158"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23144"
},
{
"name": "CVE-2025-38153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38153"
},
{
"name": "CVE-2025-37969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37969"
},
{
"name": "CVE-2025-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38548"
},
{
"name": "CVE-2025-37816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37816"
},
{
"name": "CVE-2025-37899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37899"
},
{
"name": "CVE-2025-40362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40362"
},
{
"name": "CVE-2025-37742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37742"
},
{
"name": "CVE-2025-68201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68201"
},
{
"name": "CVE-2025-40289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40289"
},
{
"name": "CVE-2025-37765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37765"
},
{
"name": "CVE-2025-38395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38395"
},
{
"name": "CVE-2025-37921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37921"
},
{
"name": "CVE-2025-38507",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38507"
},
{
"name": "CVE-2025-40230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40230"
},
{
"name": "CVE-2025-39989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39989"
},
{
"name": "CVE-2025-38337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38337"
},
{
"name": "CVE-2025-38014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38014"
},
{
"name": "CVE-2025-38258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38258"
},
{
"name": "CVE-2025-37828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37828"
},
{
"name": "CVE-2025-37769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37769"
},
{
"name": "CVE-2025-38465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38465"
},
{
"name": "CVE-2025-38513",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38513"
},
{
"name": "CVE-2025-40292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40292"
},
{
"name": "CVE-2025-38086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38086"
},
{
"name": "CVE-2025-68181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68181"
},
{
"name": "CVE-2025-37935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37935"
},
{
"name": "CVE-2025-40032",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40032"
},
{
"name": "CVE-2025-38396",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38396"
},
{
"name": "CVE-2025-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23161"
},
{
"name": "CVE-2025-38407",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38407"
},
{
"name": "CVE-2025-38493",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38493"
},
{
"name": "CVE-2025-37803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37803"
},
{
"name": "CVE-2025-40228",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40228"
},
{
"name": "CVE-2025-40150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40150"
},
{
"name": "CVE-2025-38670",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38670"
},
{
"name": "CVE-2025-39732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39732"
},
{
"name": "CVE-2025-37824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37824"
},
{
"name": "CVE-2025-40274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40274"
},
{
"name": "CVE-2025-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38602"
},
{
"name": "CVE-2025-38003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38003"
},
{
"name": "CVE-2025-38441",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38441"
},
{
"name": "CVE-2025-40206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40206"
},
{
"name": "CVE-2025-40218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40218"
},
{
"name": "CVE-2025-38007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38007"
},
{
"name": "CVE-2025-37923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37923"
},
{
"name": "CVE-2025-40088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40088"
},
{
"name": "CVE-2025-40220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40220"
},
{
"name": "CVE-2025-38142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38142"
},
{
"name": "CVE-2025-37739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37739"
},
{
"name": "CVE-2025-38478",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38478"
},
{
"name": "CVE-2025-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38568"
},
{
"name": "CVE-2025-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38583"
},
{
"name": "CVE-2025-39788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39788"
},
{
"name": "CVE-2025-37831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37831"
},
{
"name": "CVE-2025-38499",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38499"
},
{
"name": "CVE-2025-68312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68312"
},
{
"name": "CVE-2025-40062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40062"
},
{
"name": "CVE-2025-68194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68194"
},
{
"name": "CVE-2025-38269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38269"
},
{
"name": "CVE-2025-38079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38079"
},
{
"name": "CVE-2025-37940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37940"
},
{
"name": "CVE-2025-40336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40336"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2025-40067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40067"
},
{
"name": "CVE-2025-40101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40101"
},
{
"name": "CVE-2025-38735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38735"
},
{
"name": "CVE-2025-68251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68251"
},
{
"name": "CVE-2025-38652",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38652"
},
{
"name": "CVE-2025-38110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38110"
},
{
"name": "CVE-2025-38422",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38422"
},
{
"name": "CVE-2025-38402",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38402"
},
{
"name": "CVE-2025-39698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39698"
},
{
"name": "CVE-2025-40038",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40038"
},
{
"name": "CVE-2025-37915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37915"
},
{
"name": "CVE-2025-68183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68183"
},
{
"name": "CVE-2025-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23146"
},
{
"name": "CVE-2025-37903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37903"
},
{
"name": "CVE-2025-40353",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40353"
},
{
"name": "CVE-2025-40222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40222"
},
{
"name": "CVE-2025-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23142"
},
{
"name": "CVE-2025-37738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37738"
},
{
"name": "CVE-2025-38303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38303"
},
{
"name": "CVE-2025-38074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38074"
},
{
"name": "CVE-2025-40085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40085"
},
{
"name": "CVE-2025-38119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38119"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-38245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38245"
},
{
"name": "CVE-2025-40184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40184"
},
{
"name": "CVE-2025-68244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68244"
},
{
"name": "CVE-2025-40231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40231"
},
{
"name": "CVE-2025-38324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38324"
},
{
"name": "CVE-2025-40278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40278"
},
{
"name": "CVE-2025-38018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38018"
},
{
"name": "CVE-2025-40176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40176"
},
{
"name": "CVE-2025-40342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40342"
},
{
"name": "CVE-2025-37830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37830"
},
{
"name": "CVE-2025-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38614"
},
{
"name": "CVE-2025-37991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37991"
},
{
"name": "CVE-2025-38425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38425"
},
{
"name": "CVE-2025-40210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40210"
},
{
"name": "CVE-2025-37978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37978"
},
{
"name": "CVE-2025-37781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37781"
},
{
"name": "CVE-2025-38210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38210"
},
{
"name": "CVE-2025-38542",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38542"
},
{
"name": "CVE-2025-38664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38664"
},
{
"name": "CVE-2025-38344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38344"
},
{
"name": "CVE-2025-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23145"
},
{
"name": "CVE-2025-38322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38322"
},
{
"name": "CVE-2025-38088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38088"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2025-40193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40193"
},
{
"name": "CVE-2025-37823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37823"
},
{
"name": "CVE-2025-38332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38332"
},
{
"name": "CVE-2025-40148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40148"
},
{
"name": "CVE-2025-40326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40326"
},
{
"name": "CVE-2025-38386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38386"
},
{
"name": "CVE-2025-40279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40279"
},
{
"name": "CVE-2025-38385",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38385"
},
{
"name": "CVE-2025-40201",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40201"
},
{
"name": "CVE-2024-53217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53217"
},
{
"name": "CVE-2025-37952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37952"
},
{
"name": "CVE-2025-38694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38694"
},
{
"name": "CVE-2025-37793",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37793"
},
{
"name": "CVE-2025-40084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40084"
},
{
"name": "CVE-2025-68311",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68311"
},
{
"name": "CVE-2025-37740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37740"
},
{
"name": "CVE-2025-38676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38676"
},
{
"name": "CVE-2025-38530",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38530"
},
{
"name": "CVE-2025-38174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38174"
},
{
"name": "CVE-2025-37826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37826"
},
{
"name": "CVE-2025-37986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37986"
},
{
"name": "CVE-2025-37829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37829"
},
{
"name": "CVE-2025-68320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68320"
},
{
"name": "CVE-2025-40341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40341"
},
{
"name": "CVE-2025-38409",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38409"
},
{
"name": "CVE-2025-40199",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40199"
},
{
"name": "CVE-2025-40183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40183"
},
{
"name": "CVE-2025-38019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38019"
},
{
"name": "CVE-2025-38729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38729"
},
{
"name": "CVE-2025-68172",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68172"
},
{
"name": "CVE-2025-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23151"
},
{
"name": "CVE-2025-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38037"
},
{
"name": "CVE-2025-40338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40338"
},
{
"name": "CVE-2025-40195",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40195"
},
{
"name": "CVE-2025-37796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37796"
},
{
"name": "CVE-2025-37962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37962"
},
{
"name": "CVE-2025-40134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40134"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2025-37799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37799"
},
{
"name": "CVE-2025-38593",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38593"
},
{
"name": "CVE-2025-38342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38342"
},
{
"name": "CVE-2025-39795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39795"
},
{
"name": "CVE-2025-37801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37801"
},
{
"name": "CVE-2025-38167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38167"
},
{
"name": "CVE-2025-37883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37883"
},
{
"name": "CVE-2025-40302",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40302"
},
{
"name": "CVE-2025-37863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37863"
},
{
"name": "CVE-2025-37901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37901"
},
{
"name": "CVE-2025-38687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38687"
},
{
"name": "CVE-2025-40358",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40358"
},
{
"name": "CVE-2025-37811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37811"
},
{
"name": "CVE-2025-40165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40165"
},
{
"name": "CVE-2025-38257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38257"
},
{
"name": "CVE-2025-68318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68318"
},
{
"name": "CVE-2025-37864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37864"
},
{
"name": "CVE-2025-38307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38307"
},
{
"name": "CVE-2025-40161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40161"
},
{
"name": "CVE-2025-40357",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40357"
},
{
"name": "CVE-2025-40328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40328"
},
{
"name": "CVE-2025-37916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37916"
},
{
"name": "CVE-2025-40340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40340"
},
{
"name": "CVE-2025-38111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38111"
},
{
"name": "CVE-2025-37767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37767"
},
{
"name": "CVE-2025-40283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40283"
},
{
"name": "CVE-2025-40324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40324"
},
{
"name": "CVE-2025-37989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37989"
},
{
"name": "CVE-2025-38529",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38529"
},
{
"name": "CVE-2025-40131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40131"
},
{
"name": "CVE-2025-40146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40146"
},
{
"name": "CVE-2025-38326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38326"
},
{
"name": "CVE-2025-40177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40177"
},
{
"name": "CVE-2025-38055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38055"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2025-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38384"
},
{
"name": "CVE-2025-38334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38334"
},
{
"name": "CVE-2025-38728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38728"
},
{
"name": "CVE-2025-38424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38424"
},
{
"name": "CVE-2025-38430",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38430"
},
{
"name": "CVE-2025-38715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38715"
},
{
"name": "CVE-2025-39734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39734"
},
{
"name": "CVE-2025-38089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38089"
},
{
"name": "CVE-2025-40226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40226"
},
{
"name": "CVE-2025-40078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40078"
},
{
"name": "CVE-2025-38382",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38382"
},
{
"name": "CVE-2025-40074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40074"
},
{
"name": "CVE-2025-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38608"
},
{
"name": "CVE-2025-40321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40321"
},
{
"name": "CVE-2025-38650",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38650"
},
{
"name": "CVE-2025-40069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40069"
},
{
"name": "CVE-2025-39710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39710"
},
{
"name": "CVE-2025-40116",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40116"
},
{
"name": "CVE-2025-68249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68249"
},
{
"name": "CVE-2025-38124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38124"
},
{
"name": "CVE-2025-37925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37925"
},
{
"name": "CVE-2025-40158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40158"
},
{
"name": "CVE-2025-39683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39683"
},
{
"name": "CVE-2025-38420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38420"
},
{
"name": "CVE-2025-38071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38071"
},
{
"name": "CVE-2025-40327",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40327"
},
{
"name": "CVE-2025-40130",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40130"
},
{
"name": "CVE-2025-40179",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40179"
},
{
"name": "CVE-2025-37972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37972"
},
{
"name": "CVE-2025-38183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38183"
},
{
"name": "CVE-2025-40127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40127"
},
{
"name": "CVE-2025-37768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37768"
},
{
"name": "CVE-2025-40282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40282"
},
{
"name": "CVE-2025-39794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39794"
},
{
"name": "CVE-2025-38160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38160"
},
{
"name": "CVE-2025-37984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37984"
},
{
"name": "CVE-2025-38528",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38528"
},
{
"name": "CVE-2025-40168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40168"
},
{
"name": "CVE-2025-37856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37856"
},
{
"name": "CVE-2025-38107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38107"
},
{
"name": "CVE-2025-38292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38292"
},
{
"name": "CVE-2025-40053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40053"
},
{
"name": "CVE-2025-38085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38085"
},
{
"name": "CVE-2025-38222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38222"
},
{
"name": "CVE-2025-38010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38010"
},
{
"name": "CVE-2025-38197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38197"
},
{
"name": "CVE-2025-38468",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38468"
},
{
"name": "CVE-2025-40120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40120"
},
{
"name": "CVE-2025-40185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40185"
},
{
"name": "CVE-2025-38688",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38688"
},
{
"name": "CVE-2025-38333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38333"
},
{
"name": "CVE-2025-40295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40295"
},
{
"name": "CVE-2025-68192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68192"
},
{
"name": "CVE-2025-37970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37970"
},
{
"name": "CVE-2025-21884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21884"
},
{
"name": "CVE-2025-37905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37905"
},
{
"name": "CVE-2025-38390",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38390"
},
{
"name": "CVE-2025-38013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38013"
},
{
"name": "CVE-2025-40098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40098"
},
{
"name": "CVE-2025-38059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38059"
},
{
"name": "CVE-2025-38713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38713"
},
{
"name": "CVE-2025-37956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37956"
},
{
"name": "CVE-2025-40243",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40243"
},
{
"name": "CVE-2025-40196",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40196"
},
{
"name": "CVE-2025-38148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38148"
},
{
"name": "CVE-2025-40129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40129"
},
{
"name": "CVE-2025-38467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38467"
},
{
"name": "CVE-2025-38117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38117"
},
{
"name": "CVE-2025-38094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38094"
},
{
"name": "CVE-2025-68171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68171"
},
{
"name": "CVE-2025-38072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38072"
},
{
"name": "CVE-2025-37967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37967"
},
{
"name": "CVE-2025-40301",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40301"
},
{
"name": "CVE-2025-38300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38300"
},
{
"name": "CVE-2025-40040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40040"
},
{
"name": "CVE-2025-38289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38289"
},
{
"name": "CVE-2025-39782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39782"
},
{
"name": "CVE-2025-68207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68207"
},
{
"name": "CVE-2025-40066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40066"
},
{
"name": "CVE-2025-38075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38075"
},
{
"name": "CVE-2025-37885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37885"
},
{
"name": "CVE-2025-38697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38697"
},
{
"name": "CVE-2025-37949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37949"
},
{
"name": "CVE-2025-68167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68167"
},
{
"name": "CVE-2025-38691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38691"
},
{
"name": "CVE-2025-40207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40207"
},
{
"name": "CVE-2025-38373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38373"
},
{
"name": "CVE-2025-38489",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38489"
},
{
"name": "CVE-2025-40095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40095"
},
{
"name": "CVE-2025-37957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37957"
},
{
"name": "CVE-2025-38058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38058"
},
{
"name": "CVE-2025-38483",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38483"
},
{
"name": "CVE-2025-38369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38369"
},
{
"name": "CVE-2025-39759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39759"
},
{
"name": "CVE-2025-38639",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38639"
},
{
"name": "CVE-2025-38122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38122"
},
{
"name": "CVE-2025-38612",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38612"
},
{
"name": "CVE-2025-40299",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40299"
},
{
"name": "CVE-2025-38173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38173"
},
{
"name": "CVE-2025-40286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40286"
},
{
"name": "CVE-2025-38143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38143"
},
{
"name": "CVE-2025-38098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38098"
},
{
"name": "CVE-2025-40091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40091"
},
{
"name": "CVE-2025-40318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40318"
},
{
"name": "CVE-2025-38566",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38566"
},
{
"name": "CVE-2025-39721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39721"
},
{
"name": "CVE-2025-68241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68241"
},
{
"name": "CVE-2025-39760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39760"
},
{
"name": "CVE-2025-40118",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40118"
},
{
"name": "CVE-2025-38718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38718"
},
{
"name": "CVE-2025-38392",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38392"
},
{
"name": "CVE-2025-39673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39673"
},
{
"name": "CVE-2025-38259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38259"
},
{
"name": "CVE-2025-38663",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38663"
},
{
"name": "CVE-2025-40135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40135"
},
{
"name": "CVE-2025-38156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38156"
},
{
"name": "CVE-2025-37951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37951"
},
{
"name": "CVE-2025-37840",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37840"
},
{
"name": "CVE-2025-68253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68253"
},
{
"name": "CVE-2025-68734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68734"
},
{
"name": "CVE-2025-37947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37947"
},
{
"name": "CVE-2025-38416",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38416"
},
{
"name": "CVE-2025-37846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37846"
},
{
"name": "CVE-2025-38722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38722"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2025-39800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39800"
},
{
"name": "CVE-2025-40044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40044"
},
{
"name": "CVE-2025-38343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38343"
},
{
"name": "CVE-2025-40105",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40105"
},
{
"name": "CVE-2025-38202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38202"
},
{
"name": "CVE-2025-40050",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40050"
},
{
"name": "CVE-2025-40072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40072"
},
{
"name": "CVE-2025-40112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40112"
},
{
"name": "CVE-2025-40079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40079"
},
{
"name": "CVE-2025-22101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22101"
},
{
"name": "CVE-2025-38374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38374"
},
{
"name": "CVE-2025-39703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39703"
},
{
"name": "CVE-2025-38194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38194"
},
{
"name": "CVE-2025-68182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68182"
},
{
"name": "CVE-2025-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38549"
},
{
"name": "CVE-2025-40310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40310"
},
{
"name": "CVE-2025-38665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38665"
},
{
"name": "CVE-2025-38101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38101"
},
{
"name": "CVE-2025-37982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37982"
},
{
"name": "CVE-2025-37992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37992"
},
{
"name": "CVE-2025-38577",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38577"
},
{
"name": "CVE-2025-38671",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38671"
},
{
"name": "CVE-2025-68317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68317"
},
{
"name": "CVE-2025-38299",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38299"
},
{
"name": "CVE-2025-40154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40154"
},
{
"name": "CVE-2025-40331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40331"
},
{
"name": "CVE-2025-38635",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38635"
},
{
"name": "CVE-2025-38704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38704"
},
{
"name": "CVE-2025-38348",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38348"
},
{
"name": "CVE-2025-40270",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40270"
},
{
"name": "CVE-2025-40191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40191"
},
{
"name": "CVE-2025-38488",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38488"
},
{
"name": "CVE-2025-40189",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40189"
},
{
"name": "CVE-2025-40093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40093"
},
{
"name": "CVE-2025-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38540"
},
{
"name": "CVE-2025-38040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38040"
},
{
"name": "CVE-2025-38265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38265"
},
{
"name": "CVE-2025-23149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23149"
},
{
"name": "CVE-2025-38403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38403"
},
{
"name": "CVE-2025-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38552"
},
{
"name": "CVE-2025-40335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40335"
},
{
"name": "CVE-2025-40149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40149"
},
{
"name": "CVE-2025-37914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37914"
},
{
"name": "CVE-2025-40164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40164"
},
{
"name": "CVE-2025-37873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37873"
},
{
"name": "CVE-2025-37928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37928"
},
{
"name": "CVE-2025-40267",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40267"
},
{
"name": "CVE-2025-40235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40235"
},
{
"name": "CVE-2025-39766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39766"
},
{
"name": "CVE-2025-39801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39801"
},
{
"name": "CVE-2025-37922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37922"
},
{
"name": "CVE-2025-38146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38146"
},
{
"name": "CVE-2025-68208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68208"
},
{
"name": "CVE-2025-39724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39724"
},
{
"name": "CVE-2025-39687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39687"
},
{
"name": "CVE-2025-37794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37794"
},
{
"name": "CVE-2025-38510",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38510"
},
{
"name": "CVE-2025-38246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38246"
},
{
"name": "CVE-2025-39758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39758"
},
{
"name": "CVE-2025-39694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39694"
},
{
"name": "CVE-2025-38220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38220"
},
{
"name": "CVE-2025-38405",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38405"
},
{
"name": "CVE-2025-38418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38418"
},
{
"name": "CVE-2025-40352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40352"
},
{
"name": "CVE-2025-38090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38090"
},
{
"name": "CVE-2025-38429",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38429"
},
{
"name": "CVE-2025-38225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38225"
},
{
"name": "CVE-2025-22037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22037"
},
{
"name": "CVE-2025-40280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40280"
},
{
"name": "CVE-2025-38155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38155"
},
{
"name": "CVE-2025-40099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40099"
},
{
"name": "CVE-2025-37977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37977"
},
{
"name": "CVE-2025-38365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38365"
},
{
"name": "CVE-2025-38415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38415"
},
{
"name": "CVE-2025-40031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40031"
},
{
"name": "CVE-2025-40180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40180"
},
{
"name": "CVE-2025-40293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40293"
},
{
"name": "CVE-2025-38668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38668"
},
{
"name": "CVE-2025-37973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37973"
},
{
"name": "CVE-2025-40330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40330"
},
{
"name": "CVE-2025-68750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68750"
},
{
"name": "CVE-2025-38260",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38260"
},
{
"name": "CVE-2025-37827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37827"
},
{
"name": "CVE-2025-38721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38721"
},
{
"name": "CVE-2025-38244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38244"
},
{
"name": "CVE-2025-38080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38080"
},
{
"name": "CVE-2025-40126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40126"
},
{
"name": "CVE-2025-37748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37748"
},
{
"name": "CVE-2025-38364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38364"
},
{
"name": "CVE-2025-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38615"
},
{
"name": "CVE-2025-39684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39684"
},
{
"name": "CVE-2025-37836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37836"
},
{
"name": "CVE-2025-38526",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38526"
},
{
"name": "CVE-2025-38472",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38472"
},
{
"name": "CVE-2025-37944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37944"
},
{
"name": "CVE-2025-38506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38506"
},
{
"name": "CVE-2025-40320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40320"
},
{
"name": "CVE-2025-38703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38703"
},
{
"name": "CVE-2025-38494",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38494"
},
{
"name": "CVE-2025-39753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39753"
},
{
"name": "CVE-2025-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38604"
},
{
"name": "CVE-2025-40203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40203"
},
{
"name": "CVE-2025-38623",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38623"
},
{
"name": "CVE-2025-38193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38193"
},
{
"name": "CVE-2025-38400",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38400"
},
{
"name": "CVE-2025-38136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38136"
},
{
"name": "CVE-2025-40192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40192"
},
{
"name": "CVE-2025-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38544"
},
{
"name": "CVE-2025-37771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37771"
},
{
"name": "CVE-2025-39797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39797"
},
{
"name": "CVE-2025-40200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40200"
},
{
"name": "CVE-2025-38236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38236"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2025-37975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37975"
},
{
"name": "CVE-2025-40124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40124"
},
{
"name": "CVE-2025-38347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38347"
},
{
"name": "CVE-2025-39776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39776"
},
{
"name": "CVE-2025-37998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37998"
},
{
"name": "CVE-2025-38198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38198"
},
{
"name": "CVE-2025-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23163"
},
{
"name": "CVE-2025-40094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40094"
},
{
"name": "CVE-2025-37968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37968"
},
{
"name": "CVE-2025-38376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38376"
},
{
"name": "CVE-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2025-40102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40102"
},
{
"name": "CVE-2025-40170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40170"
},
{
"name": "CVE-2025-38437",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38437"
},
{
"name": "CVE-2025-40160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40160"
},
{
"name": "CVE-2025-40284",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40284"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-40209",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40209"
},
{
"name": "CVE-2025-40077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40077"
},
{
"name": "CVE-2025-38351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38351"
},
{
"name": "CVE-2025-38048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38048"
},
{
"name": "CVE-2025-40071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40071"
},
{
"name": "CVE-2025-38683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38683"
},
{
"name": "CVE-2025-40113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40113"
},
{
"name": "CVE-2025-39736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39736"
},
{
"name": "CVE-2025-40234",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40234"
},
{
"name": "CVE-2025-37757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37757"
},
{
"name": "CVE-2025-68247",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68247"
},
{
"name": "CVE-2025-40305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40305"
},
{
"name": "CVE-2025-40080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40080"
},
{
"name": "CVE-2025-38009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38009"
},
{
"name": "CVE-2025-40215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40215"
},
{
"name": "CVE-2025-40307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40307"
},
{
"name": "CVE-2025-40111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40111"
},
{
"name": "CVE-2025-38081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38081"
},
{
"name": "CVE-2025-37809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37809"
},
{
"name": "CVE-2024-36350",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36350"
},
{
"name": "CVE-2025-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40211"
},
{
"name": "CVE-2025-40068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40068"
},
{
"name": "CVE-2025-38185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38185"
},
{
"name": "CVE-2025-39691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39691"
},
{
"name": "CVE-2025-38406",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38406"
},
{
"name": "CVE-2025-68315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68315"
},
{
"name": "CVE-2025-40163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40163"
},
{
"name": "CVE-2025-40042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40042"
},
{
"name": "CVE-2025-37817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37817"
},
{
"name": "CVE-2025-40155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40155"
},
{
"name": "CVE-2025-39890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39890"
},
{
"name": "CVE-2025-39742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39742"
},
{
"name": "CVE-2025-40217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40217"
},
{
"name": "CVE-2025-22102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22102"
},
{
"name": "CVE-2025-37987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37987"
},
{
"name": "CVE-2025-37749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37749"
},
{
"name": "CVE-2024-36331",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36331"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2025-40133",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40133"
},
{
"name": "CVE-2025-38263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38263"
},
{
"name": "CVE-2025-38610",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38610"
},
{
"name": "CVE-2025-37772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37772"
},
{
"name": "CVE-2025-38214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38214"
},
{
"name": "CVE-2025-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38560"
},
{
"name": "CVE-2025-37994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37994"
},
{
"name": "CVE-2025-38551",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38551"
},
{
"name": "CVE-2025-38701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38701"
},
{
"name": "CVE-2025-38218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38218"
},
{
"name": "CVE-2025-40329",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40329"
},
{
"name": "CVE-2025-38349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38349"
},
{
"name": "CVE-2025-39726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39726"
},
{
"name": "CVE-2025-38393",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38393"
},
{
"name": "CVE-2025-37891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37891"
},
{
"name": "CVE-2025-38249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38249"
},
{
"name": "CVE-2025-38716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38716"
},
{
"name": "CVE-2025-37858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37858"
},
{
"name": "CVE-2025-38154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38154"
},
{
"name": "CVE-2025-38469",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38469"
},
{
"name": "CVE-2025-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38581"
},
{
"name": "CVE-2025-40034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40034"
},
{
"name": "CVE-2025-40060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40060"
},
{
"name": "CVE-2025-39790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39790"
},
{
"name": "CVE-2025-38389",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38389"
},
{
"name": "CVE-2025-38448",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38448"
},
{
"name": "CVE-2025-37780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37780"
},
{
"name": "CVE-2025-37995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37995"
},
{
"name": "CVE-2025-38680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38680"
},
{
"name": "CVE-2025-37754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37754"
},
{
"name": "CVE-2025-40059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40059"
},
{
"name": "CVE-2025-38497",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38497"
},
{
"name": "CVE-2025-68168",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68168"
},
{
"name": "CVE-2025-23156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23156"
},
{
"name": "CVE-2025-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23157"
},
{
"name": "CVE-2025-68206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68206"
},
{
"name": "CVE-2025-68309",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68309"
},
{
"name": "CVE-2025-38684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38684"
},
{
"name": "CVE-2025-38165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38165"
},
{
"name": "CVE-2025-40003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40003"
},
{
"name": "CVE-2025-39686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39686"
},
{
"name": "CVE-2025-39798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39798"
},
{
"name": "CVE-2025-38495",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38495"
},
{
"name": "CVE-2025-37808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37808"
},
{
"name": "CVE-2025-38730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38730"
},
{
"name": "CVE-2025-38052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38052"
},
{
"name": "CVE-2025-38377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38377"
},
{
"name": "CVE-2025-40175",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40175"
},
{
"name": "CVE-2025-68170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68170"
},
{
"name": "CVE-2025-39747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39747"
},
{
"name": "CVE-2025-68313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68313"
},
{
"name": "CVE-2025-38516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38516"
},
{
"name": "CVE-2025-38462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38462"
},
{
"name": "CVE-2025-38428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38428"
},
{
"name": "CVE-2025-39714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39714"
},
{
"name": "CVE-2025-38262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38262"
},
{
"name": "CVE-2025-38138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38138"
},
{
"name": "CVE-2025-38035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38035"
},
{
"name": "CVE-2025-37759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37759"
},
{
"name": "CVE-2025-38414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38414"
},
{
"name": "CVE-2025-68197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68197"
},
{
"name": "CVE-2025-40123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40123"
},
{
"name": "CVE-2025-37933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37933"
},
{
"name": "CVE-2025-38310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38310"
},
{
"name": "CVE-2025-37886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37886"
},
{
"name": "CVE-2025-37963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37963"
},
{
"name": "CVE-2025-40297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40297"
},
{
"name": "CVE-2025-38226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38226"
},
{
"name": "CVE-2025-39706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39706"
},
{
"name": "CVE-2025-40178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40178"
},
{
"name": "CVE-2025-40363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40363"
},
{
"name": "CVE-2025-38443",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38443"
},
{
"name": "CVE-2025-38576",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38576"
},
{
"name": "CVE-2025-37800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37800"
},
{
"name": "CVE-2025-40276",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40276"
},
{
"name": "CVE-2025-37900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37900"
},
{
"name": "CVE-2025-40224",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40224"
},
{
"name": "CVE-2025-38439",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38439"
},
{
"name": "CVE-2025-37805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37805"
},
{
"name": "CVE-2025-68245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68245"
},
{
"name": "CVE-2025-39719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39719"
},
{
"name": "CVE-2025-40317",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40317"
},
{
"name": "CVE-2025-40236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40236"
},
{
"name": "CVE-2025-37990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37990"
},
{
"name": "CVE-2025-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38553"
},
{
"name": "CVE-2025-38190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38190"
},
{
"name": "CVE-2025-38180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38180"
},
{
"name": "CVE-2025-39738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39738"
},
{
"name": "CVE-2025-68202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68202"
},
{
"name": "CVE-2025-38145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38145"
},
{
"name": "CVE-2025-40174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40174"
},
{
"name": "CVE-2025-37948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37948"
},
{
"name": "CVE-2025-38166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38166"
},
{
"name": "CVE-2025-40227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40227"
},
{
"name": "CVE-2025-37862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37862"
},
{
"name": "CVE-2025-38321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38321"
},
{
"name": "CVE-2025-39705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39705"
},
{
"name": "CVE-2025-40316",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40316"
},
{
"name": "CVE-2025-37960",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37960"
},
{
"name": "CVE-2025-38045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38045"
},
{
"name": "CVE-2025-38051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38051"
},
{
"name": "CVE-2025-39713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39713"
},
{
"name": "CVE-2025-37763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37763"
},
{
"name": "CVE-2025-37954",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37954"
},
{
"name": "CVE-2025-22128",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22128"
},
{
"name": "CVE-2025-40065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40065"
},
{
"name": "CVE-2025-37839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37839"
},
{
"name": "CVE-2025-39744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39744"
},
{
"name": "CVE-2025-38277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38277"
},
{
"name": "CVE-2025-37913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37913"
},
{
"name": "CVE-2025-68177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68177"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38539"
},
{
"name": "CVE-2025-40181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40181"
},
{
"name": "CVE-2025-68191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68191"
},
{
"name": "CVE-2025-38044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38044"
},
{
"name": "CVE-2025-68250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68250"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2025-40141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40141"
},
{
"name": "CVE-2025-38200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38200"
},
{
"name": "CVE-2025-38480",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38480"
},
{
"name": "CVE-2025-40132",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40132"
},
{
"name": "CVE-2025-38346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38346"
},
{
"name": "CVE-2025-40152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40152"
},
{
"name": "CVE-2025-37959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37959"
},
{
"name": "CVE-2025-38191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38191"
},
{
"name": "CVE-2025-39946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39946"
},
{
"name": "CVE-2024-50299",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50299"
},
{
"name": "CVE-2025-38062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38062"
},
{
"name": "CVE-2025-38531",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38531"
},
{
"name": "CVE-2025-40288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40288"
},
{
"name": "CVE-2025-68239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68239"
},
{
"name": "CVE-2025-39693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39693"
},
{
"name": "CVE-2025-40281",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40281"
},
{
"name": "CVE-2025-68185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68185"
},
{
"name": "CVE-2025-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40304"
},
{
"name": "CVE-2025-38503",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38503"
},
{
"name": "CVE-2025-40110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40110"
},
{
"name": "CVE-2025-40162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40162"
},
{
"name": "CVE-2025-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38630"
},
{
"name": "CVE-2025-38131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38131"
},
{
"name": "CVE-2025-40268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40268"
},
{
"name": "CVE-2025-37851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37851"
},
{
"name": "CVE-2025-38481",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38481"
},
{
"name": "CVE-2025-38585",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38585"
},
{
"name": "CVE-2025-38320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38320"
},
{
"name": "CVE-2025-38625",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38625"
},
{
"name": "CVE-2025-38164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38164"
},
{
"name": "CVE-2025-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40303"
},
{
"name": "CVE-2025-68178",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68178"
},
{
"name": "CVE-2025-40337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40337"
},
{
"name": "CVE-2025-40346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40346"
},
{
"name": "CVE-2025-38264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38264"
},
{
"name": "CVE-2025-40036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40036"
},
{
"name": "CVE-2025-39676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39676"
},
{
"name": "CVE-2025-40241",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40241"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2025-38280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38280"
},
{
"name": "CVE-2025-37788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37788"
},
{
"name": "CVE-2025-38427",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38427"
},
{
"name": "CVE-2025-38084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38084"
},
{
"name": "CVE-2025-40046",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40046"
},
{
"name": "CVE-2025-37879",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37879"
},
{
"name": "CVE-2025-38217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38217"
},
{
"name": "CVE-2025-40030",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40030"
},
{
"name": "CVE-2025-40244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40244"
},
{
"name": "CVE-2025-37881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37881"
},
{
"name": "CVE-2025-38103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38103"
},
{
"name": "CVE-2025-38514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38514"
},
{
"name": "CVE-2025-39783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39783"
},
{
"name": "CVE-2025-39715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39715"
},
{
"name": "CVE-2025-40323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40323"
},
{
"name": "CVE-2025-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38569"
},
{
"name": "CVE-2025-38255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38255"
},
{
"name": "CVE-2025-38512",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38512"
},
{
"name": "CVE-2025-40096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40096"
},
{
"name": "CVE-2025-38622",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38622"
},
{
"name": "CVE-2025-37909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37909"
},
{
"name": "CVE-2025-38700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38700"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2025-38532",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38532"
},
{
"name": "CVE-2025-39712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39712"
},
{
"name": "CVE-2025-37812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37812"
},
{
"name": "CVE-2025-39707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39707"
},
{
"name": "CVE-2025-40275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40275"
},
{
"name": "CVE-2025-37875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37875"
},
{
"name": "CVE-2025-38410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38410"
},
{
"name": "CVE-2025-40182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40182"
},
{
"name": "CVE-2025-68211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68211"
},
{
"name": "CVE-2025-39781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39781"
},
{
"name": "CVE-2025-38640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38640"
},
{
"name": "CVE-2025-38476",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38476"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2025-40339",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40339"
},
{
"name": "CVE-2025-40140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40140"
},
{
"name": "CVE-2025-38020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38020"
},
{
"name": "CVE-2025-40223",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40223"
},
{
"name": "CVE-2025-38572",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38572"
},
{
"name": "CVE-2025-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23140"
},
{
"name": "CVE-2025-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23150"
},
{
"name": "CVE-2025-38460",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38460"
},
{
"name": "CVE-2025-40061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40061"
},
{
"name": "CVE-2025-38182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38182"
},
{
"name": "CVE-2025-38550",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38550"
},
{
"name": "CVE-2025-38275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38275"
},
{
"name": "CVE-2025-40213",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40213"
},
{
"name": "CVE-2025-38345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38345"
},
{
"name": "CVE-2025-40334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40334"
},
{
"name": "CVE-2025-38170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38170"
},
{
"name": "CVE-2025-39711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39711"
},
{
"name": "CVE-2025-22115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22115"
},
{
"name": "CVE-2025-22120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22120"
},
{
"name": "CVE-2025-38535",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38535"
},
{
"name": "CVE-2022-49267",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49267"
},
{
"name": "CVE-2025-38231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38231"
},
{
"name": "CVE-2025-37854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37854"
},
{
"name": "CVE-2025-40142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40142"
},
{
"name": "CVE-2025-40159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40159"
},
{
"name": "CVE-2025-40319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40319"
},
{
"name": "CVE-2025-68193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68193"
},
{
"name": "CVE-2025-38473",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38473"
},
{
"name": "CVE-2025-38113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38113"
},
{
"name": "CVE-2025-38714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38714"
},
{
"name": "CVE-2025-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23148"
},
{
"name": "CVE-2025-38361",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38361"
},
{
"name": "CVE-2025-38470",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38470"
},
{
"name": "CVE-2025-38181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38181"
},
{
"name": "CVE-2025-40051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40051"
},
{
"name": "CVE-2025-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38391"
},
{
"name": "CVE-2025-38248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38248"
},
{
"name": "CVE-2025-40351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40351"
},
{
"name": "CVE-2025-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40087"
},
{
"name": "CVE-2025-40229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40229"
},
{
"name": "CVE-2025-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23147"
},
{
"name": "CVE-2025-39752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39752"
}
],
"initial_release_date": "2026-02-27T00:00:00",
"last_revision_date": "2026-02-27T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0227",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-02-27T00: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": "2026-02-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8060-1",
"url": "https://ubuntu.com/security/notices/USN-8060-1"
},
{
"published_at": "2026-02-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8059-2",
"url": "https://ubuntu.com/security/notices/USN-8059-2"
},
{
"published_at": "2026-02-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8028-8",
"url": "https://ubuntu.com/security/notices/USN-8028-8"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8060-4",
"url": "https://ubuntu.com/security/notices/USN-8060-4"
},
{
"published_at": "2026-02-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8052-2",
"url": "https://ubuntu.com/security/notices/USN-8052-2"
},
{
"published_at": "2026-02-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8060-2",
"url": "https://ubuntu.com/security/notices/USN-8060-2"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8059-4",
"url": "https://ubuntu.com/security/notices/USN-8059-4"
},
{
"published_at": "2026-02-26",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8059-6",
"url": "https://ubuntu.com/security/notices/USN-8059-6"
},
{
"published_at": "2026-02-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8061-1",
"url": "https://ubuntu.com/security/notices/USN-8061-1"
},
{
"published_at": "2026-02-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8060-3",
"url": "https://ubuntu.com/security/notices/USN-8060-3"
},
{
"published_at": "2026-02-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8059-1",
"url": "https://ubuntu.com/security/notices/USN-8059-1"
},
{
"published_at": "2026-02-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8029-3",
"url": "https://ubuntu.com/security/notices/USN-8029-3"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8059-5",
"url": "https://ubuntu.com/security/notices/USN-8059-5"
},
{
"published_at": "2026-02-25",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8059-3",
"url": "https://ubuntu.com/security/notices/USN-8059-3"
},
{
"published_at": "2026-02-20",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8015-5",
"url": "https://ubuntu.com/security/notices/USN-8015-5"
}
]
}
CERTFR-2026-AVI-0246
Vulnerability from certfr_avis - Published: 2026-03-06 - Updated: 2026-03-06
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 exécution de code arbitraire, une atteinte à la confidentialité des données et une atteinte à l'intégrité des données.
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 18.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.10",
"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-2025-38490",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38490"
},
{
"name": "CVE-2025-37850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37850"
},
{
"name": "CVE-2025-38485",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38485"
},
{
"name": "CVE-2025-22026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22026"
},
{
"name": "CVE-2025-38579",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38579"
},
{
"name": "CVE-2025-37761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37761"
},
{
"name": "CVE-2025-37865",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37865"
},
{
"name": "CVE-2025-38328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38328"
},
{
"name": "CVE-2025-38711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38711"
},
{
"name": "CVE-2025-38487",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38487"
},
{
"name": "CVE-2025-37775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37775"
},
{
"name": "CVE-2025-38335",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38335"
},
{
"name": "CVE-2025-38304",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38304"
},
{
"name": "CVE-2025-37892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37892"
},
{
"name": "CVE-2025-38100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38100"
},
{
"name": "CVE-2025-37859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37859"
},
{
"name": "CVE-2025-38043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38043"
},
{
"name": "CVE-2025-38471",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38471"
},
{
"name": "CVE-2025-38520",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38520"
},
{
"name": "CVE-2025-37792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37792"
},
{
"name": "CVE-2025-38108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38108"
},
{
"name": "CVE-2025-38230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38230"
},
{
"name": "CVE-2025-38229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38229"
},
{
"name": "CVE-2025-38158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38158"
},
{
"name": "CVE-2025-37872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37872"
},
{
"name": "CVE-2025-38588",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38588"
},
{
"name": "CVE-2025-38279",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38279"
},
{
"name": "CVE-2025-38561",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38561"
},
{
"name": "CVE-2025-38574",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38574"
},
{
"name": "CVE-2025-22036",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22036"
},
{
"name": "CVE-2025-38147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38147"
},
{
"name": "CVE-2025-23155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23155"
},
{
"name": "CVE-2025-38286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38286"
},
{
"name": "CVE-2025-39757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39757"
},
{
"name": "CVE-2025-38501",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38501"
},
{
"name": "CVE-2025-38474",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38474"
},
{
"name": "CVE-2025-37979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37979"
},
{
"name": "CVE-2025-37777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37777"
},
{
"name": "CVE-2025-39772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39772"
},
{
"name": "CVE-2025-37936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37936"
},
{
"name": "CVE-2025-38601",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38601"
},
{
"name": "CVE-2025-37766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37766"
},
{
"name": "CVE-2025-38104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38104"
},
{
"name": "CVE-2025-37844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37844"
},
{
"name": "CVE-2025-21931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21931"
},
{
"name": "CVE-2025-37871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37871"
},
{
"name": "CVE-2025-37778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37778"
},
{
"name": "CVE-2025-39716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39716"
},
{
"name": "CVE-2025-39702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39702"
},
{
"name": "CVE-2025-38515",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38515"
},
{
"name": "CVE-2025-38645",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38645"
},
{
"name": "CVE-2025-38163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38163"
},
{
"name": "CVE-2025-22126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22126"
},
{
"name": "CVE-2025-38444",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38444"
},
{
"name": "CVE-2025-38109",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38109"
},
{
"name": "CVE-2025-39779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39779"
},
{
"name": "CVE-2025-37755",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37755"
},
{
"name": "CVE-2021-47599",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47599"
},
{
"name": "CVE-2025-39685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39685"
},
{
"name": "CVE-2025-38660",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38660"
},
{
"name": "CVE-2025-39761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39761"
},
{
"name": "CVE-2025-39720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39720"
},
{
"name": "CVE-2025-38624",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38624"
},
{
"name": "CVE-2025-38388",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38388"
},
{
"name": "CVE-2025-38157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38157"
},
{
"name": "CVE-2025-37790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37790"
},
{
"name": "CVE-2025-39746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39746"
},
{
"name": "CVE-2025-38323",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38323"
},
{
"name": "CVE-2025-40019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40019"
},
{
"name": "CVE-2025-38208",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38208"
},
{
"name": "CVE-2025-38219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38219"
},
{
"name": "CVE-2025-39889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39889"
},
{
"name": "CVE-2025-38099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38099"
},
{
"name": "CVE-2025-38524",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38524"
},
{
"name": "CVE-2025-38466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38466"
},
{
"name": "CVE-2025-37758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37758"
},
{
"name": "CVE-2025-38087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38087"
},
{
"name": "CVE-2025-38039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38039"
},
{
"name": "CVE-2025-38595",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38595"
},
{
"name": "CVE-2024-56548",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56548"
},
{
"name": "CVE-2025-38626",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38626"
},
{
"name": "CVE-2025-37852",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37852"
},
{
"name": "CVE-2025-37841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37841"
},
{
"name": "CVE-2025-37918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37918"
},
{
"name": "CVE-2025-37917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37917"
},
{
"name": "CVE-2025-38290",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38290"
},
{
"name": "CVE-2025-38063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38063"
},
{
"name": "CVE-2025-37770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37770"
},
{
"name": "CVE-2025-37773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37773"
},
{
"name": "CVE-2025-38578",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38578"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2025-38675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38675"
},
{
"name": "CVE-2025-38646",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38646"
},
{
"name": "CVE-2025-38491",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38491"
},
{
"name": "CVE-2025-38708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38708"
},
{
"name": "CVE-2025-37961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37961"
},
{
"name": "CVE-2025-38313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38313"
},
{
"name": "CVE-2025-38336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38336"
},
{
"name": "CVE-2025-38408",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38408"
},
{
"name": "CVE-2025-38644",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38644"
},
{
"name": "CVE-2025-38692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38692"
},
{
"name": "CVE-2025-38061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38061"
},
{
"name": "CVE-2025-37983",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37983"
},
{
"name": "CVE-2025-38127",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38127"
},
{
"name": "CVE-2025-38375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38375"
},
{
"name": "CVE-2025-37784",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37784"
},
{
"name": "CVE-2025-39701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39701"
},
{
"name": "CVE-2025-37920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37920"
},
{
"name": "CVE-2025-37815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37815"
},
{
"name": "CVE-2025-38686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38686"
},
{
"name": "CVE-2025-37819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37819"
},
{
"name": "CVE-2025-38609",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38609"
},
{
"name": "CVE-2024-36357",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36357"
},
{
"name": "CVE-2025-38463",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38463"
},
{
"name": "CVE-2025-38112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38112"
},
{
"name": "CVE-2025-38521",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38521"
},
{
"name": "CVE-2025-38023",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38023"
},
{
"name": "CVE-2025-39709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39709"
},
{
"name": "CVE-2025-38282",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38282"
},
{
"name": "CVE-2025-39689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39689"
},
{
"name": "CVE-2025-38215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38215"
},
{
"name": "CVE-2025-39787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39787"
},
{
"name": "CVE-2025-37943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37943"
},
{
"name": "CVE-2025-37745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37745"
},
{
"name": "CVE-2025-39731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39731"
},
{
"name": "CVE-2025-38734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38734"
},
{
"name": "CVE-2025-38653",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38653"
},
{
"name": "CVE-2025-38571",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38571"
},
{
"name": "CVE-2025-37789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37789"
},
{
"name": "CVE-2025-38695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38695"
},
{
"name": "CVE-2025-38004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38004"
},
{
"name": "CVE-2025-39749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39749"
},
{
"name": "CVE-2025-38387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38387"
},
{
"name": "CVE-2025-38362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38362"
},
{
"name": "CVE-2025-37924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37924"
},
{
"name": "CVE-2025-38371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38371"
},
{
"name": "CVE-2025-38445",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38445"
},
{
"name": "CVE-2025-38456",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38456"
},
{
"name": "CVE-2025-38538",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38538"
},
{
"name": "CVE-2025-37867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37867"
},
{
"name": "CVE-2025-23160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23160"
},
{
"name": "CVE-2025-38295",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38295"
},
{
"name": "CVE-2025-38461",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38461"
},
{
"name": "CVE-2025-37857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37857"
},
{
"name": "CVE-2025-37842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37842"
},
{
"name": "CVE-2025-38710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38710"
},
{
"name": "CVE-2025-39681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39681"
},
{
"name": "CVE-2025-38060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38060"
},
{
"name": "CVE-2025-38159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38159"
},
{
"name": "CVE-2025-38066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38066"
},
{
"name": "CVE-2025-39770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39770"
},
{
"name": "CVE-2025-37744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37744"
},
{
"name": "CVE-2025-38705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38705"
},
{
"name": "CVE-2025-38706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38706"
},
{
"name": "CVE-2025-38305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38305"
},
{
"name": "CVE-2025-37884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37884"
},
{
"name": "CVE-2025-38067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38067"
},
{
"name": "CVE-2025-39750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39750"
},
{
"name": "CVE-2025-38699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38699"
},
{
"name": "CVE-2025-37927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37927"
},
{
"name": "CVE-2025-38707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38707"
},
{
"name": "CVE-2025-38562",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38562"
},
{
"name": "CVE-2025-37897",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37897"
},
{
"name": "CVE-2025-37911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37911"
},
{
"name": "CVE-2025-38587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38587"
},
{
"name": "CVE-2025-37869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37869"
},
{
"name": "CVE-2025-39692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39692"
},
{
"name": "CVE-2025-38068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38068"
},
{
"name": "CVE-2025-38436",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38436"
},
{
"name": "CVE-2025-37930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37930"
},
{
"name": "CVE-2025-38401",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38401"
},
{
"name": "CVE-2025-38677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38677"
},
{
"name": "CVE-2025-38097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38097"
},
{
"name": "CVE-2025-37810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37810"
},
{
"name": "CVE-2025-38253",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38253"
},
{
"name": "CVE-2025-38123",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38123"
},
{
"name": "CVE-2025-38338",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38338"
},
{
"name": "CVE-2025-38555",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38555"
},
{
"name": "CVE-2025-38239",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38239"
},
{
"name": "CVE-2025-38590",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38590"
},
{
"name": "CVE-2025-38027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38027"
},
{
"name": "CVE-2025-38102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38102"
},
{
"name": "CVE-2025-38283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38283"
},
{
"name": "CVE-2025-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23159"
},
{
"name": "CVE-2025-38455",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38455"
},
{
"name": "CVE-2025-38584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38584"
},
{
"name": "CVE-2025-38015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38015"
},
{
"name": "CVE-2025-39675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39675"
},
{
"name": "CVE-2025-39679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39679"
},
{
"name": "CVE-2025-38527",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38527"
},
{
"name": "CVE-2025-38449",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38449"
},
{
"name": "CVE-2025-37853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37853"
},
{
"name": "CVE-2025-38126",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38126"
},
{
"name": "CVE-2025-38149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38149"
},
{
"name": "CVE-2025-39763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39763"
},
{
"name": "CVE-2025-38399",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38399"
},
{
"name": "CVE-2025-38065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38065"
},
{
"name": "CVE-2025-38693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38693"
},
{
"name": "CVE-2025-38679",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38679"
},
{
"name": "CVE-2025-38459",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38459"
},
{
"name": "CVE-2025-38685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38685"
},
{
"name": "CVE-2025-38412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38412"
},
{
"name": "CVE-2025-38031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38031"
},
{
"name": "CVE-2025-38293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38293"
},
{
"name": "CVE-2025-38648",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38648"
},
{
"name": "CVE-2025-38278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38278"
},
{
"name": "CVE-2025-37764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37764"
},
{
"name": "CVE-2025-38184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38184"
},
{
"name": "CVE-2025-37741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37741"
},
{
"name": "CVE-2025-38053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38053"
},
{
"name": "CVE-2025-37822",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37822"
},
{
"name": "CVE-2025-37912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37912"
},
{
"name": "CVE-2025-38482",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38482"
},
{
"name": "CVE-2025-37820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37820"
},
{
"name": "CVE-2025-37985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37985"
},
{
"name": "CVE-2025-38634",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38634"
},
{
"name": "CVE-2025-37787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37787"
},
{
"name": "CVE-2025-38008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38008"
},
{
"name": "CVE-2025-38458",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38458"
},
{
"name": "CVE-2025-39730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39730"
},
{
"name": "CVE-2025-38011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38011"
},
{
"name": "CVE-2025-38034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38034"
},
{
"name": "CVE-2025-38135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38135"
},
{
"name": "CVE-2025-38619",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38619"
},
{
"name": "CVE-2025-38312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38312"
},
{
"name": "CVE-2025-38095",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38095"
},
{
"name": "CVE-2025-37878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37878"
},
{
"name": "CVE-2025-39737",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39737"
},
{
"name": "CVE-2025-38464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38464"
},
{
"name": "CVE-2025-38363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38363"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2025-38702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38702"
},
{
"name": "CVE-2025-38319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38319"
},
{
"name": "CVE-2022-49698",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49698"
},
{
"name": "CVE-2025-38724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38724"
},
{
"name": "CVE-2025-38250",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38250"
},
{
"name": "CVE-2025-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38457"
},
{
"name": "CVE-2025-38582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38582"
},
{
"name": "CVE-2025-37813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37813"
},
{
"name": "CVE-2025-38543",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38543"
},
{
"name": "CVE-2025-38698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38698"
},
{
"name": "CVE-2025-38212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38212"
},
{
"name": "CVE-2025-38298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38298"
},
{
"name": "CVE-2025-39739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39739"
},
{
"name": "CVE-2025-38024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38024"
},
{
"name": "CVE-2025-38496",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38496"
},
{
"name": "CVE-2025-38078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38078"
},
{
"name": "CVE-2025-38419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38419"
},
{
"name": "CVE-2025-38533",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38533"
},
{
"name": "CVE-2025-38169",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38169"
},
{
"name": "CVE-2025-37931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37931"
},
{
"name": "CVE-2025-38511",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38511"
},
{
"name": "CVE-2025-38537",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38537"
},
{
"name": "CVE-2025-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38546"
},
{
"name": "CVE-2025-38211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38211"
},
{
"name": "CVE-2025-38057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38057"
},
{
"name": "CVE-2025-37887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37887"
},
{
"name": "CVE-2025-38077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38077"
},
{
"name": "CVE-2025-38251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38251"
},
{
"name": "CVE-2025-37861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37861"
},
{
"name": "CVE-2025-38120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38120"
},
{
"name": "CVE-2025-38285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38285"
},
{
"name": "CVE-2025-39743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39743"
},
{
"name": "CVE-2025-39718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39718"
},
{
"name": "CVE-2025-37938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37938"
},
{
"name": "CVE-2025-38005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38005"
},
{
"name": "CVE-2025-38368",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38368"
},
{
"name": "CVE-2025-38161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38161"
},
{
"name": "CVE-2025-38331",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38331"
},
{
"name": "CVE-2025-38354",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38354"
},
{
"name": "CVE-2025-38712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38712"
},
{
"name": "CVE-2025-38732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38732"
},
{
"name": "CVE-2025-39773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39773"
},
{
"name": "CVE-2025-38696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38696"
},
{
"name": "CVE-2025-38274",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38274"
},
{
"name": "CVE-2025-37874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37874"
},
{
"name": "CVE-2025-38115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38115"
},
{
"name": "CVE-2025-38632",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38632"
},
{
"name": "CVE-2025-37988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37988"
},
{
"name": "CVE-2025-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23158"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23144"
},
{
"name": "CVE-2025-38153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38153"
},
{
"name": "CVE-2025-37969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37969"
},
{
"name": "CVE-2025-38548",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38548"
},
{
"name": "CVE-2025-37816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37816"
},
{
"name": "CVE-2025-37899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37899"
},
{
"name": "CVE-2025-37742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37742"
},
{
"name": "CVE-2025-37765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37765"
},
{
"name": "CVE-2025-38395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38395"
},
{
"name": "CVE-2025-37921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37921"
},
{
"name": "CVE-2025-38507",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38507"
},
{
"name": "CVE-2025-39989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39989"
},
{
"name": "CVE-2025-38337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38337"
},
{
"name": "CVE-2025-38014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38014"
},
{
"name": "CVE-2025-38258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38258"
},
{
"name": "CVE-2025-37828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37828"
},
{
"name": "CVE-2025-37769",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37769"
},
{
"name": "CVE-2025-38465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38465"
},
{
"name": "CVE-2025-38513",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38513"
},
{
"name": "CVE-2025-38086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38086"
},
{
"name": "CVE-2025-37935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37935"
},
{
"name": "CVE-2025-38396",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38396"
},
{
"name": "CVE-2025-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23161"
},
{
"name": "CVE-2025-38407",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38407"
},
{
"name": "CVE-2025-38493",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38493"
},
{
"name": "CVE-2025-37803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37803"
},
{
"name": "CVE-2022-48875",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48875"
},
{
"name": "CVE-2025-38670",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38670"
},
{
"name": "CVE-2025-39732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39732"
},
{
"name": "CVE-2025-37824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37824"
},
{
"name": "CVE-2025-38602",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38602"
},
{
"name": "CVE-2025-38003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38003"
},
{
"name": "CVE-2025-38441",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38441"
},
{
"name": "CVE-2025-38007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38007"
},
{
"name": "CVE-2025-37923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37923"
},
{
"name": "CVE-2025-38142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38142"
},
{
"name": "CVE-2025-37739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37739"
},
{
"name": "CVE-2025-38478",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38478"
},
{
"name": "CVE-2025-38568",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38568"
},
{
"name": "CVE-2025-38583",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38583"
},
{
"name": "CVE-2025-39788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39788"
},
{
"name": "CVE-2025-37831",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37831"
},
{
"name": "CVE-2025-38499",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38499"
},
{
"name": "CVE-2025-38269",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38269"
},
{
"name": "CVE-2025-38079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38079"
},
{
"name": "CVE-2025-37940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37940"
},
{
"name": "CVE-2025-37945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37945"
},
{
"name": "CVE-2025-38735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38735"
},
{
"name": "CVE-2025-38652",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38652"
},
{
"name": "CVE-2025-38110",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38110"
},
{
"name": "CVE-2025-38422",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38422"
},
{
"name": "CVE-2025-38402",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38402"
},
{
"name": "CVE-2025-39698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39698"
},
{
"name": "CVE-2025-37915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37915"
},
{
"name": "CVE-2025-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23146"
},
{
"name": "CVE-2025-37903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37903"
},
{
"name": "CVE-2025-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23142"
},
{
"name": "CVE-2025-37738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37738"
},
{
"name": "CVE-2025-38303",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38303"
},
{
"name": "CVE-2025-38074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38074"
},
{
"name": "CVE-2025-38119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38119"
},
{
"name": "CVE-2025-38232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38232"
},
{
"name": "CVE-2025-38245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38245"
},
{
"name": "CVE-2025-38324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38324"
},
{
"name": "CVE-2025-38018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38018"
},
{
"name": "CVE-2025-37830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37830"
},
{
"name": "CVE-2025-38614",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38614"
},
{
"name": "CVE-2025-37991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37991"
},
{
"name": "CVE-2025-38425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38425"
},
{
"name": "CVE-2025-37978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37978"
},
{
"name": "CVE-2025-37781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37781"
},
{
"name": "CVE-2025-38210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38210"
},
{
"name": "CVE-2025-38542",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38542"
},
{
"name": "CVE-2025-38664",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38664"
},
{
"name": "CVE-2025-38344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38344"
},
{
"name": "CVE-2025-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23145"
},
{
"name": "CVE-2025-38322",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38322"
},
{
"name": "CVE-2025-38088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38088"
},
{
"name": "CVE-2025-23141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23141"
},
{
"name": "CVE-2025-37823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37823"
},
{
"name": "CVE-2025-38332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38332"
},
{
"name": "CVE-2025-38386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38386"
},
{
"name": "CVE-2025-38385",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38385"
},
{
"name": "CVE-2025-37952",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37952"
},
{
"name": "CVE-2025-38694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38694"
},
{
"name": "CVE-2025-37793",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37793"
},
{
"name": "CVE-2025-37740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37740"
},
{
"name": "CVE-2025-38676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38676"
},
{
"name": "CVE-2025-38530",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38530"
},
{
"name": "CVE-2025-38174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38174"
},
{
"name": "CVE-2025-37826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37826"
},
{
"name": "CVE-2025-37986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37986"
},
{
"name": "CVE-2025-37829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37829"
},
{
"name": "CVE-2025-38409",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38409"
},
{
"name": "CVE-2025-38019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38019"
},
{
"name": "CVE-2025-38729",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38729"
},
{
"name": "CVE-2025-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23151"
},
{
"name": "CVE-2025-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38037"
},
{
"name": "CVE-2025-37796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37796"
},
{
"name": "CVE-2025-37962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37962"
},
{
"name": "CVE-2025-38681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38681"
},
{
"name": "CVE-2025-37799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37799"
},
{
"name": "CVE-2025-38593",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38593"
},
{
"name": "CVE-2025-38342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38342"
},
{
"name": "CVE-2025-39795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39795"
},
{
"name": "CVE-2025-37801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37801"
},
{
"name": "CVE-2025-38167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38167"
},
{
"name": "CVE-2025-37883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37883"
},
{
"name": "CVE-2025-37863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37863"
},
{
"name": "CVE-2025-37901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37901"
},
{
"name": "CVE-2025-38687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38687"
},
{
"name": "CVE-2025-37811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37811"
},
{
"name": "CVE-2025-38257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38257"
},
{
"name": "CVE-2025-37864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37864"
},
{
"name": "CVE-2025-38307",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38307"
},
{
"name": "CVE-2025-37916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37916"
},
{
"name": "CVE-2025-38111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38111"
},
{
"name": "CVE-2025-37767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37767"
},
{
"name": "CVE-2025-37989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37989"
},
{
"name": "CVE-2025-38529",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38529"
},
{
"name": "CVE-2025-38326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38326"
},
{
"name": "CVE-2025-38055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38055"
},
{
"name": "CVE-2025-38129",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38129"
},
{
"name": "CVE-2025-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38384"
},
{
"name": "CVE-2025-38334",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38334"
},
{
"name": "CVE-2025-38728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38728"
},
{
"name": "CVE-2025-38424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38424"
},
{
"name": "CVE-2025-38430",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38430"
},
{
"name": "CVE-2025-38715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38715"
},
{
"name": "CVE-2025-39734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39734"
},
{
"name": "CVE-2025-38089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38089"
},
{
"name": "CVE-2025-38382",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38382"
},
{
"name": "CVE-2025-38608",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38608"
},
{
"name": "CVE-2025-38650",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38650"
},
{
"name": "CVE-2025-39710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39710"
},
{
"name": "CVE-2025-38124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38124"
},
{
"name": "CVE-2025-37925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37925"
},
{
"name": "CVE-2025-39683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39683"
},
{
"name": "CVE-2025-38420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38420"
},
{
"name": "CVE-2025-38071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38071"
},
{
"name": "CVE-2025-37972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37972"
},
{
"name": "CVE-2025-38183",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38183"
},
{
"name": "CVE-2025-37768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37768"
},
{
"name": "CVE-2025-39794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39794"
},
{
"name": "CVE-2025-38160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38160"
},
{
"name": "CVE-2025-37984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37984"
},
{
"name": "CVE-2025-38528",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38528"
},
{
"name": "CVE-2025-37856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37856"
},
{
"name": "CVE-2025-38107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38107"
},
{
"name": "CVE-2025-38292",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38292"
},
{
"name": "CVE-2025-38085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38085"
},
{
"name": "CVE-2025-38222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38222"
},
{
"name": "CVE-2025-38010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38010"
},
{
"name": "CVE-2025-38197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38197"
},
{
"name": "CVE-2025-38468",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38468"
},
{
"name": "CVE-2025-38688",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38688"
},
{
"name": "CVE-2025-38333",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38333"
},
{
"name": "CVE-2025-37970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37970"
},
{
"name": "CVE-2025-21884",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21884"
},
{
"name": "CVE-2025-37905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37905"
},
{
"name": "CVE-2025-38390",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38390"
},
{
"name": "CVE-2025-38013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38013"
},
{
"name": "CVE-2025-38059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38059"
},
{
"name": "CVE-2025-38713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38713"
},
{
"name": "CVE-2025-37956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37956"
},
{
"name": "CVE-2025-38148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38148"
},
{
"name": "CVE-2025-38467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38467"
},
{
"name": "CVE-2025-38117",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38117"
},
{
"name": "CVE-2025-38094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38094"
},
{
"name": "CVE-2025-40214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40214"
},
{
"name": "CVE-2025-38072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38072"
},
{
"name": "CVE-2025-37967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37967"
},
{
"name": "CVE-2025-38300",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38300"
},
{
"name": "CVE-2025-38289",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38289"
},
{
"name": "CVE-2025-39782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39782"
},
{
"name": "CVE-2025-38075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38075"
},
{
"name": "CVE-2025-37885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37885"
},
{
"name": "CVE-2025-38697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38697"
},
{
"name": "CVE-2025-37949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37949"
},
{
"name": "CVE-2025-38691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38691"
},
{
"name": "CVE-2025-38373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38373"
},
{
"name": "CVE-2025-38489",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38489"
},
{
"name": "CVE-2025-37957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37957"
},
{
"name": "CVE-2025-38058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38058"
},
{
"name": "CVE-2025-38483",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38483"
},
{
"name": "CVE-2025-38369",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38369"
},
{
"name": "CVE-2025-39759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39759"
},
{
"name": "CVE-2025-38639",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38639"
},
{
"name": "CVE-2025-38122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38122"
},
{
"name": "CVE-2025-38612",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38612"
},
{
"name": "CVE-2025-38173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38173"
},
{
"name": "CVE-2025-38143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38143"
},
{
"name": "CVE-2025-38098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38098"
},
{
"name": "CVE-2025-38566",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38566"
},
{
"name": "CVE-2025-39721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39721"
},
{
"name": "CVE-2025-39760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39760"
},
{
"name": "CVE-2025-38718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38718"
},
{
"name": "CVE-2025-38392",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38392"
},
{
"name": "CVE-2025-39673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39673"
},
{
"name": "CVE-2025-38259",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38259"
},
{
"name": "CVE-2025-38663",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38663"
},
{
"name": "CVE-2025-38156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38156"
},
{
"name": "CVE-2025-37951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37951"
},
{
"name": "CVE-2025-37840",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37840"
},
{
"name": "CVE-2025-37947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37947"
},
{
"name": "CVE-2025-38416",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38416"
},
{
"name": "CVE-2025-37846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37846"
},
{
"name": "CVE-2025-38722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38722"
},
{
"name": "CVE-2025-38192",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38192"
},
{
"name": "CVE-2025-39800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39800"
},
{
"name": "CVE-2025-38343",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38343"
},
{
"name": "CVE-2025-38202",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38202"
},
{
"name": "CVE-2025-22101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22101"
},
{
"name": "CVE-2025-38374",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38374"
},
{
"name": "CVE-2025-39703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39703"
},
{
"name": "CVE-2025-38194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38194"
},
{
"name": "CVE-2025-38549",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38549"
},
{
"name": "CVE-2025-38665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38665"
},
{
"name": "CVE-2025-38101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38101"
},
{
"name": "CVE-2025-37982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37982"
},
{
"name": "CVE-2025-37992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37992"
},
{
"name": "CVE-2025-38577",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38577"
},
{
"name": "CVE-2025-38671",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38671"
},
{
"name": "CVE-2025-38299",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38299"
},
{
"name": "CVE-2025-38635",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38635"
},
{
"name": "CVE-2025-38704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38704"
},
{
"name": "CVE-2025-38348",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38348"
},
{
"name": "CVE-2025-38488",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38488"
},
{
"name": "CVE-2025-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38540"
},
{
"name": "CVE-2025-38040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38040"
},
{
"name": "CVE-2025-38265",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38265"
},
{
"name": "CVE-2025-23149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23149"
},
{
"name": "CVE-2025-38403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38403"
},
{
"name": "CVE-2025-21726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21726"
},
{
"name": "CVE-2025-38552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38552"
},
{
"name": "CVE-2025-37914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37914"
},
{
"name": "CVE-2025-37873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37873"
},
{
"name": "CVE-2025-37928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37928"
},
{
"name": "CVE-2025-39766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39766"
},
{
"name": "CVE-2025-39801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39801"
},
{
"name": "CVE-2025-37922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37922"
},
{
"name": "CVE-2025-38146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38146"
},
{
"name": "CVE-2025-39724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39724"
},
{
"name": "CVE-2025-39687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39687"
},
{
"name": "CVE-2025-37794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37794"
},
{
"name": "CVE-2025-38510",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38510"
},
{
"name": "CVE-2025-38246",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38246"
},
{
"name": "CVE-2025-39758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39758"
},
{
"name": "CVE-2025-39694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39694"
},
{
"name": "CVE-2025-38220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38220"
},
{
"name": "CVE-2025-38405",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38405"
},
{
"name": "CVE-2025-38418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38418"
},
{
"name": "CVE-2025-38090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38090"
},
{
"name": "CVE-2025-38429",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38429"
},
{
"name": "CVE-2025-38225",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38225"
},
{
"name": "CVE-2025-22037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22037"
},
{
"name": "CVE-2025-38155",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38155"
},
{
"name": "CVE-2025-37977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37977"
},
{
"name": "CVE-2025-38365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38365"
},
{
"name": "CVE-2025-38415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38415"
},
{
"name": "CVE-2025-38668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38668"
},
{
"name": "CVE-2025-37973",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37973"
},
{
"name": "CVE-2025-68750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68750"
},
{
"name": "CVE-2025-38260",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38260"
},
{
"name": "CVE-2025-37827",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37827"
},
{
"name": "CVE-2025-38721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38721"
},
{
"name": "CVE-2025-38080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38080"
},
{
"name": "CVE-2025-37748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37748"
},
{
"name": "CVE-2025-38364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38364"
},
{
"name": "CVE-2025-38615",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38615"
},
{
"name": "CVE-2025-39684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39684"
},
{
"name": "CVE-2025-37836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37836"
},
{
"name": "CVE-2025-38526",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38526"
},
{
"name": "CVE-2025-38472",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38472"
},
{
"name": "CVE-2025-37944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37944"
},
{
"name": "CVE-2025-38506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38506"
},
{
"name": "CVE-2025-38703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38703"
},
{
"name": "CVE-2025-38494",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38494"
},
{
"name": "CVE-2025-39753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39753"
},
{
"name": "CVE-2025-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38604"
},
{
"name": "CVE-2025-38623",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38623"
},
{
"name": "CVE-2025-38193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38193"
},
{
"name": "CVE-2025-38400",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38400"
},
{
"name": "CVE-2025-38136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38136"
},
{
"name": "CVE-2025-38544",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38544"
},
{
"name": "CVE-2025-37771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37771"
},
{
"name": "CVE-2025-39797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39797"
},
{
"name": "CVE-2025-38236",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38236"
},
{
"name": "CVE-2025-38725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38725"
},
{
"name": "CVE-2025-37975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37975"
},
{
"name": "CVE-2025-38347",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38347"
},
{
"name": "CVE-2025-39776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39776"
},
{
"name": "CVE-2025-37998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37998"
},
{
"name": "CVE-2025-38198",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38198"
},
{
"name": "CVE-2025-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23163"
},
{
"name": "CVE-2025-37968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37968"
},
{
"name": "CVE-2025-38376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38376"
},
{
"name": "CVE-2025-38006",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38006"
},
{
"name": "CVE-2025-38437",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38437"
},
{
"name": "CVE-2025-38125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38125"
},
{
"name": "CVE-2025-38351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38351"
},
{
"name": "CVE-2025-38048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38048"
},
{
"name": "CVE-2025-39736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39736"
},
{
"name": "CVE-2025-37757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37757"
},
{
"name": "CVE-2025-38009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38009"
},
{
"name": "CVE-2025-40215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40215"
},
{
"name": "CVE-2025-38081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38081"
},
{
"name": "CVE-2025-37809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37809"
},
{
"name": "CVE-2024-36350",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36350"
},
{
"name": "CVE-2025-38185",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38185"
},
{
"name": "CVE-2025-39691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39691"
},
{
"name": "CVE-2025-38406",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38406"
},
{
"name": "CVE-2025-37817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37817"
},
{
"name": "CVE-2025-39890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39890"
},
{
"name": "CVE-2025-39742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39742"
},
{
"name": "CVE-2025-22102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22102"
},
{
"name": "CVE-2025-37987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37987"
},
{
"name": "CVE-2025-37749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37749"
},
{
"name": "CVE-2024-36331",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36331"
},
{
"name": "CVE-2025-39748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39748"
},
{
"name": "CVE-2024-49927",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49927"
},
{
"name": "CVE-2025-38263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38263"
},
{
"name": "CVE-2025-38610",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38610"
},
{
"name": "CVE-2025-37772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37772"
},
{
"name": "CVE-2025-38214",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38214"
},
{
"name": "CVE-2025-38560",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38560"
},
{
"name": "CVE-2025-37994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37994"
},
{
"name": "CVE-2025-38551",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38551"
},
{
"name": "CVE-2025-38701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38701"
},
{
"name": "CVE-2025-38218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38218"
},
{
"name": "CVE-2025-38349",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38349"
},
{
"name": "CVE-2025-39726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39726"
},
{
"name": "CVE-2025-38393",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38393"
},
{
"name": "CVE-2024-47659",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47659"
},
{
"name": "CVE-2025-37891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37891"
},
{
"name": "CVE-2025-38249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38249"
},
{
"name": "CVE-2025-38716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38716"
},
{
"name": "CVE-2025-37858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37858"
},
{
"name": "CVE-2025-38154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38154"
},
{
"name": "CVE-2025-38469",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38469"
},
{
"name": "CVE-2025-38581",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38581"
},
{
"name": "CVE-2025-39790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39790"
},
{
"name": "CVE-2025-38389",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38389"
},
{
"name": "CVE-2025-38448",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38448"
},
{
"name": "CVE-2025-37780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37780"
},
{
"name": "CVE-2025-37995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37995"
},
{
"name": "CVE-2025-38680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38680"
},
{
"name": "CVE-2025-37754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37754"
},
{
"name": "CVE-2025-38497",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38497"
},
{
"name": "CVE-2025-23156",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23156"
},
{
"name": "CVE-2025-23157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23157"
},
{
"name": "CVE-2025-38684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38684"
},
{
"name": "CVE-2025-38165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38165"
},
{
"name": "CVE-2025-39686",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39686"
},
{
"name": "CVE-2025-39798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39798"
},
{
"name": "CVE-2025-38495",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38495"
},
{
"name": "CVE-2025-37808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37808"
},
{
"name": "CVE-2025-38730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38730"
},
{
"name": "CVE-2025-38052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38052"
},
{
"name": "CVE-2025-38377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38377"
},
{
"name": "CVE-2025-39747",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39747"
},
{
"name": "CVE-2025-38516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38516"
},
{
"name": "CVE-2025-38462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38462"
},
{
"name": "CVE-2025-38428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38428"
},
{
"name": "CVE-2025-39714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39714"
},
{
"name": "CVE-2025-38262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38262"
},
{
"name": "CVE-2025-38138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38138"
},
{
"name": "CVE-2025-38035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38035"
},
{
"name": "CVE-2025-37759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37759"
},
{
"name": "CVE-2025-38414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38414"
},
{
"name": "CVE-2025-37933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37933"
},
{
"name": "CVE-2025-38310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38310"
},
{
"name": "CVE-2025-37886",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37886"
},
{
"name": "CVE-2025-37963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37963"
},
{
"name": "CVE-2025-40297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40297"
},
{
"name": "CVE-2025-38226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38226"
},
{
"name": "CVE-2025-39706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39706"
},
{
"name": "CVE-2025-38443",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38443"
},
{
"name": "CVE-2025-38576",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38576"
},
{
"name": "CVE-2025-37800",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37800"
},
{
"name": "CVE-2025-37900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37900"
},
{
"name": "CVE-2025-38439",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38439"
},
{
"name": "CVE-2025-37805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37805"
},
{
"name": "CVE-2025-39719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39719"
},
{
"name": "CVE-2025-37990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37990"
},
{
"name": "CVE-2025-38553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38553"
},
{
"name": "CVE-2025-38190",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38190"
},
{
"name": "CVE-2025-38180",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38180"
},
{
"name": "CVE-2025-39738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39738"
},
{
"name": "CVE-2025-38145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38145"
},
{
"name": "CVE-2025-37948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37948"
},
{
"name": "CVE-2025-38166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38166"
},
{
"name": "CVE-2025-37862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37862"
},
{
"name": "CVE-2025-38321",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38321"
},
{
"name": "CVE-2025-39705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39705"
},
{
"name": "CVE-2025-37960",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37960"
},
{
"name": "CVE-2025-38045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38045"
},
{
"name": "CVE-2025-38051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38051"
},
{
"name": "CVE-2025-39713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39713"
},
{
"name": "CVE-2025-37763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37763"
},
{
"name": "CVE-2025-22128",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22128"
},
{
"name": "CVE-2025-37839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37839"
},
{
"name": "CVE-2025-39744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39744"
},
{
"name": "CVE-2025-38277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38277"
},
{
"name": "CVE-2025-37913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37913"
},
{
"name": "CVE-2025-39756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39756"
},
{
"name": "CVE-2025-38539",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38539"
},
{
"name": "CVE-2025-38044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38044"
},
{
"name": "CVE-2025-37786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37786"
},
{
"name": "CVE-2025-38200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38200"
},
{
"name": "CVE-2025-38480",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38480"
},
{
"name": "CVE-2025-38346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38346"
},
{
"name": "CVE-2025-37959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37959"
},
{
"name": "CVE-2025-38191",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38191"
},
{
"name": "CVE-2025-39946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39946"
},
{
"name": "CVE-2025-38062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38062"
},
{
"name": "CVE-2025-38531",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38531"
},
{
"name": "CVE-2025-39693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39693"
},
{
"name": "CVE-2025-38503",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38503"
},
{
"name": "CVE-2024-56593",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56593"
},
{
"name": "CVE-2025-38630",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38630"
},
{
"name": "CVE-2025-38131",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38131"
},
{
"name": "CVE-2025-37851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37851"
},
{
"name": "CVE-2025-38481",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38481"
},
{
"name": "CVE-2025-38585",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38585"
},
{
"name": "CVE-2025-38320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38320"
},
{
"name": "CVE-2025-38625",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38625"
},
{
"name": "CVE-2025-38164",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38164"
},
{
"name": "CVE-2025-38264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38264"
},
{
"name": "CVE-2025-39676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39676"
},
{
"name": "CVE-2025-37980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37980"
},
{
"name": "CVE-2025-38280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38280"
},
{
"name": "CVE-2025-37788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37788"
},
{
"name": "CVE-2025-38427",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38427"
},
{
"name": "CVE-2025-38084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38084"
},
{
"name": "CVE-2025-37879",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37879"
},
{
"name": "CVE-2025-38217",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38217"
},
{
"name": "CVE-2025-37881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37881"
},
{
"name": "CVE-2025-38103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38103"
},
{
"name": "CVE-2025-38514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38514"
},
{
"name": "CVE-2025-39783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39783"
},
{
"name": "CVE-2025-39715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39715"
},
{
"name": "CVE-2025-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38569"
},
{
"name": "CVE-2025-38255",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38255"
},
{
"name": "CVE-2025-38512",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38512"
},
{
"name": "CVE-2025-38622",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38622"
},
{
"name": "CVE-2025-37909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37909"
},
{
"name": "CVE-2025-38700",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38700"
},
{
"name": "CVE-2025-37849",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37849"
},
{
"name": "CVE-2025-38162",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38162"
},
{
"name": "CVE-2025-38532",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38532"
},
{
"name": "CVE-2025-39712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39712"
},
{
"name": "CVE-2025-37812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37812"
},
{
"name": "CVE-2025-39707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39707"
},
{
"name": "CVE-2025-37875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37875"
},
{
"name": "CVE-2025-38410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38410"
},
{
"name": "CVE-2025-39781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39781"
},
{
"name": "CVE-2025-38640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38640"
},
{
"name": "CVE-2025-38476",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38476"
},
{
"name": "CVE-2025-38659",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38659"
},
{
"name": "CVE-2025-38020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38020"
},
{
"name": "CVE-2025-38572",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38572"
},
{
"name": "CVE-2025-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23140"
},
{
"name": "CVE-2025-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23150"
},
{
"name": "CVE-2025-38460",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38460"
},
{
"name": "CVE-2025-38182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38182"
},
{
"name": "CVE-2025-38550",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38550"
},
{
"name": "CVE-2025-38275",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38275"
},
{
"name": "CVE-2025-38345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38345"
},
{
"name": "CVE-2025-38170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38170"
},
{
"name": "CVE-2025-39711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39711"
},
{
"name": "CVE-2025-22115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22115"
},
{
"name": "CVE-2025-22120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22120"
},
{
"name": "CVE-2025-38535",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38535"
},
{
"name": "CVE-2022-49267",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49267"
},
{
"name": "CVE-2025-38231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38231"
},
{
"name": "CVE-2025-37854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37854"
},
{
"name": "CVE-2025-38473",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38473"
},
{
"name": "CVE-2025-38113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38113"
},
{
"name": "CVE-2025-38714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38714"
},
{
"name": "CVE-2025-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23148"
},
{
"name": "CVE-2025-38361",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38361"
},
{
"name": "CVE-2025-38470",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38470"
},
{
"name": "CVE-2025-38181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38181"
},
{
"name": "CVE-2025-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38391"
},
{
"name": "CVE-2025-38248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38248"
},
{
"name": "CVE-2025-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23147"
},
{
"name": "CVE-2025-39752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39752"
}
],
"initial_release_date": "2026-03-06T00:00:00",
"last_revision_date": "2026-03-06T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-0246",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-03-06T00:00:00.000000"
}
],
"risks": [
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Ex\u00e9cution de code arbitraire"
},
{
"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 ex\u00e9cution de code arbitraire, une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es et une atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu LSN-0118-1",
"url": "https://ubuntu.com/security/notices/LSN-0118-1"
},
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8070-1",
"url": "https://ubuntu.com/security/notices/USN-8070-1"
},
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8059-7",
"url": "https://ubuntu.com/security/notices/USN-8059-7"
},
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8060-5",
"url": "https://ubuntu.com/security/notices/USN-8060-5"
},
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8074-1",
"url": "https://ubuntu.com/security/notices/USN-8074-1"
},
{
"published_at": "2026-03-03",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7990-6",
"url": "https://ubuntu.com/security/notices/USN-7990-6"
},
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8070-2",
"url": "https://ubuntu.com/security/notices/USN-8070-2"
},
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8070-3",
"url": "https://ubuntu.com/security/notices/USN-8070-3"
},
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8074-2",
"url": "https://ubuntu.com/security/notices/USN-8074-2"
},
{
"published_at": "2026-03-04",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-8060-6",
"url": "https://ubuntu.com/security/notices/USN-8060-6"
}
]
}
FKIE_CVE-2025-37991
Vulnerability from fkie_nvd - Published: 2025-05-20 18:15 - Updated: 2026-06-17 09:15| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/757ba4d17b868482837c566cfefca59e2296c608 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/cf21e890f56b7d0038ddaf25224e4f4c69ecd143 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/de3629baf5a33af1919dec7136d643b0662e85ef | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/df3592e493d7f29bae4ffde9a9325de50ddf962e | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/ec4584495868bd465fe60a3f771915c0e7ce7951 | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html | Third Party Advisory |
| 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.15 | |
| linux | linux_kernel | 6.15 | |
| linux | linux_kernel | 6.15 | |
| linux | linux_kernel | 6.15 | |
| debian | debian_linux | 11.0 |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"arch/parisc/math-emu/driver.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "757ba4d17b868482837c566cfefca59e2296c608",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "ec4584495868bd465fe60a3f771915c0e7ce7951",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "6c639af49e9e5615a8395981eaf5943fb40acd6f",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "6a098c51d18ec99485668da44294565c43dbc106",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "cf21e890f56b7d0038ddaf25224e4f4c69ecd143",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "df3592e493d7f29bae4ffde9a9325de50ddf962e",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "de3629baf5a33af1919dec7136d643b0662e85ef",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"arch/parisc/math-emu/driver.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "2.6.12"
},
{
"lessThan": "2.6.12",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.294",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.238",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.182",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.138",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.90",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.28",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.14.*",
"status": "unaffected",
"version": "6.14.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.15",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "093AFCC1-07FE-4A32-A1F0-9B1F9197071E",
"versionEndExcluding": "5.4.294",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "0DAAEF7F-D560-47FC-8B65-20404DB82432",
"versionEndExcluding": "5.10.238",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "57E76AE8-79D9-4EC8-9845-9A86B1ED152E",
"versionEndExcluding": "5.15.182",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "B6266F82-46B4-4D38-AC4A-54C92A1DFAB2",
"versionEndExcluding": "6.1.138",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2BE1DB09-2D62-4C63-AF19-947300669741",
"versionEndExcluding": "6.6.90",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "5082CE19-0F3D-4521-AB3E-810D8255F500",
"versionEndExcluding": "6.12.28",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "19E5095E-5950-43EA-8E78-FC860855293F",
"versionEndExcluding": "6.14.6",
"versionStartIncluding": "6.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.15:rc1:*:*:*:*:*:*",
"matchCriteriaId": "8D465631-2980-487A-8E65-40AE2B9F8ED1",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.15:rc2:*:*:*:*:*:*",
"matchCriteriaId": "4C9D071F-B28E-46EC-AC61-22B913390211",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.15:rc3:*:*:*:*:*:*",
"matchCriteriaId": "13FC0DDE-E513-465E-9E81-515702D49B74",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:6.15:rc4:*:*:*:*:*:*",
"matchCriteriaId": "8C7B5B0E-4EEB-48F5-B4CF-0935A7633845",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
},
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:debian:debian_linux:11.0:*:*:*:*:*:*:*",
"matchCriteriaId": "FA6FEEC2-9F11-4643-8827-749718254FED",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler. Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0. The latter cancels all pending traps. Let\u0027s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n sigset_t set;\n sigemptyset(\u0026set);\n sigaddset(\u0026set, SIGFPE);\n sigprocmask(SIG_UNBLOCK, \u0026set, NULL);\n printf(\"GOT signal %d with si_code %ld\\n\", sig, i-\u003esi_code);\n}\n\nint main() {\n struct sigaction action = {\n .sa_sigaction = fpe_func,\n .sa_flags = SA_RESTART|SA_SIGINFO };\n sigaction(SIGFPE, \u0026action, 0);\n feenableexcept(FE_OVERFLOW);\n return printf(\"%lf\\n\",1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\"./a.out\", [\"./a.out\"], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception"
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: parisc: Se corrige el doble fallo de SIGFPE Camm not\u00f3 que en parisc una excepci\u00f3n SIGFPE bloquear\u00e1 una aplicaci\u00f3n con un segundo SIGFPE en el manejador de se\u00f1ales. Dave lo analiz\u00f3 y sucede porque glibc usa un almac\u00e9n de punto flotante de doble palabra para actualizar at\u00f3micamente los descriptores de funci\u00f3n. Como resultado del enlace diferido, llegamos a un almac\u00e9n de punto flotante en fpe_func casi inmediatamente. Cuando se establece el bit T, se produce una trampa de excepci\u00f3n de asistencia cuando el coprocesador encuentra *cualquier* instrucci\u00f3n de punto flotante excepto un almac\u00e9n doble del registro %fr0. Este \u00faltimo cancela todas las trampas pendientes. Arreglemos esto borrando el bit Trap (T) en el registro de estado FP antes de regresar al manejador de se\u00f1ales en el espacio de usuario. El problema se puede reproducir con este programa de prueba: root@parisc:~# cat fpe.c static void fpe_func(int sig, siginfo_t *i, void *v) { sigset_t set; sigemptyset(\u0026amp;set); sigaddset(\u0026amp;set, SIGFPE); sigprocmask(SIG_UNBLOCK, \u0026amp;set, NULL); printf(\"Se\u00f1al GOT %d con c\u00f3digo si %ld\\n\", sig, i-\u0026gt;c\u00f3digo si); } int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, \u0026amp;action, 0); feenableexcept(FE_OVERFLOW); return printf(\"%lf\\n\",1.7976931348623158E308*1.7976931348623158E308); } root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Excepci\u00f3n de punto flotante root@parisc:~# strace -f ./a.out execve(\"./a.out\", [\"./a.out\"], 0xf9ac7034 /* 20 variables */) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ eliminado por SIGFPE +++ Excepci\u00f3n de punto flotante"
}
],
"id": "CVE-2025-37991",
"lastModified": "2026-06-17T09:15:50.220",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "LOCAL",
"availabilityImpact": "HIGH",
"baseScore": 7.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 1.8,
"impactScore": 5.9,
"source": "nvd@nist.gov",
"type": "Primary"
}
]
},
"published": "2025-05-20T18:15:45.997",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/757ba4d17b868482837c566cfefca59e2296c608"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/cf21e890f56b7d0038ddaf25224e4f4c69ecd143"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/de3629baf5a33af1919dec7136d643b0662e85ef"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/df3592e493d7f29bae4ffde9a9325de50ddf962e"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/ec4584495868bd465fe60a3f771915c0e7ce7951"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Third Party Advisory"
],
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-415"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
}
]
}
GHSA-XP2H-P3FR-J2J5
Vulnerability from github – Published: 2025-05-20 18:30 – Updated: 2025-12-16 21:30In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix double SIGFPE crash
Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.
When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.
The issue can be reproduced with this test program:
root@parisc:~# cat fpe.c
static void fpe_func(int sig, siginfo_t i, void v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); }
int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }
root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception
root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 / 20 vars /) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception
{
"affected": [],
"aliases": [
"CVE-2025-37991"
],
"database_specific": {
"cwe_ids": [
"CWE-415"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T18:15:45Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler. Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0. The latter cancels all pending traps. Let\u0027s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n sigset_t set;\n sigemptyset(\u0026set);\n sigaddset(\u0026set, SIGFPE);\n sigprocmask(SIG_UNBLOCK, \u0026set, NULL);\n printf(\"GOT signal %d with si_code %ld\\n\", sig, i-\u003esi_code);\n}\n\nint main() {\n struct sigaction action = {\n .sa_sigaction = fpe_func,\n .sa_flags = SA_RESTART|SA_SIGINFO };\n sigaction(SIGFPE, \u0026action, 0);\n feenableexcept(FE_OVERFLOW);\n return printf(\"%lf\\n\",1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\"./a.out\", [\"./a.out\"], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception",
"id": "GHSA-xp2h-p3fr-j2j5",
"modified": "2025-12-16T21:30:49Z",
"published": "2025-05-20T18:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37991"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2a1aff3616b3b57aa4a5f8a7762cce1e82493fe6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6a098c51d18ec99485668da44294565c43dbc106"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6c639af49e9e5615a8395981eaf5943fb40acd6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/757ba4d17b868482837c566cfefca59e2296c608"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cf21e890f56b7d0038ddaf25224e4f4c69ecd143"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/de3629baf5a33af1919dec7136d643b0662e85ef"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/df3592e493d7f29bae4ffde9a9325de50ddf962e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ec4584495868bd465fe60a3f771915c0e7ce7951"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00010.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
oesa-2025-1823
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
arm64: Don't call NULL in do_compat_alignment_fixup()
do_alignment_t32_to_handler() only fixes up alignment faults for specific instructions; it returns NULL otherwise (e.g. LDREX). When that's the case, signal to the caller that it needs to proceed with the regular alignment fault handling (i.e. SIGBUS). Without this patch, the kernel panics:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000 [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] SMP Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa> libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c> CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1 Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : do_compat_alignment_fixup+0xd8/0x3dc sp : ffff80000f973dd0 x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001 x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000 x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001 Call trace: 0x0 do_alignment_fault+0x40/0x50 do_mem_abort+0x4c/0xa0 el0_da+0x48/0xf0 el0t_32_sync_handler+0x110/0x140 el0t_32_sync+0x190/0x194 Code: bad PC value ---[ end trace 0000000000000000 ]---(CVE-2025-22033)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses
Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where "accepting" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT and a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory.
The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.
============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted
include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]
stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>(CVE-2025-23141)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()
syzbot reports an UBSAN issue as below:
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10 index 18446744073709550692 is out of range for type '__le32[5]' (aka 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 get_nid fs/f2fs/node.h:381 [inline] f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886 f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093 aio_write+0x56b/0x7c0 fs/aio.c:1633 io_submit_one+0x8a7/0x18a0 fs/aio.c:2052 __do_sys_io_submit fs/aio.c:2111 [inline] __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081 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 RIP: 0033:0x7f238798cde9
index 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long)
In f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to access .i_nid[-924], it means both offset[0] and level should zero.
The possible case should be in f2fs_do_truncate_blocks(), we try to truncate inode size to zero, however, dn.ofs_in_node is zero and dn.node_page is not an inode page, so it fails to truncate inode page, and then pass zeroed free_from to f2fs_truncate_inode_blocks(), result in this issue.
if (dn.ofs_in_node || IS_INODE(dn.node_page)) {
f2fs_truncate_data_blocks_range(&dn, count);
free_from += count;
}
I guess the reason why dn.node_page is not an inode page could be: there are multiple nat entries share the same node block address, once the node block address was reused, f2fs_get_node_page() may load a non-inode block.
Let's add a sanity check for such condition to avoid out-of-bounds access issue.(CVE-2025-37739)
In the Linux kernel, the following vulnerability has been resolved:
net: ti: icss-iep: Fix possible NULL pointer dereference for perout request
The ICSS IEP driver tracks perout and pps enable state with flags. Currently when disabling pps and perout signals during icss_iep_exit(), results in NULL pointer dereference for perout.
To fix the null pointer dereference issue, the icss_iep_perout_enable_hw function can be modified to directly clear the IEP CMP registers when disabling PPS or PEROUT, without referencing the ptp_perout_request structure, as its contents are irrelevant in this case.(CVE-2025-37784)
In the Linux kernel, the following vulnerability has been resolved:
crypto: null - Use spin lock instead of mutex
As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm.(CVE-2025-37808)
In the Linux kernel, the following vulnerability has been resolved:
spi: fsl-qspi: use devm function instead of driver remove
Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence.
Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind(CVE-2025-37842)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix mode1 reset crash issue
If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM.
There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash.
To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs.(CVE-2025-37854)
In the Linux kernel, the following vulnerability has been resolved:
pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result
If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the "devlink dev info" devlink command.
This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array.
Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails.(CVE-2025-37887)
In the Linux kernel, the following vulnerability has been resolved:
octeon_ep: Fix host hang issue during device reboot
When the host loses heartbeat messages from the device, the driver calls the device-specific ndo_stop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndo_stop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, dev_close should be called instead of the device-specific stop function.dev_close internally calls ndo_stop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndo_stop is not called.(CVE-2025-37933)
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Add job to pending list if the reset was skipped
When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete.
However, when timedout_job() is called, the job in question is removed
from the pending list, which means it won't be automatically freed through
free_job(). Consequently, when we skip the reset and keep the job
running, the job won't be freed when it finally completes.
This situation leads to a memory leak, as exposed in [1] and 2.
Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout.(CVE-2025-37951)
In the Linux kernel, the following vulnerability has been resolved:
iio: light: opt3001: fix deadlock due to concurrent flag access
The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock.
Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages.(CVE-2025-37968)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()
Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8):
X / 8 + !!(X & 7)
Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and use it in lieu of DIV_ROUND_UP() for ->key_size() return values.
Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes" parameter is a ->key_size() return value in some instances, or a user-specified ASN.1 length in the case of ecdsa_get_signature_rs().(CVE-2025-37984)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix double SIGFPE crash
Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.
When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.
The issue can be reproduced with this test program:
root@parisc:~# cat fpe.c
static void fpe_func(int sig, siginfo_t i, void v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); }
int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }
root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception
root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 / 20 vars /) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception(CVE-2025-37991)
In the Linux kernel, the following vulnerability has been resolved:
nfs: handle failure of nfs_get_lock_context in unlock path
When memory is insufficient, the allocation of nfs_lock_context in nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM) as valid and proceed to execute rpc_run_task(), this will trigger a NULL pointer dereference in nfs4_locku_prepare. For example:
BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpc_async_schedule RIP: 0010:nfs4_locku_prepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: <TASK> __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]---
Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and return NULL to terminate subsequent rpc_run_task, preventing NULL pointer dereference.(CVE-2025-38023)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios
A kernel crash was observed when replacing free hugetlb folios:
BUG: kernel NULL pointer dereference, address: 0000000000000028 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 28 UID: 0 PID: 29639 Comm: test_cma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntary) RIP: 0010:alloc_and_dissolve_hugetlb_folio+0x1d/0x1f0 RSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000342cca RCX: ffffea0043000000 RDX: ffffc9000b30fb08 RSI: ffffea0043000000 RDI: 0000000000000000 RBP: ffffc9000b30fb20 R08: 0000000000001000 R09: 0000000000000000 R10: ffff88886f92eb00 R11: 0000000000000000 R12: ffffea0043000000 R13: 0000000000000000 R14: 00000000010c0200 R15: 0000000000000004 FS: 00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000391402000 CR4: 0000000000350ef0 Call Trace: <TASK> replace_free_hugepage_folios+0xb6/0x100 alloc_contig_range_noprof+0x18a/0x590 ? srso_return_thunk+0x5/0x5f ? down_read+0x12/0xa0 ? srso_return_thunk+0x5/0x5f cma_range_alloc.constprop.0+0x131/0x290 __cma_alloc+0xcf/0x2c0 cma_alloc_write+0x43/0xb0 simple_attr_write_xsigned.constprop.0.isra.0+0xb2/0x110 debugfs_attr_write+0x46/0x70 full_proxy_write+0x62/0xa0 vfs_write+0xf8/0x420 ? srso_return_thunk+0x5/0x5f ? filp_flush+0x86/0xa0 ? srso_return_thunk+0x5/0x5f ? filp_close+0x1f/0x30 ? srso_return_thunk+0x5/0x5f ? do_dup2+0xaf/0x160 ? srso_return_thunk+0x5/0x5f ksys_write+0x65/0xe0 do_syscall_64+0x64/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
There is a potential race between __update_and_free_hugetlb_folio() and replace_free_hugepage_folios():
CPU1 CPU2 __update_and_free_hugetlb_folio replace_free_hugepage_folios folio_test_hugetlb(folio) -- It's still hugetlb folio.
__folio_clear_hugetlb(folio) hugetlb_free_folio(folio) h = folio_hstate(folio) -- Here, h is NULL pointer
When the above race condition occurs, folio_hstate(folio) returns NULL, and subsequent access to this NULL pointer will cause the system to crash. To resolve this issue, execute folio_hstate(folio) under the protection of the hugetlb_lock lock, ensuring that folio_hstate(folio) does not return NULL.(CVE-2025-38050)
In the Linux kernel, the following vulnerability has been resolved:
rseq: Fix segfault on registration when rseq_cs is non-zero
The rseq_cs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseq_cs field doesn't point to a valid struct rseq_cs.
The correct solution to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseq_cs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseq_cs does point to a valid struct rseq_cs.
What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation.(CVE-2025-38067)
In the Linux kernel, the following vulnerability has been resolved:
libnvdimm/labels: Fix divide error in nd_label_data_init()
If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver:
Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]
Code and flow:
1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver):
drivers/cxl/pmem.c: .config_size = mds->lsa_size,
3) max_xfer is set to zero (nvdimm driver):
drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);
4) A subsequent DIV_ROUND_UP() causes a division by zero:
drivers/nvdimm/label.c: / Make our initial read size a multiple of max_xfer size / drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size);
Fix this by checking the config size parameter by extending an existing check.(CVE-2025-38072)
In the Linux kernel, the following vulnerability has been resolved:
spi-rockchip: Fix register out of bounds access
Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense.(CVE-2025-38081)
In the Linux kernel, the following vulnerability has been resolved:
drivers/rapidio/rio_cm.c: prevent possible heap overwrite
In
riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send()
cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated.
Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace.(CVE-2025-38090)
In the Linux kernel, the following vulnerability has been resolved:
net: cadence: macb: Fix a possible deadlock in macb_halt_tx.
There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock.
That deadlock was noticed on a sama5d4 device that stayed locked for days.
Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.(CVE-2025-38094)
In the Linux kernel, the following vulnerability has been resolved:
dma-buf: insert memory barrier before updating num_fences
smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered.(CVE-2025-38095)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken
A SCO connection without the proper voice_setting can cause the controller to lock up.(CVE-2025-38099)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: red: fix a race in __red_change()
Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 [1]: lock root
[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.(CVE-2025-38108)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete
This reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to avoid crashes like bellow:
================================================================== BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341
CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #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 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
Allocated by task 5987: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252 mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279 remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x548/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 5989: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2380 [inline] slab_free mm/slub.c:4642 [inline] kfree+0x18e/0x440 mm/slub.c:4841 mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242 mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314 __sys_bind_socket net/socket.c:1810 [inline] __sys_bind+0x2c3/0x3e0 net/socket.c:1841 __do_sys_bind net/socket.c:1846 [inline] __se_sys_bind net/socket.c:1844 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1844 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38118)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (asus-ec-sensors) check sensor index in read_string()
Prevent a potential invalid memory access when the requested sensor is not found.
find_ec_sensor_index() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to get_sensor_info().
Add a proper check to return -EINVAL if sensor_index is negative.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
groeck: Return error code returned from find_ec_sensor_index
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Fix the dead loop of MPLS parse
The unexpected MPLS packet may not end with the bottom label stack. When there are many stacks, The label count value has wrapped around. A dead loop occurs, soft lockup/CPU stuck finally.
stack backtrace: UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26 index -1 is out of range for type '__be32 [3]' CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021 Call Trace: <IRQ> show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0 </IRQ>(CVE-2025-38146)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds
Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads 5 bytes:
void rtw_fw_bt_wifi_control(struct rtw_dev rtwdev, u8 op_code, u8 data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, (data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));
Detected using the static analysis tool - Svace.(CVE-2025-38159)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on sbi->total_valid_block_count
syzbot reported a f2fs bug as below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94
The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.(CVE-2025-38163)
In the Linux kernel, the following vulnerability has been resolved:
arm64/fpsimd: Discard stale CPU state when handling SME traps
The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set:
| / With TIF_SME userspace shouldn't generate any traps / | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1);
This is very similar to the SVE issue we fixed in commit:
751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")
The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g.
| void do_sme_acc(unsigned long esr, struct pt_regs regs) | { | // Trap on CPU 0 with TIF_SME clear, SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | / With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | }
Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.
Note: this was originallly posted as [1].
Rutland: rewrite commit message
In the Linux kernel, the following vulnerability has been resolved:
ublk: santizize the arguments from userspace when adding a device
Sanity check the values for queue depth and number of queues we get from userspace when adding a device.(CVE-2025-38182)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()
ERROR INFO:
CPU 25 Unable to handle kernel paging request at virtual address 0x0 ... Call Trace: [<900000000023c30c>] huge_pte_offset+0x3c/0x58 [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438 [<900000000051fee8>] __get_user_pages+0xe0/0x4c8 [<9000000000522414>] faultin_page_range+0x84/0x380 [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48 [<900000000056689c>] do_madvise+0x1bc/0x3e8 [<9000000000566df4>] sys_madvise+0x24/0x38 [<90000000015b9e88>] do_syscall+0x78/0x98 [<9000000000221f18>] handle_syscall+0xb8/0x158
In some cases, pmd may be NULL and rely on NULL as the return value for processing, so it is necessary to determine this situation here.(CVE-2025-38195)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()
bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check.(CVE-2025-38202)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"kernel-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"kernel-source-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"perf-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"python3-perf-6.6.0-100.0.0.92.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-100.0.0.92.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-100.0.0.92.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"kernel-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"kernel-source-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"perf-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"python3-perf-6.6.0-100.0.0.92.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-100.0.0.92.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-100.0.0.92.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: Don\u0026apos;t call NULL in do_compat_alignment_fixup()\n\ndo_alignment_t32_to_handler() only fixes up alignment faults for\nspecific instructions; it returns NULL otherwise (e.g. LDREX). When\nthat\u0026apos;s the case, signal to the caller that it needs to proceed with the\nregular alignment fault handling (i.e. SIGBUS). Without this patch, the\nkernel panics:\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Mem abort info:\n ESR = 0x0000000086000006\n EC = 0x21: IABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x06: level 2 translation fault\n user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000\n [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000\n Internal error: Oops: 0000000086000006 [#1] SMP\n Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa\u0026gt;\n libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c\u0026gt;\n CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1\n Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021\n pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : 0x0\n lr : do_compat_alignment_fixup+0xd8/0x3dc\n sp : ffff80000f973dd0\n x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000\n x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001\n x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000\n x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001\n Call trace:\n 0x0\n do_alignment_fault+0x40/0x50\n do_mem_abort+0x4c/0xa0\n el0_da+0x48/0xf0\n el0t_32_sync_handler+0x110/0x140\n el0t_32_sync+0x190/0x194\n Code: bad PC value\n ---[ end trace 0000000000000000 ]---(CVE-2025-22033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses\n\nAcquire a lock on kvm-\u0026gt;srcu when userspace is getting MP state to handle a\nrather extreme edge case where \u0026quot;accepting\u0026quot; APIC events, i.e. processing\npending INIT or SIPI, can trigger accesses to guest memory. If the vCPU\nis in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP\nstate will trigger a nested VM-Exit by way of -\u0026gt;check_nested_events(), and\nemuating the nested VM-Exit can access guest memory.\n\nThe splat was originally hit by syzkaller on a Google-internal kernel, and\nreproduced on an upstream kernel by hacking the triple_fault_event_test\nselftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a\nmemory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.\n\n =============================\n WARNING: suspicious RCU usage\n 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!\n\n other info that might help us debug this:\n\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by triple_fault_ev/1256:\n #0: ffff88810df5a330 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]\n\n stack backtrace:\n CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7f/0x90\n lockdep_rcu_suspicious+0x144/0x190\n kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]\n kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n read_and_check_msr_entry+0x2e/0x180 [kvm_intel]\n __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]\n kvm_check_nested_events+0x1b/0x30 [kvm]\n kvm_apic_accept_events+0x33/0x100 [kvm]\n kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]\n kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]\n __x64_sys_ioctl+0x8b/0xb0\n do_syscall_64+0x6c/0x170\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;(CVE-2025-23141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()\n\nsyzbot reports an UBSAN issue as below:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10\nindex 18446744073709550692 is out of range for type \u0026apos;__le32[5]\u0026apos; (aka \u0026apos;unsigned int[5]\u0026apos;)\nCPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0\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 ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429\n get_nid fs/f2fs/node.h:381 [inline]\n f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181\n f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808\n f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836\n f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886\n f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093\n aio_write+0x56b/0x7c0 fs/aio.c:1633\n io_submit_one+0x8a7/0x18a0 fs/aio.c:2052\n __do_sys_io_submit fs/aio.c:2111 [inline]\n __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081\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\nRIP: 0033:0x7f238798cde9\n\nindex 18446744073709550692 (decimal, unsigned long long)\n= 0xfffffffffffffc64 (hexadecimal, unsigned long long)\n= -924 (decimal, long long)\n\nIn f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to\naccess .i_nid[-924], it means both offset[0] and level should zero.\n\nThe possible case should be in f2fs_do_truncate_blocks(), we try to\ntruncate inode size to zero, however, dn.ofs_in_node is zero and\ndn.node_page is not an inode page, so it fails to truncate inode page,\nand then pass zeroed free_from to f2fs_truncate_inode_blocks(), result\nin this issue.\n\n\tif (dn.ofs_in_node || IS_INODE(dn.node_page)) {\n\t\tf2fs_truncate_data_blocks_range(\u0026amp;dn, count);\n\t\tfree_from += count;\n\t}\n\nI guess the reason why dn.node_page is not an inode page could be: there\nare multiple nat entries share the same node block address, once the node\nblock address was reused, f2fs_get_node_page() may load a non-inode block.\n\nLet\u0026apos;s add a sanity check for such condition to avoid out-of-bounds access\nissue.(CVE-2025-37739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ti: icss-iep: Fix possible NULL pointer dereference for perout request\n\nThe ICSS IEP driver tracks perout and pps enable state with flags.\nCurrently when disabling pps and perout signals during icss_iep_exit(),\nresults in NULL pointer dereference for perout.\n\nTo fix the null pointer dereference issue, the icss_iep_perout_enable_hw\nfunction can be modified to directly clear the IEP CMP registers when\ndisabling PPS or PEROUT, without referencing the ptp_perout_request\nstructure, as its contents are irrelevant in this case.(CVE-2025-37784)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: null - Use spin lock instead of mutex\n\nAs the null algorithm may be freed in softirq context through\naf_alg, use spin locks instead of mutexes to protect the default\nnull algorithm.(CVE-2025-37808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fsl-qspi: use devm function instead of driver remove\n\nDriver use devm APIs to manage clk/irq/resources and register the spi\ncontroller, but the legacy remove function will be called first during\ndevice detach and trigger kernel panic. Drop the remove function and use\ndevm_add_action_or_reset() for driver cleanup to ensure the release\nsequence.\n\nTrigger kernel panic on i.MX8MQ by\necho 30bb0000.spi \u0026gt;/sys/bus/platform/drivers/fsl-quadspi/unbind(CVE-2025-37842)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix mode1 reset crash issue\n\nIf HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal\nuser space to abort the processes. After process abort exit, user queues\nstill use the GPU to access system memory before h/w is reset while KFD\ncleanup worker free system memory and free VRAM.\n\nThere is use-after-free race bug that KFD allocate and reuse the freed\nsystem memory, and user queue write to the same system memory to corrupt\nthe data structure and cause driver crash.\n\nTo fix this race, KFD cleanup worker terminate user queues, then flush\nreset_domain wq to wait for any GPU ongoing reset complete, and then\nfree outstanding BOs.(CVE-2025-37854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result\n\nIf the FW doesn\u0026apos;t support the PDS_CORE_CMD_FW_CONTROL command\nthe driver might at the least print garbage and at the worst\ncrash when the user runs the \u0026quot;devlink dev info\u0026quot; devlink command.\n\nThis happens because the stack variable fw_list is not 0\ninitialized which results in fw_list.num_fw_slots being a\ngarbage value from the stack. Then the driver tries to access\nfw_list.fw_names[i] with i \u0026gt;= ARRAY_SIZE and runs off the end\nof the array.\n\nFix this by initializing the fw_list and by not failing\ncompletely if the devcmd fails because other useful information\nis printed via devlink dev info even if the devcmd fails.(CVE-2025-37887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteon_ep: Fix host hang issue during device reboot\n\nWhen the host loses heartbeat messages from the device,\nthe driver calls the device-specific ndo_stop function,\nwhich frees the resources. If the driver is unloaded in\nthis scenario, it calls ndo_stop again, attempting to free\nresources that have already been freed, leading to a host\nhang issue. To resolve this, dev_close should be called\ninstead of the device-specific stop function.dev_close\ninternally calls ndo_stop to stop the network interface\nand performs additional cleanup tasks. During the driver\nunload process, if the device is already down, ndo_stop\nis not called.(CVE-2025-37933)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Add job to pending list if the reset was skipped\n\nWhen a CL/CSD job times out, we check if the GPU has made any progress\nsince the last timeout. If so, instead of resetting the hardware, we skip\nthe reset and let the timer get rearmed. This gives long-running jobs a\nchance to complete.\n\nHowever, when `timedout_job()` is called, the job in question is removed\nfrom the pending list, which means it won\u0026apos;t be automatically freed through\n`free_job()`. Consequently, when we skip the reset and keep the job\nrunning, the job won\u0026apos;t be freed when it finally completes.\n\nThis situation leads to a memory leak, as exposed in [1] and [2].\n\nSimilarly to commit 704d3d60fec4 (\u0026quot;drm/etnaviv: don\u0026apos;t block scheduler when\nGPU is still active\u0026quot;), this patch ensures the job is put back on the\npending list when extending the timeout.(CVE-2025-37951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: light: opt3001: fix deadlock due to concurrent flag access\n\nThe threaded IRQ function in this driver is reading the flag twice: once to\nlock a mutex and once to unlock it. Even though the code setting the flag\nis designed to prevent it, there are subtle cases where the flag could be\ntrue at the mutex_lock stage and false at the mutex_unlock stage. This\nresults in the mutex not being unlocked, resulting in a deadlock.\n\nFix it by making the opt3001_irq() code generally more robust, reading the\nflag into a variable and using the variable value at both stages.(CVE-2025-37968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()\n\nHerbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa\nimplementation\u0026apos;s -\u0026gt;key_size() callback returns an unusually large value.\nHerbert instead suggests (for a division by 8):\n\n X / 8 + !!(X \u0026amp; 7)\n\nBased on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and\nuse it in lieu of DIV_ROUND_UP() for -\u0026gt;key_size() return values.\n\nAdditionally, use the macro in ecc_digits_from_bytes(), whose \u0026quot;nbytes\u0026quot;\nparameter is a -\u0026gt;key_size() return value in some instances, or a\nuser-specified ASN.1 length in the case of ecdsa_get_signature_rs().(CVE-2025-37984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler. Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0. The latter cancels all pending traps. Let\u0026apos;s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n sigset_t set;\n sigemptyset(\u0026amp;set);\n sigaddset(\u0026amp;set, SIGFPE);\n sigprocmask(SIG_UNBLOCK, \u0026amp;set, NULL);\n printf(\u0026quot;GOT signal %d with si_code %ld\\n\u0026quot;, sig, i-\u0026gt;si_code);\n}\n\nint main() {\n struct sigaction action = {\n .sa_sigaction = fpe_func,\n .sa_flags = SA_RESTART|SA_SIGINFO };\n sigaction(SIGFPE, \u0026amp;action, 0);\n feenableexcept(FE_OVERFLOW);\n return printf(\u0026quot;%lf\\n\u0026quot;,1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\u0026quot;./a.out\u0026quot;, [\u0026quot;./a.out\u0026quot;], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception(CVE-2025-37991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs: handle failure of nfs_get_lock_context in unlock path\n\nWhen memory is insufficient, the allocation of nfs_lock_context in\nnfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat\nan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)\nas valid and proceed to execute rpc_run_task(), this will trigger a NULL\npointer dereference in nfs4_locku_prepare. For example:\n\nBUG: kernel NULL pointer dereference, address: 000000000000000c\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP PTI\nCPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40\nWorkqueue: rpciod rpc_async_schedule\nRIP: 0010:nfs4_locku_prepare+0x35/0xc2\nCode: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3\nRSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246\nRAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40\nRBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38\nR10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030\nR13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30\nFS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __rpc_execute+0xbc/0x480\n rpc_async_schedule+0x2f/0x40\n process_one_work+0x232/0x5d0\n worker_thread+0x1da/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x10d/0x240\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\nCR2: 000000000000000c\n---[ end trace 0000000000000000 ]---\n\nFree the allocated nfs4_unlockdata when nfs_get_lock_context() fails and\nreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointer\ndereference.(CVE-2025-38023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios\n\nA kernel crash was observed when replacing free hugetlb folios:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000028\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 28 UID: 0 PID: 29639 Comm: test_cma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntary)\nRIP: 0010:alloc_and_dissolve_hugetlb_folio+0x1d/0x1f0\nRSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: 0000000000342cca RCX: ffffea0043000000\nRDX: ffffc9000b30fb08 RSI: ffffea0043000000 RDI: 0000000000000000\nRBP: ffffc9000b30fb20 R08: 0000000000001000 R09: 0000000000000000\nR10: ffff88886f92eb00 R11: 0000000000000000 R12: ffffea0043000000\nR13: 0000000000000000 R14: 00000000010c0200 R15: 0000000000000004\nFS: 00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000028 CR3: 0000000391402000 CR4: 0000000000350ef0\nCall Trace:\n\u0026lt;TASK\u0026gt;\n replace_free_hugepage_folios+0xb6/0x100\n alloc_contig_range_noprof+0x18a/0x590\n ? srso_return_thunk+0x5/0x5f\n ? down_read+0x12/0xa0\n ? srso_return_thunk+0x5/0x5f\n cma_range_alloc.constprop.0+0x131/0x290\n __cma_alloc+0xcf/0x2c0\n cma_alloc_write+0x43/0xb0\n simple_attr_write_xsigned.constprop.0.isra.0+0xb2/0x110\n debugfs_attr_write+0x46/0x70\n full_proxy_write+0x62/0xa0\n vfs_write+0xf8/0x420\n ? srso_return_thunk+0x5/0x5f\n ? filp_flush+0x86/0xa0\n ? srso_return_thunk+0x5/0x5f\n ? filp_close+0x1f/0x30\n ? srso_return_thunk+0x5/0x5f\n ? do_dup2+0xaf/0x160\n ? srso_return_thunk+0x5/0x5f\n ksys_write+0x65/0xe0\n do_syscall_64+0x64/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThere is a potential race between __update_and_free_hugetlb_folio() and\nreplace_free_hugepage_folios():\n\nCPU1 CPU2\n__update_and_free_hugetlb_folio replace_free_hugepage_folios\n folio_test_hugetlb(folio)\n -- It\u0026apos;s still hugetlb folio.\n\n __folio_clear_hugetlb(folio)\n hugetlb_free_folio(folio)\n h = folio_hstate(folio)\n -- Here, h is NULL pointer\n\nWhen the above race condition occurs, folio_hstate(folio) returns NULL,\nand subsequent access to this NULL pointer will cause the system to crash.\nTo resolve this issue, execute folio_hstate(folio) under the protection\nof the hugetlb_lock lock, ensuring that folio_hstate(folio) does not\nreturn NULL.(CVE-2025-38050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrseq: Fix segfault on registration when rseq_cs is non-zero\n\nThe rseq_cs field is documented as being set to 0 by user-space prior to\nregistration, however this is not currently enforced by the kernel. This\ncan result in a segfault on return to user-space if the value stored in\nthe rseq_cs field doesn\u0026apos;t point to a valid struct rseq_cs.\n\nThe correct solution to this would be to fail the rseq registration when\nthe rseq_cs field is non-zero. However, some older versions of glibc\nwill reuse the rseq area of previous threads without clearing the\nrseq_cs field and will also terminate the process if the rseq\nregistration fails in a secondary thread. This wasn\u0026apos;t caught in testing\nbecause in this case the leftover rseq_cs does point to a valid struct\nrseq_cs.\n\nWhat we can do is clear the rseq_cs field on registration when it\u0026apos;s\nnon-zero which will prevent segfaults on registration and won\u0026apos;t break\nthe glibc versions that reuse rseq areas on thread creation.(CVE-2025-38067)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibnvdimm/labels: Fix divide error in nd_label_data_init()\n\nIf a faulty CXL memory device returns a broken zero LSA size in its\nmemory device information (Identify Memory Device (Opcode 4000h), CXL\nspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm\ndriver:\n\n Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI\n RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]\n\nCode and flow:\n\n1) CXL Command 4000h returns LSA size = 0\n2) config_size is assigned to zero LSA size (CXL pmem driver):\n\ndrivers/cxl/pmem.c: .config_size = mds-\u0026gt;lsa_size,\n\n3) max_xfer is set to zero (nvdimm driver):\n\ndrivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd-\u0026gt;nsarea.max_xfer, config_size);\n\n4) A subsequent DIV_ROUND_UP() causes a division by zero:\n\ndrivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */\ndrivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,\ndrivers/nvdimm/label.c- config_size);\n\nFix this by checking the config size parameter by extending an\nexisting check.(CVE-2025-38072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi-rockchip: Fix register out of bounds access\n\nDo not write native chip select stuff for GPIO chip selects.\nGPIOs can be numbered much higher than native CS.\nAlso, it makes no sense.(CVE-2025-38081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/rapidio/rio_cm.c: prevent possible heap overwrite\n\nIn\n\nriocm_cdev_ioctl(RIO_CM_CHAN_SEND)\n -\u0026gt; cm_chan_msg_send()\n -\u0026gt; riocm_ch_send()\n\ncm_chan_msg_send() checks that userspace didn\u0026apos;t send too much data but\nriocm_ch_send() failed to check that userspace sent sufficient data. The\nresult is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr\nwhich were outside the bounds of the space which cm_chan_msg_send()\nallocated.\n\nAddress this by teaching riocm_ch_send() to check that the entire\nrio_ch_chan_hdr was copied in from userspace.(CVE-2025-38090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: cadence: macb: Fix a possible deadlock in macb_halt_tx.\n\nThere is a situation where after THALT is set high, TGO stays high as\nwell. Because jiffies are never updated, as we are in a context with\ninterrupts disabled, we never exit that loop and have a deadlock.\n\nThat deadlock was noticed on a sama5d4 device that stayed locked for days.\n\nUse retries instead of jiffies so that the timeout really works and we do\nnot have a deadlock anymore.(CVE-2025-38094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf: insert memory barrier before updating num_fences\n\nsmp_store_mb() inserts memory barrier after storing operation.\nIt is different with what the comment is originally aiming so Null\npointer dereference can be happened if memory update is reordered.(CVE-2025-38095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken\n\nA SCO connection without the proper voice_setting can cause\nthe controller to lock up.(CVE-2025-38099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: red: fix a race in __red_change()\n\nGerrard Tai reported a race condition in RED, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n | [5]: lock root\n | [6]: rehash\n | [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent\u0026apos;s qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.(CVE-2025-38108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete\n\nThis reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to\navoid crashes like bellow:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406\nRead of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341\n\nCPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #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\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xd2/0x2b0 mm/kasan/report.c:521\n kasan_report+0x118/0x150 mm/kasan/report.c:634\n mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406\n hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x711/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5987:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252\n mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279\n remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:727\n sock_write_iter+0x258/0x330 net/socket.c:1131\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x548/0xa90 fs/read_write.c:686\n ksys_write+0x145/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 5989:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2380 [inline]\n slab_free mm/slub.c:4642 [inline]\n kfree+0x18e/0x440 mm/slub.c:4841\n mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242\n mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366\n hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314\n __sys_bind_socket net/socket.c:1810 [inline]\n __sys_bind+0x2c3/0x3e0 net/socket.c:1841\n __do_sys_bind net/socket.c:1846 [inline]\n __se_sys_bind net/socket.c:1844 [inline]\n __x64_sys_bind+0x7a/0x90 net/socket.c:1844\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (asus-ec-sensors) check sensor index in read_string()\n\nPrevent a potential invalid memory access when the requested sensor\nis not found.\n\nfind_ec_sensor_index() may return a negative value (e.g. -ENOENT),\nbut its result was used without checking, which could lead to\nundefined behavior when passed to get_sensor_info().\n\nAdd a proper check to return -EINVAL if sensor_index is negative.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[groeck: Return error code returned from find_ec_sensor_index](CVE-2025-38142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: Fix the dead loop of MPLS parse\n\nThe unexpected MPLS packet may not end with the bottom label stack.\nWhen there are many stacks, The label count value has wrapped around.\nA dead loop occurs, soft lockup/CPU stuck finally.\n\nstack backtrace:\nUBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26\nindex -1 is out of range for type \u0026apos;__be32 [3]\u0026apos;\nCPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu\nHardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n show_stack+0x52/0x5c\n dump_stack_lvl+0x4a/0x63\n dump_stack+0x10/0x16\n ubsan_epilogue+0x9/0x36\n __ubsan_handle_out_of_bounds.cold+0x44/0x49\n key_extract_l3l4+0x82a/0x840 [openvswitch]\n ? kfree_skbmem+0x52/0xa0\n key_extract+0x9c/0x2b0 [openvswitch]\n ovs_flow_key_extract+0x124/0x350 [openvswitch]\n ovs_vport_receive+0x61/0xd0 [openvswitch]\n ? kernel_init_free_pages.part.0+0x4a/0x70\n ? get_page_from_freelist+0x353/0x540\n netdev_port_receive+0xc4/0x180 [openvswitch]\n ? netdev_port_receive+0x180/0x180 [openvswitch]\n netdev_frame_hook+0x1f/0x40 [openvswitch]\n __netif_receive_skb_core.constprop.0+0x23a/0xf00\n __netif_receive_skb_list_core+0xfa/0x240\n netif_receive_skb_list_internal+0x18e/0x2a0\n napi_complete_done+0x7a/0x1c0\n bnxt_poll+0x155/0x1c0 [bnxt_en]\n __napi_poll+0x30/0x180\n net_rx_action+0x126/0x280\n ? bnxt_msix+0x67/0x80 [bnxt_en]\n handle_softirqs+0xda/0x2d0\n irq_exit_rcu+0x96/0xc0\n common_interrupt+0x8e/0xa0\n \u0026lt;/IRQ\u0026gt;(CVE-2025-38146)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: fix the \u0026apos;para\u0026apos; buffer size to avoid reading out of bounds\n\nSet the size to 6 instead of 2, since \u0026apos;para\u0026apos; array is passed to\n\u0026apos;rtw_fw_bt_wifi_control(rtwdev, para[0], \u0026amp;para[1])\u0026apos;, which reads\n5 bytes:\n\nvoid rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)\n{\n ...\n SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);\n SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));\n ...\n SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));\n\nDetected using the static analysis tool - Svace.(CVE-2025-38159)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on sbi-\u0026gt;total_valid_block_count\n\nsyzbot reported a f2fs bug as below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/f2fs.h:2521!\nRIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521\nCall Trace:\n f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695\n truncate_dnode+0x417/0x740 fs/f2fs/node.c:973\n truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014\n f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197\n f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810\n f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838\n f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888\n f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112\n notify_change+0xbca/0xe90 fs/attr.c:552\n do_truncate+0x222/0x310 fs/open.c:65\n handle_truncate fs/namei.c:3466 [inline]\n do_open fs/namei.c:3849 [inline]\n path_openat+0x2e4f/0x35d0 fs/namei.c:4004\n do_filp_open+0x284/0x4e0 fs/namei.c:4031\n do_sys_openat2+0x12b/0x1d0 fs/open.c:1429\n do_sys_open fs/open.c:1444 [inline]\n __do_sys_creat fs/open.c:1522 [inline]\n __se_sys_creat fs/open.c:1516 [inline]\n __x64_sys_creat+0x124/0x170 fs/open.c:1516\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94\n\nThe reason is: in fuzzed image, sbi-\u0026gt;total_valid_block_count is\ninconsistent w/ mapped blocks indexed by inode, so, we should\nnot trigger panic for such case, instead, let\u0026apos;s print log and\nset fsck flag.(CVE-2025-38163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: Discard stale CPU state when handling SME traps\n\nThe logic for handling SME traps manipulates saved FPSIMD/SVE/SME state\nincorrectly, and a race with preemption can result in a task having\nTIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state\nis stale (e.g. with SME traps enabled). This can result in warnings from\ndo_sme_acc() where SME traps are not expected while TIF_SME is set:\n\n| /* With TIF_SME userspace shouldn\u0026apos;t generate any traps */\n| if (test_and_set_thread_flag(TIF_SME))\n| WARN_ON(1);\n\nThis is very similar to the SVE issue we fixed in commit:\n\n 751ecf6afd6568ad (\u0026quot;arm64/sve: Discard stale CPU state when handling SVE traps\u0026quot;)\n\nThe race can occur when the SME trap handler is preempted before and\nafter manipulating the saved FPSIMD/SVE/SME state, starting and ending on\nthe same CPU, e.g.\n\n| void do_sme_acc(unsigned long esr, struct pt_regs *regs)\n| {\n| // Trap on CPU 0 with TIF_SME clear, SME traps enabled\n| // task-\u0026gt;fpsimd_cpu is 0.\n| // per_cpu_ptr(\u0026amp;fpsimd_last_state, 0) is task.\n|\n| ...\n|\n| // Preempted; migrated from CPU 0 to CPU 1.\n| // TIF_FOREIGN_FPSTATE is set.\n|\n| get_cpu_fpsimd_context();\n|\n| /* With TIF_SME userspace shouldn\u0026apos;t generate any traps */\n| if (test_and_set_thread_flag(TIF_SME))\n| WARN_ON(1);\n|\n| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {\n| unsigned long vq_minus_one =\n| sve_vq_from_vl(task_get_sme_vl(current)) - 1;\n| sme_set_vq(vq_minus_one);\n|\n| fpsimd_bind_task_to_cpu();\n| }\n|\n| put_cpu_fpsimd_context();\n|\n| // Preempted; migrated from CPU 1 to CPU 0.\n| // task-\u0026gt;fpsimd_cpu is still 0\n| // If per_cpu_ptr(\u0026amp;fpsimd_last_state, 0) is still task then:\n| // - Stale HW state is reused (with SME traps enabled)\n| // - TIF_FOREIGN_FPSTATE is cleared\n| // - A return to userspace skips HW state restore\n| }\n\nFix the case where the state is not live and TIF_FOREIGN_FPSTATE is set\nby calling fpsimd_flush_task_state() to detach from the saved CPU\nstate. This ensures that a subsequent context switch will not reuse the\nstale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the\nnew state to be reloaded from memory prior to a return to userspace.\n\nNote: this was originallly posted as [1].\n\n[ Rutland: rewrite commit message ](CVE-2025-38170)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nublk: santizize the arguments from userspace when adding a device\n\nSanity check the values for queue depth and number of queues\nwe get from userspace when adding a device.(CVE-2025-38182)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()\n\nERROR INFO:\n\nCPU 25 Unable to handle kernel paging request at virtual address 0x0\n ...\n Call Trace:\n [\u0026lt;900000000023c30c\u0026gt;] huge_pte_offset+0x3c/0x58\n [\u0026lt;900000000057fd4c\u0026gt;] hugetlb_follow_page_mask+0x74/0x438\n [\u0026lt;900000000051fee8\u0026gt;] __get_user_pages+0xe0/0x4c8\n [\u0026lt;9000000000522414\u0026gt;] faultin_page_range+0x84/0x380\n [\u0026lt;9000000000564e8c\u0026gt;] madvise_vma_behavior+0x534/0xa48\n [\u0026lt;900000000056689c\u0026gt;] do_madvise+0x1bc/0x3e8\n [\u0026lt;9000000000566df4\u0026gt;] sys_madvise+0x24/0x38\n [\u0026lt;90000000015b9e88\u0026gt;] do_syscall+0x78/0x98\n [\u0026lt;9000000000221f18\u0026gt;] handle_syscall+0xb8/0x158\n\nIn some cases, pmd may be NULL and rely on NULL as the return value for\nprocessing, so it is necessary to determine this situation here.(CVE-2025-38195)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()\n\nbpf_map_lookup_percpu_elem() helper is also available for sleepable bpf\nprogram. When BPF JIT is disabled or under 32-bit host,\nbpf_map_lookup_percpu_elem() will not be inlined. Using it in a\nsleepable bpf program will trigger the warning in\nbpf_map_lookup_percpu_elem(), because the bpf program only holds\nrcu_read_lock_trace lock. Therefore, add the missed check.(CVE-2025-38202)",
"id": "OESA-2025-1823",
"modified": "2026-08-06T11:08:54Z",
"published": "2025-07-11T11:08:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1823"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22033"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23141"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37784"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37842"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37933"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38023"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38050"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38067"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38090"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38094"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38118"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38146"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38159"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38163"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38170"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38182"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38195"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38202"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-22033",
"CVE-2025-23141",
"CVE-2025-37739",
"CVE-2025-37784",
"CVE-2025-37808",
"CVE-2025-37842",
"CVE-2025-37854",
"CVE-2025-37887",
"CVE-2025-37933",
"CVE-2025-37951",
"CVE-2025-37968",
"CVE-2025-37984",
"CVE-2025-37991",
"CVE-2025-38023",
"CVE-2025-38050",
"CVE-2025-38067",
"CVE-2025-38072",
"CVE-2025-38081",
"CVE-2025-38090",
"CVE-2025-38094",
"CVE-2025-38095",
"CVE-2025-38099",
"CVE-2025-38108",
"CVE-2025-38118",
"CVE-2025-38142",
"CVE-2025-38146",
"CVE-2025-38159",
"CVE-2025-38163",
"CVE-2025-38170",
"CVE-2025-38182",
"CVE-2025-38195",
"CVE-2025-38202"
]
}
oesa-2025-1824
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
arm64: Don't call NULL in do_compat_alignment_fixup()
do_alignment_t32_to_handler() only fixes up alignment faults for specific instructions; it returns NULL otherwise (e.g. LDREX). When that's the case, signal to the caller that it needs to proceed with the regular alignment fault handling (i.e. SIGBUS). Without this patch, the kernel panics:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000 [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] SMP Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa> libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c> CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1 Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : do_compat_alignment_fixup+0xd8/0x3dc sp : ffff80000f973dd0 x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001 x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000 x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001 Call trace: 0x0 do_alignment_fault+0x40/0x50 do_mem_abort+0x4c/0xa0 el0_da+0x48/0xf0 el0t_32_sync_handler+0x110/0x140 el0t_32_sync+0x190/0x194 Code: bad PC value ---[ end trace 0000000000000000 ]---(CVE-2025-22033)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses
Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where "accepting" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT and a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory.
The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.
============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted
include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]
stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>(CVE-2025-23141)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()
syzbot reports an UBSAN issue as below:
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10 index 18446744073709550692 is out of range for type '__le32[5]' (aka 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 get_nid fs/f2fs/node.h:381 [inline] f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886 f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093 aio_write+0x56b/0x7c0 fs/aio.c:1633 io_submit_one+0x8a7/0x18a0 fs/aio.c:2052 __do_sys_io_submit fs/aio.c:2111 [inline] __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081 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 RIP: 0033:0x7f238798cde9
index 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long)
In f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to access .i_nid[-924], it means both offset[0] and level should zero.
The possible case should be in f2fs_do_truncate_blocks(), we try to truncate inode size to zero, however, dn.ofs_in_node is zero and dn.node_page is not an inode page, so it fails to truncate inode page, and then pass zeroed free_from to f2fs_truncate_inode_blocks(), result in this issue.
if (dn.ofs_in_node || IS_INODE(dn.node_page)) {
f2fs_truncate_data_blocks_range(&dn, count);
free_from += count;
}
I guess the reason why dn.node_page is not an inode page could be: there are multiple nat entries share the same node block address, once the node block address was reused, f2fs_get_node_page() may load a non-inode block.
Let's add a sanity check for such condition to avoid out-of-bounds access issue.(CVE-2025-37739)
In the Linux kernel, the following vulnerability has been resolved:
net: ti: icss-iep: Fix possible NULL pointer dereference for perout request
The ICSS IEP driver tracks perout and pps enable state with flags. Currently when disabling pps and perout signals during icss_iep_exit(), results in NULL pointer dereference for perout.
To fix the null pointer dereference issue, the icss_iep_perout_enable_hw function can be modified to directly clear the IEP CMP registers when disabling PPS or PEROUT, without referencing the ptp_perout_request structure, as its contents are irrelevant in this case.(CVE-2025-37784)
In the Linux kernel, the following vulnerability has been resolved:
crypto: null - Use spin lock instead of mutex
As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm.(CVE-2025-37808)
In the Linux kernel, the following vulnerability has been resolved:
spi: fsl-qspi: use devm function instead of driver remove
Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence.
Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind(CVE-2025-37842)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix mode1 reset crash issue
If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM.
There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash.
To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs.(CVE-2025-37854)
In the Linux kernel, the following vulnerability has been resolved:
pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result
If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the "devlink dev info" devlink command.
This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array.
Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails.(CVE-2025-37887)
In the Linux kernel, the following vulnerability has been resolved:
octeon_ep: Fix host hang issue during device reboot
When the host loses heartbeat messages from the device, the driver calls the device-specific ndo_stop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndo_stop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, dev_close should be called instead of the device-specific stop function.dev_close internally calls ndo_stop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndo_stop is not called.(CVE-2025-37933)
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Add job to pending list if the reset was skipped
When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete.
However, when timedout_job() is called, the job in question is removed
from the pending list, which means it won't be automatically freed through
free_job(). Consequently, when we skip the reset and keep the job
running, the job won't be freed when it finally completes.
This situation leads to a memory leak, as exposed in [1] and 2.
Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout.(CVE-2025-37951)
In the Linux kernel, the following vulnerability has been resolved:
iio: light: opt3001: fix deadlock due to concurrent flag access
The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock.
Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages.(CVE-2025-37968)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()
Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8):
X / 8 + !!(X & 7)
Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and use it in lieu of DIV_ROUND_UP() for ->key_size() return values.
Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes" parameter is a ->key_size() return value in some instances, or a user-specified ASN.1 length in the case of ecdsa_get_signature_rs().(CVE-2025-37984)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix double SIGFPE crash
Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.
When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.
The issue can be reproduced with this test program:
root@parisc:~# cat fpe.c
static void fpe_func(int sig, siginfo_t i, void v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); }
int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }
root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception
root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 / 20 vars /) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception(CVE-2025-37991)
In the Linux kernel, the following vulnerability has been resolved:
nfs: handle failure of nfs_get_lock_context in unlock path
When memory is insufficient, the allocation of nfs_lock_context in nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM) as valid and proceed to execute rpc_run_task(), this will trigger a NULL pointer dereference in nfs4_locku_prepare. For example:
BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpc_async_schedule RIP: 0010:nfs4_locku_prepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: <TASK> __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]---
Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and return NULL to terminate subsequent rpc_run_task, preventing NULL pointer dereference.(CVE-2025-38023)
In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios
A kernel crash was observed when replacing free hugetlb folios:
BUG: kernel NULL pointer dereference, address: 0000000000000028 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 28 UID: 0 PID: 29639 Comm: test_cma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntary) RIP: 0010:alloc_and_dissolve_hugetlb_folio+0x1d/0x1f0 RSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000342cca RCX: ffffea0043000000 RDX: ffffc9000b30fb08 RSI: ffffea0043000000 RDI: 0000000000000000 RBP: ffffc9000b30fb20 R08: 0000000000001000 R09: 0000000000000000 R10: ffff88886f92eb00 R11: 0000000000000000 R12: ffffea0043000000 R13: 0000000000000000 R14: 00000000010c0200 R15: 0000000000000004 FS: 00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000391402000 CR4: 0000000000350ef0 Call Trace: <TASK> replace_free_hugepage_folios+0xb6/0x100 alloc_contig_range_noprof+0x18a/0x590 ? srso_return_thunk+0x5/0x5f ? down_read+0x12/0xa0 ? srso_return_thunk+0x5/0x5f cma_range_alloc.constprop.0+0x131/0x290 __cma_alloc+0xcf/0x2c0 cma_alloc_write+0x43/0xb0 simple_attr_write_xsigned.constprop.0.isra.0+0xb2/0x110 debugfs_attr_write+0x46/0x70 full_proxy_write+0x62/0xa0 vfs_write+0xf8/0x420 ? srso_return_thunk+0x5/0x5f ? filp_flush+0x86/0xa0 ? srso_return_thunk+0x5/0x5f ? filp_close+0x1f/0x30 ? srso_return_thunk+0x5/0x5f ? do_dup2+0xaf/0x160 ? srso_return_thunk+0x5/0x5f ksys_write+0x65/0xe0 do_syscall_64+0x64/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e
There is a potential race between __update_and_free_hugetlb_folio() and replace_free_hugepage_folios():
CPU1 CPU2 __update_and_free_hugetlb_folio replace_free_hugepage_folios folio_test_hugetlb(folio) -- It's still hugetlb folio.
__folio_clear_hugetlb(folio) hugetlb_free_folio(folio) h = folio_hstate(folio) -- Here, h is NULL pointer
When the above race condition occurs, folio_hstate(folio) returns NULL, and subsequent access to this NULL pointer will cause the system to crash. To resolve this issue, execute folio_hstate(folio) under the protection of the hugetlb_lock lock, ensuring that folio_hstate(folio) does not return NULL.(CVE-2025-38050)
In the Linux kernel, the following vulnerability has been resolved:
rseq: Fix segfault on registration when rseq_cs is non-zero
The rseq_cs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseq_cs field doesn't point to a valid struct rseq_cs.
The correct solution to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseq_cs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseq_cs does point to a valid struct rseq_cs.
What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation.(CVE-2025-38067)
In the Linux kernel, the following vulnerability has been resolved:
libnvdimm/labels: Fix divide error in nd_label_data_init()
If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver:
Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]
Code and flow:
1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver):
drivers/cxl/pmem.c: .config_size = mds->lsa_size,
3) max_xfer is set to zero (nvdimm driver):
drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);
4) A subsequent DIV_ROUND_UP() causes a division by zero:
drivers/nvdimm/label.c: / Make our initial read size a multiple of max_xfer size / drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size);
Fix this by checking the config size parameter by extending an existing check.(CVE-2025-38072)
In the Linux kernel, the following vulnerability has been resolved:
spi-rockchip: Fix register out of bounds access
Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense.(CVE-2025-38081)
In the Linux kernel, the following vulnerability has been resolved:
drivers/rapidio/rio_cm.c: prevent possible heap overwrite
In
riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send()
cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated.
Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace.(CVE-2025-38090)
In the Linux kernel, the following vulnerability has been resolved:
net: cadence: macb: Fix a possible deadlock in macb_halt_tx.
There is a situation where after THALT is set high, TGO stays high as well. Because jiffies are never updated, as we are in a context with interrupts disabled, we never exit that loop and have a deadlock.
That deadlock was noticed on a sama5d4 device that stayed locked for days.
Use retries instead of jiffies so that the timeout really works and we do not have a deadlock anymore.(CVE-2025-38094)
In the Linux kernel, the following vulnerability has been resolved:
dma-buf: insert memory barrier before updating num_fences
smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered.(CVE-2025-38095)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken
A SCO connection without the proper voice_setting can cause the controller to lock up.(CVE-2025-38099)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: red: fix a race in __red_change()
Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time.
The race is as follows:
CPU 0 CPU 1 [1]: lock root
[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock.(CVE-2025-38108)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete
This reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to avoid crashes like bellow:
================================================================== BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 Read of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341
CPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #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 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406 hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334 process_one_work kernel/workqueue.c:3238 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402 kthread+0x711/0x8a0 kernel/kthread.c:464 ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK>
Allocated by task 5987: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252 mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279 remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 sock_write_iter+0x258/0x330 net/socket.c:1131 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x548/0xa90 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 5989: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2380 [inline] slab_free mm/slub.c:4642 [inline] kfree+0x18e/0x440 mm/slub.c:4841 mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242 mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314 __sys_bind_socket net/socket.c:1810 [inline] __sys_bind+0x2c3/0x3e0 net/socket.c:1841 __do_sys_bind net/socket.c:1846 [inline] __se_sys_bind net/socket.c:1844 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1844 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38118)
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (asus-ec-sensors) check sensor index in read_string()
Prevent a potential invalid memory access when the requested sensor is not found.
find_ec_sensor_index() may return a negative value (e.g. -ENOENT), but its result was used without checking, which could lead to undefined behavior when passed to get_sensor_info().
Add a proper check to return -EINVAL if sensor_index is negative.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
groeck: Return error code returned from find_ec_sensor_index
In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Fix the dead loop of MPLS parse
The unexpected MPLS packet may not end with the bottom label stack. When there are many stacks, The label count value has wrapped around. A dead loop occurs, soft lockup/CPU stuck finally.
stack backtrace: UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26 index -1 is out of range for type '__be32 [3]' CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu Hardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021 Call Trace: <IRQ> show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0 </IRQ>(CVE-2025-38146)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: fix the 'para' buffer size to avoid reading out of bounds
Set the size to 6 instead of 2, since 'para' array is passed to 'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads 5 bytes:
void rtw_fw_bt_wifi_control(struct rtw_dev rtwdev, u8 op_code, u8 data) { ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, (data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));
Detected using the static analysis tool - Svace.(CVE-2025-38159)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on sbi->total_valid_block_count
syzbot reported a f2fs bug as below:
------------[ cut here ]------------ kernel BUG at fs/f2fs/f2fs.h:2521! RIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521 Call Trace: f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695 truncate_dnode+0x417/0x740 fs/f2fs/node.c:973 truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014 f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197 f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888 f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112 notify_change+0xbca/0xe90 fs/attr.c:552 do_truncate+0x222/0x310 fs/open.c:65 handle_truncate fs/namei.c:3466 [inline] do_open fs/namei.c:3849 [inline] path_openat+0x2e4f/0x35d0 fs/namei.c:4004 do_filp_open+0x284/0x4e0 fs/namei.c:4031 do_sys_openat2+0x12b/0x1d0 fs/open.c:1429 do_sys_open fs/open.c:1444 [inline] __do_sys_creat fs/open.c:1522 [inline] __se_sys_creat fs/open.c:1516 [inline] __x64_sys_creat+0x124/0x170 fs/open.c:1516 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94
The reason is: in fuzzed image, sbi->total_valid_block_count is inconsistent w/ mapped blocks indexed by inode, so, we should not trigger panic for such case, instead, let's print log and set fsck flag.(CVE-2025-38163)
In the Linux kernel, the following vulnerability has been resolved:
arm64/fpsimd: Discard stale CPU state when handling SME traps
The logic for handling SME traps manipulates saved FPSIMD/SVE/SME state incorrectly, and a race with preemption can result in a task having TIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SME traps enabled). This can result in warnings from do_sme_acc() where SME traps are not expected while TIF_SME is set:
| / With TIF_SME userspace shouldn't generate any traps / | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1);
This is very similar to the SVE issue we fixed in commit:
751ecf6afd6568ad ("arm64/sve: Discard stale CPU state when handling SVE traps")
The race can occur when the SME trap handler is preempted before and after manipulating the saved FPSIMD/SVE/SME state, starting and ending on the same CPU, e.g.
| void do_sme_acc(unsigned long esr, struct pt_regs regs) | { | // Trap on CPU 0 with TIF_SME clear, SME traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | / With TIF_SME userspace shouldn't generate any traps */ | if (test_and_set_thread_flag(TIF_SME)) | WARN_ON(1); | | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | unsigned long vq_minus_one = | sve_vq_from_vl(task_get_sme_vl(current)) - 1; | sme_set_vq(vq_minus_one); | | fpsimd_bind_task_to_cpu(); | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SME traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | }
Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace.
Note: this was originallly posted as [1].
Rutland: rewrite commit message
In the Linux kernel, the following vulnerability has been resolved:
ublk: santizize the arguments from userspace when adding a device
Sanity check the values for queue depth and number of queues we get from userspace when adding a device.(CVE-2025-38182)
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()
ERROR INFO:
CPU 25 Unable to handle kernel paging request at virtual address 0x0 ... Call Trace: [<900000000023c30c>] huge_pte_offset+0x3c/0x58 [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438 [<900000000051fee8>] __get_user_pages+0xe0/0x4c8 [<9000000000522414>] faultin_page_range+0x84/0x380 [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48 [<900000000056689c>] do_madvise+0x1bc/0x3e8 [<9000000000566df4>] sys_madvise+0x24/0x38 [<90000000015b9e88>] do_syscall+0x78/0x98 [<9000000000221f18>] handle_syscall+0xb8/0x158
In some cases, pmd may be NULL and rely on NULL as the return value for processing, so it is necessary to determine this situation here.(CVE-2025-38195)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()
bpf_map_lookup_percpu_elem() helper is also available for sleepable bpf program. When BPF JIT is disabled or under 32-bit host, bpf_map_lookup_percpu_elem() will not be inlined. Using it in a sleepable bpf program will trigger the warning in bpf_map_lookup_percpu_elem(), because the bpf program only holds rcu_read_lock_trace lock. Therefore, add the missed check.(CVE-2025-38202)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"perf-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-100.0.0.103.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-100.0.0.103.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"perf-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-100.0.0.103.oe2403sp1.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-100.0.0.103.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: Don\u0026apos;t call NULL in do_compat_alignment_fixup()\n\ndo_alignment_t32_to_handler() only fixes up alignment faults for\nspecific instructions; it returns NULL otherwise (e.g. LDREX). When\nthat\u0026apos;s the case, signal to the caller that it needs to proceed with the\nregular alignment fault handling (i.e. SIGBUS). Without this patch, the\nkernel panics:\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Mem abort info:\n ESR = 0x0000000086000006\n EC = 0x21: IABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x06: level 2 translation fault\n user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000\n [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000\n Internal error: Oops: 0000000086000006 [#1] SMP\n Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa\u0026gt;\n libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c\u0026gt;\n CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1\n Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021\n pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : 0x0\n lr : do_compat_alignment_fixup+0xd8/0x3dc\n sp : ffff80000f973dd0\n x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000\n x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001\n x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000\n x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001\n Call trace:\n 0x0\n do_alignment_fault+0x40/0x50\n do_mem_abort+0x4c/0xa0\n el0_da+0x48/0xf0\n el0t_32_sync_handler+0x110/0x140\n el0t_32_sync+0x190/0x194\n Code: bad PC value\n ---[ end trace 0000000000000000 ]---(CVE-2025-22033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses\n\nAcquire a lock on kvm-\u0026gt;srcu when userspace is getting MP state to handle a\nrather extreme edge case where \u0026quot;accepting\u0026quot; APIC events, i.e. processing\npending INIT or SIPI, can trigger accesses to guest memory. If the vCPU\nis in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP\nstate will trigger a nested VM-Exit by way of -\u0026gt;check_nested_events(), and\nemuating the nested VM-Exit can access guest memory.\n\nThe splat was originally hit by syzkaller on a Google-internal kernel, and\nreproduced on an upstream kernel by hacking the triple_fault_event_test\nselftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a\nmemory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.\n\n =============================\n WARNING: suspicious RCU usage\n 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!\n\n other info that might help us debug this:\n\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by triple_fault_ev/1256:\n #0: ffff88810df5a330 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]\n\n stack backtrace:\n CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7f/0x90\n lockdep_rcu_suspicious+0x144/0x190\n kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]\n kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n read_and_check_msr_entry+0x2e/0x180 [kvm_intel]\n __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]\n kvm_check_nested_events+0x1b/0x30 [kvm]\n kvm_apic_accept_events+0x33/0x100 [kvm]\n kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]\n kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]\n __x64_sys_ioctl+0x8b/0xb0\n do_syscall_64+0x6c/0x170\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;(CVE-2025-23141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()\n\nsyzbot reports an UBSAN issue as below:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10\nindex 18446744073709550692 is out of range for type \u0026apos;__le32[5]\u0026apos; (aka \u0026apos;unsigned int[5]\u0026apos;)\nCPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0\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 ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429\n get_nid fs/f2fs/node.h:381 [inline]\n f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181\n f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808\n f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836\n f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886\n f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093\n aio_write+0x56b/0x7c0 fs/aio.c:1633\n io_submit_one+0x8a7/0x18a0 fs/aio.c:2052\n __do_sys_io_submit fs/aio.c:2111 [inline]\n __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081\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\nRIP: 0033:0x7f238798cde9\n\nindex 18446744073709550692 (decimal, unsigned long long)\n= 0xfffffffffffffc64 (hexadecimal, unsigned long long)\n= -924 (decimal, long long)\n\nIn f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to\naccess .i_nid[-924], it means both offset[0] and level should zero.\n\nThe possible case should be in f2fs_do_truncate_blocks(), we try to\ntruncate inode size to zero, however, dn.ofs_in_node is zero and\ndn.node_page is not an inode page, so it fails to truncate inode page,\nand then pass zeroed free_from to f2fs_truncate_inode_blocks(), result\nin this issue.\n\n\tif (dn.ofs_in_node || IS_INODE(dn.node_page)) {\n\t\tf2fs_truncate_data_blocks_range(\u0026amp;dn, count);\n\t\tfree_from += count;\n\t}\n\nI guess the reason why dn.node_page is not an inode page could be: there\nare multiple nat entries share the same node block address, once the node\nblock address was reused, f2fs_get_node_page() may load a non-inode block.\n\nLet\u0026apos;s add a sanity check for such condition to avoid out-of-bounds access\nissue.(CVE-2025-37739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ti: icss-iep: Fix possible NULL pointer dereference for perout request\n\nThe ICSS IEP driver tracks perout and pps enable state with flags.\nCurrently when disabling pps and perout signals during icss_iep_exit(),\nresults in NULL pointer dereference for perout.\n\nTo fix the null pointer dereference issue, the icss_iep_perout_enable_hw\nfunction can be modified to directly clear the IEP CMP registers when\ndisabling PPS or PEROUT, without referencing the ptp_perout_request\nstructure, as its contents are irrelevant in this case.(CVE-2025-37784)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: null - Use spin lock instead of mutex\n\nAs the null algorithm may be freed in softirq context through\naf_alg, use spin locks instead of mutexes to protect the default\nnull algorithm.(CVE-2025-37808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fsl-qspi: use devm function instead of driver remove\n\nDriver use devm APIs to manage clk/irq/resources and register the spi\ncontroller, but the legacy remove function will be called first during\ndevice detach and trigger kernel panic. Drop the remove function and use\ndevm_add_action_or_reset() for driver cleanup to ensure the release\nsequence.\n\nTrigger kernel panic on i.MX8MQ by\necho 30bb0000.spi \u0026gt;/sys/bus/platform/drivers/fsl-quadspi/unbind(CVE-2025-37842)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix mode1 reset crash issue\n\nIf HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal\nuser space to abort the processes. After process abort exit, user queues\nstill use the GPU to access system memory before h/w is reset while KFD\ncleanup worker free system memory and free VRAM.\n\nThere is use-after-free race bug that KFD allocate and reuse the freed\nsystem memory, and user queue write to the same system memory to corrupt\nthe data structure and cause driver crash.\n\nTo fix this race, KFD cleanup worker terminate user queues, then flush\nreset_domain wq to wait for any GPU ongoing reset complete, and then\nfree outstanding BOs.(CVE-2025-37854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result\n\nIf the FW doesn\u0026apos;t support the PDS_CORE_CMD_FW_CONTROL command\nthe driver might at the least print garbage and at the worst\ncrash when the user runs the \u0026quot;devlink dev info\u0026quot; devlink command.\n\nThis happens because the stack variable fw_list is not 0\ninitialized which results in fw_list.num_fw_slots being a\ngarbage value from the stack. Then the driver tries to access\nfw_list.fw_names[i] with i \u0026gt;= ARRAY_SIZE and runs off the end\nof the array.\n\nFix this by initializing the fw_list and by not failing\ncompletely if the devcmd fails because other useful information\nis printed via devlink dev info even if the devcmd fails.(CVE-2025-37887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteon_ep: Fix host hang issue during device reboot\n\nWhen the host loses heartbeat messages from the device,\nthe driver calls the device-specific ndo_stop function,\nwhich frees the resources. If the driver is unloaded in\nthis scenario, it calls ndo_stop again, attempting to free\nresources that have already been freed, leading to a host\nhang issue. To resolve this, dev_close should be called\ninstead of the device-specific stop function.dev_close\ninternally calls ndo_stop to stop the network interface\nand performs additional cleanup tasks. During the driver\nunload process, if the device is already down, ndo_stop\nis not called.(CVE-2025-37933)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Add job to pending list if the reset was skipped\n\nWhen a CL/CSD job times out, we check if the GPU has made any progress\nsince the last timeout. If so, instead of resetting the hardware, we skip\nthe reset and let the timer get rearmed. This gives long-running jobs a\nchance to complete.\n\nHowever, when `timedout_job()` is called, the job in question is removed\nfrom the pending list, which means it won\u0026apos;t be automatically freed through\n`free_job()`. Consequently, when we skip the reset and keep the job\nrunning, the job won\u0026apos;t be freed when it finally completes.\n\nThis situation leads to a memory leak, as exposed in [1] and [2].\n\nSimilarly to commit 704d3d60fec4 (\u0026quot;drm/etnaviv: don\u0026apos;t block scheduler when\nGPU is still active\u0026quot;), this patch ensures the job is put back on the\npending list when extending the timeout.(CVE-2025-37951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: light: opt3001: fix deadlock due to concurrent flag access\n\nThe threaded IRQ function in this driver is reading the flag twice: once to\nlock a mutex and once to unlock it. Even though the code setting the flag\nis designed to prevent it, there are subtle cases where the flag could be\ntrue at the mutex_lock stage and false at the mutex_unlock stage. This\nresults in the mutex not being unlocked, resulting in a deadlock.\n\nFix it by making the opt3001_irq() code generally more robust, reading the\nflag into a variable and using the variable value at both stages.(CVE-2025-37968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()\n\nHerbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa\nimplementation\u0026apos;s -\u0026gt;key_size() callback returns an unusually large value.\nHerbert instead suggests (for a division by 8):\n\n X / 8 + !!(X \u0026amp; 7)\n\nBased on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and\nuse it in lieu of DIV_ROUND_UP() for -\u0026gt;key_size() return values.\n\nAdditionally, use the macro in ecc_digits_from_bytes(), whose \u0026quot;nbytes\u0026quot;\nparameter is a -\u0026gt;key_size() return value in some instances, or a\nuser-specified ASN.1 length in the case of ecdsa_get_signature_rs().(CVE-2025-37984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler. Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0. The latter cancels all pending traps. Let\u0026apos;s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n sigset_t set;\n sigemptyset(\u0026amp;set);\n sigaddset(\u0026amp;set, SIGFPE);\n sigprocmask(SIG_UNBLOCK, \u0026amp;set, NULL);\n printf(\u0026quot;GOT signal %d with si_code %ld\\n\u0026quot;, sig, i-\u0026gt;si_code);\n}\n\nint main() {\n struct sigaction action = {\n .sa_sigaction = fpe_func,\n .sa_flags = SA_RESTART|SA_SIGINFO };\n sigaction(SIGFPE, \u0026amp;action, 0);\n feenableexcept(FE_OVERFLOW);\n return printf(\u0026quot;%lf\\n\u0026quot;,1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\u0026quot;./a.out\u0026quot;, [\u0026quot;./a.out\u0026quot;], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception(CVE-2025-37991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs: handle failure of nfs_get_lock_context in unlock path\n\nWhen memory is insufficient, the allocation of nfs_lock_context in\nnfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat\nan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)\nas valid and proceed to execute rpc_run_task(), this will trigger a NULL\npointer dereference in nfs4_locku_prepare. For example:\n\nBUG: kernel NULL pointer dereference, address: 000000000000000c\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP PTI\nCPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40\nWorkqueue: rpciod rpc_async_schedule\nRIP: 0010:nfs4_locku_prepare+0x35/0xc2\nCode: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3\nRSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246\nRAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40\nRBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38\nR10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030\nR13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30\nFS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __rpc_execute+0xbc/0x480\n rpc_async_schedule+0x2f/0x40\n process_one_work+0x232/0x5d0\n worker_thread+0x1da/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x10d/0x240\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\nCR2: 000000000000000c\n---[ end trace 0000000000000000 ]---\n\nFree the allocated nfs4_unlockdata when nfs_get_lock_context() fails and\nreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointer\ndereference.(CVE-2025-38023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix kernel NULL pointer dereference when replacing free hugetlb folios\n\nA kernel crash was observed when replacing free hugetlb folios:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000028\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 28 UID: 0 PID: 29639 Comm: test_cma.sh Tainted 6.15.0-rc6-zp #41 PREEMPT(voluntary)\nRIP: 0010:alloc_and_dissolve_hugetlb_folio+0x1d/0x1f0\nRSP: 0018:ffffc9000b30fa90 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: 0000000000342cca RCX: ffffea0043000000\nRDX: ffffc9000b30fb08 RSI: ffffea0043000000 RDI: 0000000000000000\nRBP: ffffc9000b30fb20 R08: 0000000000001000 R09: 0000000000000000\nR10: ffff88886f92eb00 R11: 0000000000000000 R12: ffffea0043000000\nR13: 0000000000000000 R14: 00000000010c0200 R15: 0000000000000004\nFS: 00007fcda5f14740(0000) GS:ffff8888ec1d8000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000028 CR3: 0000000391402000 CR4: 0000000000350ef0\nCall Trace:\n\u0026lt;TASK\u0026gt;\n replace_free_hugepage_folios+0xb6/0x100\n alloc_contig_range_noprof+0x18a/0x590\n ? srso_return_thunk+0x5/0x5f\n ? down_read+0x12/0xa0\n ? srso_return_thunk+0x5/0x5f\n cma_range_alloc.constprop.0+0x131/0x290\n __cma_alloc+0xcf/0x2c0\n cma_alloc_write+0x43/0xb0\n simple_attr_write_xsigned.constprop.0.isra.0+0xb2/0x110\n debugfs_attr_write+0x46/0x70\n full_proxy_write+0x62/0xa0\n vfs_write+0xf8/0x420\n ? srso_return_thunk+0x5/0x5f\n ? filp_flush+0x86/0xa0\n ? srso_return_thunk+0x5/0x5f\n ? filp_close+0x1f/0x30\n ? srso_return_thunk+0x5/0x5f\n ? do_dup2+0xaf/0x160\n ? srso_return_thunk+0x5/0x5f\n ksys_write+0x65/0xe0\n do_syscall_64+0x64/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThere is a potential race between __update_and_free_hugetlb_folio() and\nreplace_free_hugepage_folios():\n\nCPU1 CPU2\n__update_and_free_hugetlb_folio replace_free_hugepage_folios\n folio_test_hugetlb(folio)\n -- It\u0026apos;s still hugetlb folio.\n\n __folio_clear_hugetlb(folio)\n hugetlb_free_folio(folio)\n h = folio_hstate(folio)\n -- Here, h is NULL pointer\n\nWhen the above race condition occurs, folio_hstate(folio) returns NULL,\nand subsequent access to this NULL pointer will cause the system to crash.\nTo resolve this issue, execute folio_hstate(folio) under the protection\nof the hugetlb_lock lock, ensuring that folio_hstate(folio) does not\nreturn NULL.(CVE-2025-38050)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrseq: Fix segfault on registration when rseq_cs is non-zero\n\nThe rseq_cs field is documented as being set to 0 by user-space prior to\nregistration, however this is not currently enforced by the kernel. This\ncan result in a segfault on return to user-space if the value stored in\nthe rseq_cs field doesn\u0026apos;t point to a valid struct rseq_cs.\n\nThe correct solution to this would be to fail the rseq registration when\nthe rseq_cs field is non-zero. However, some older versions of glibc\nwill reuse the rseq area of previous threads without clearing the\nrseq_cs field and will also terminate the process if the rseq\nregistration fails in a secondary thread. This wasn\u0026apos;t caught in testing\nbecause in this case the leftover rseq_cs does point to a valid struct\nrseq_cs.\n\nWhat we can do is clear the rseq_cs field on registration when it\u0026apos;s\nnon-zero which will prevent segfaults on registration and won\u0026apos;t break\nthe glibc versions that reuse rseq areas on thread creation.(CVE-2025-38067)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibnvdimm/labels: Fix divide error in nd_label_data_init()\n\nIf a faulty CXL memory device returns a broken zero LSA size in its\nmemory device information (Identify Memory Device (Opcode 4000h), CXL\nspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm\ndriver:\n\n Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI\n RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]\n\nCode and flow:\n\n1) CXL Command 4000h returns LSA size = 0\n2) config_size is assigned to zero LSA size (CXL pmem driver):\n\ndrivers/cxl/pmem.c: .config_size = mds-\u0026gt;lsa_size,\n\n3) max_xfer is set to zero (nvdimm driver):\n\ndrivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd-\u0026gt;nsarea.max_xfer, config_size);\n\n4) A subsequent DIV_ROUND_UP() causes a division by zero:\n\ndrivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */\ndrivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,\ndrivers/nvdimm/label.c- config_size);\n\nFix this by checking the config size parameter by extending an\nexisting check.(CVE-2025-38072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi-rockchip: Fix register out of bounds access\n\nDo not write native chip select stuff for GPIO chip selects.\nGPIOs can be numbered much higher than native CS.\nAlso, it makes no sense.(CVE-2025-38081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/rapidio/rio_cm.c: prevent possible heap overwrite\n\nIn\n\nriocm_cdev_ioctl(RIO_CM_CHAN_SEND)\n -\u0026gt; cm_chan_msg_send()\n -\u0026gt; riocm_ch_send()\n\ncm_chan_msg_send() checks that userspace didn\u0026apos;t send too much data but\nriocm_ch_send() failed to check that userspace sent sufficient data. The\nresult is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr\nwhich were outside the bounds of the space which cm_chan_msg_send()\nallocated.\n\nAddress this by teaching riocm_ch_send() to check that the entire\nrio_ch_chan_hdr was copied in from userspace.(CVE-2025-38090)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: cadence: macb: Fix a possible deadlock in macb_halt_tx.\n\nThere is a situation where after THALT is set high, TGO stays high as\nwell. Because jiffies are never updated, as we are in a context with\ninterrupts disabled, we never exit that loop and have a deadlock.\n\nThat deadlock was noticed on a sama5d4 device that stayed locked for days.\n\nUse retries instead of jiffies so that the timeout really works and we do\nnot have a deadlock anymore.(CVE-2025-38094)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndma-buf: insert memory barrier before updating num_fences\n\nsmp_store_mb() inserts memory barrier after storing operation.\nIt is different with what the comment is originally aiming so Null\npointer dereference can be happened if memory update is reordered.(CVE-2025-38095)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/broken\n\nA SCO connection without the proper voice_setting can cause\nthe controller to lock up.(CVE-2025-38099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: red: fix a race in __red_change()\n\nGerrard Tai reported a race condition in RED, whenever SFQ perturb timer\nfires at the wrong time.\n\nThe race is as follows:\n\nCPU 0 CPU 1\n[1]: lock root\n[2]: qdisc_tree_flush_backlog()\n[3]: unlock root\n |\n | [5]: lock root\n | [6]: rehash\n | [7]: qdisc_tree_reduce_backlog()\n |\n[4]: qdisc_put()\n\nThis can be abused to underflow a parent\u0026apos;s qlen.\n\nCalling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()\nshould fix the race, because all packets will be purged from the qdisc\nbefore releasing the lock.(CVE-2025-38108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix UAF on mgmt_remove_adv_monitor_complete\n\nThis reworks MGMT_OP_REMOVE_ADV_MONITOR to not use mgmt_pending_add to\navoid crashes like bellow:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406\nRead of size 8 at addr ffff88801c53f318 by task kworker/u5:5/5341\n\nCPU: 0 UID: 0 PID: 5341 Comm: kworker/u5:5 Not tainted 6.15.0-syzkaller-10402-g4cb6c8af8591 #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\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xd2/0x2b0 mm/kasan/report.c:521\n kasan_report+0x118/0x150 mm/kasan/report.c:634\n mgmt_remove_adv_monitor_complete+0xe5/0x540 net/bluetooth/mgmt.c:5406\n hci_cmd_sync_work+0x261/0x3a0 net/bluetooth/hci_sync.c:334\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x711/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 5987:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4358\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n mgmt_pending_new+0x65/0x240 net/bluetooth/mgmt_util.c:252\n mgmt_pending_add+0x34/0x120 net/bluetooth/mgmt_util.c:279\n remove_adv_monitor+0x103/0x1b0 net/bluetooth/mgmt.c:5454\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:727\n sock_write_iter+0x258/0x330 net/socket.c:1131\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x548/0xa90 fs/read_write.c:686\n ksys_write+0x145/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 5989:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2380 [inline]\n slab_free mm/slub.c:4642 [inline]\n kfree+0x18e/0x440 mm/slub.c:4841\n mgmt_pending_foreach+0xc9/0x120 net/bluetooth/mgmt_util.c:242\n mgmt_index_removed+0x10d/0x2f0 net/bluetooth/mgmt.c:9366\n hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314\n __sys_bind_socket net/socket.c:1810 [inline]\n __sys_bind+0x2c3/0x3e0 net/socket.c:1841\n __do_sys_bind net/socket.c:1846 [inline]\n __se_sys_bind net/socket.c:1844 [inline]\n __x64_sys_bind+0x7a/0x90 net/socket.c:1844\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (asus-ec-sensors) check sensor index in read_string()\n\nPrevent a potential invalid memory access when the requested sensor\nis not found.\n\nfind_ec_sensor_index() may return a negative value (e.g. -ENOENT),\nbut its result was used without checking, which could lead to\nundefined behavior when passed to get_sensor_info().\n\nAdd a proper check to return -EINVAL if sensor_index is negative.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\n\n[groeck: Return error code returned from find_ec_sensor_index](CVE-2025-38142)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: Fix the dead loop of MPLS parse\n\nThe unexpected MPLS packet may not end with the bottom label stack.\nWhen there are many stacks, The label count value has wrapped around.\nA dead loop occurs, soft lockup/CPU stuck finally.\n\nstack backtrace:\nUBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26\nindex -1 is out of range for type \u0026apos;__be32 [3]\u0026apos;\nCPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-Ubuntu\nHardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n show_stack+0x52/0x5c\n dump_stack_lvl+0x4a/0x63\n dump_stack+0x10/0x16\n ubsan_epilogue+0x9/0x36\n __ubsan_handle_out_of_bounds.cold+0x44/0x49\n key_extract_l3l4+0x82a/0x840 [openvswitch]\n ? kfree_skbmem+0x52/0xa0\n key_extract+0x9c/0x2b0 [openvswitch]\n ovs_flow_key_extract+0x124/0x350 [openvswitch]\n ovs_vport_receive+0x61/0xd0 [openvswitch]\n ? kernel_init_free_pages.part.0+0x4a/0x70\n ? get_page_from_freelist+0x353/0x540\n netdev_port_receive+0xc4/0x180 [openvswitch]\n ? netdev_port_receive+0x180/0x180 [openvswitch]\n netdev_frame_hook+0x1f/0x40 [openvswitch]\n __netif_receive_skb_core.constprop.0+0x23a/0xf00\n __netif_receive_skb_list_core+0xfa/0x240\n netif_receive_skb_list_internal+0x18e/0x2a0\n napi_complete_done+0x7a/0x1c0\n bnxt_poll+0x155/0x1c0 [bnxt_en]\n __napi_poll+0x30/0x180\n net_rx_action+0x126/0x280\n ? bnxt_msix+0x67/0x80 [bnxt_en]\n handle_softirqs+0xda/0x2d0\n irq_exit_rcu+0x96/0xc0\n common_interrupt+0x8e/0xa0\n \u0026lt;/IRQ\u0026gt;(CVE-2025-38146)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: fix the \u0026apos;para\u0026apos; buffer size to avoid reading out of bounds\n\nSet the size to 6 instead of 2, since \u0026apos;para\u0026apos; array is passed to\n\u0026apos;rtw_fw_bt_wifi_control(rtwdev, para[0], \u0026amp;para[1])\u0026apos;, which reads\n5 bytes:\n\nvoid rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data)\n{\n ...\n SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data);\n SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1));\n ...\n SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));\n\nDetected using the static analysis tool - Svace.(CVE-2025-38159)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on sbi-\u0026gt;total_valid_block_count\n\nsyzbot reported a f2fs bug as below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/f2fs.h:2521!\nRIP: 0010:dec_valid_block_count+0x3b2/0x3c0 fs/f2fs/f2fs.h:2521\nCall Trace:\n f2fs_truncate_data_blocks_range+0xc8c/0x11a0 fs/f2fs/file.c:695\n truncate_dnode+0x417/0x740 fs/f2fs/node.c:973\n truncate_nodes+0x3ec/0xf50 fs/f2fs/node.c:1014\n f2fs_truncate_inode_blocks+0x8e3/0x1370 fs/f2fs/node.c:1197\n f2fs_do_truncate_blocks+0x840/0x12b0 fs/f2fs/file.c:810\n f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:838\n f2fs_truncate+0x417/0x720 fs/f2fs/file.c:888\n f2fs_setattr+0xc4f/0x12f0 fs/f2fs/file.c:1112\n notify_change+0xbca/0xe90 fs/attr.c:552\n do_truncate+0x222/0x310 fs/open.c:65\n handle_truncate fs/namei.c:3466 [inline]\n do_open fs/namei.c:3849 [inline]\n path_openat+0x2e4f/0x35d0 fs/namei.c:4004\n do_filp_open+0x284/0x4e0 fs/namei.c:4031\n do_sys_openat2+0x12b/0x1d0 fs/open.c:1429\n do_sys_open fs/open.c:1444 [inline]\n __do_sys_creat fs/open.c:1522 [inline]\n __se_sys_creat fs/open.c:1516 [inline]\n __x64_sys_creat+0x124/0x170 fs/open.c:1516\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/syscall_64.c:94\n\nThe reason is: in fuzzed image, sbi-\u0026gt;total_valid_block_count is\ninconsistent w/ mapped blocks indexed by inode, so, we should\nnot trigger panic for such case, instead, let\u0026apos;s print log and\nset fsck flag.(CVE-2025-38163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: Discard stale CPU state when handling SME traps\n\nThe logic for handling SME traps manipulates saved FPSIMD/SVE/SME state\nincorrectly, and a race with preemption can result in a task having\nTIF_SME set and TIF_FOREIGN_FPSTATE clear even though the live CPU state\nis stale (e.g. with SME traps enabled). This can result in warnings from\ndo_sme_acc() where SME traps are not expected while TIF_SME is set:\n\n| /* With TIF_SME userspace shouldn\u0026apos;t generate any traps */\n| if (test_and_set_thread_flag(TIF_SME))\n| WARN_ON(1);\n\nThis is very similar to the SVE issue we fixed in commit:\n\n 751ecf6afd6568ad (\u0026quot;arm64/sve: Discard stale CPU state when handling SVE traps\u0026quot;)\n\nThe race can occur when the SME trap handler is preempted before and\nafter manipulating the saved FPSIMD/SVE/SME state, starting and ending on\nthe same CPU, e.g.\n\n| void do_sme_acc(unsigned long esr, struct pt_regs *regs)\n| {\n| // Trap on CPU 0 with TIF_SME clear, SME traps enabled\n| // task-\u0026gt;fpsimd_cpu is 0.\n| // per_cpu_ptr(\u0026amp;fpsimd_last_state, 0) is task.\n|\n| ...\n|\n| // Preempted; migrated from CPU 0 to CPU 1.\n| // TIF_FOREIGN_FPSTATE is set.\n|\n| get_cpu_fpsimd_context();\n|\n| /* With TIF_SME userspace shouldn\u0026apos;t generate any traps */\n| if (test_and_set_thread_flag(TIF_SME))\n| WARN_ON(1);\n|\n| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {\n| unsigned long vq_minus_one =\n| sve_vq_from_vl(task_get_sme_vl(current)) - 1;\n| sme_set_vq(vq_minus_one);\n|\n| fpsimd_bind_task_to_cpu();\n| }\n|\n| put_cpu_fpsimd_context();\n|\n| // Preempted; migrated from CPU 1 to CPU 0.\n| // task-\u0026gt;fpsimd_cpu is still 0\n| // If per_cpu_ptr(\u0026amp;fpsimd_last_state, 0) is still task then:\n| // - Stale HW state is reused (with SME traps enabled)\n| // - TIF_FOREIGN_FPSTATE is cleared\n| // - A return to userspace skips HW state restore\n| }\n\nFix the case where the state is not live and TIF_FOREIGN_FPSTATE is set\nby calling fpsimd_flush_task_state() to detach from the saved CPU\nstate. This ensures that a subsequent context switch will not reuse the\nstale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the\nnew state to be reloaded from memory prior to a return to userspace.\n\nNote: this was originallly posted as [1].\n\n[ Rutland: rewrite commit message ](CVE-2025-38170)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nublk: santizize the arguments from userspace when adding a device\n\nSanity check the values for queue depth and number of queues\nwe get from userspace when adding a device.(CVE-2025-38182)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()\n\nERROR INFO:\n\nCPU 25 Unable to handle kernel paging request at virtual address 0x0\n ...\n Call Trace:\n [\u0026lt;900000000023c30c\u0026gt;] huge_pte_offset+0x3c/0x58\n [\u0026lt;900000000057fd4c\u0026gt;] hugetlb_follow_page_mask+0x74/0x438\n [\u0026lt;900000000051fee8\u0026gt;] __get_user_pages+0xe0/0x4c8\n [\u0026lt;9000000000522414\u0026gt;] faultin_page_range+0x84/0x380\n [\u0026lt;9000000000564e8c\u0026gt;] madvise_vma_behavior+0x534/0xa48\n [\u0026lt;900000000056689c\u0026gt;] do_madvise+0x1bc/0x3e8\n [\u0026lt;9000000000566df4\u0026gt;] sys_madvise+0x24/0x38\n [\u0026lt;90000000015b9e88\u0026gt;] do_syscall+0x78/0x98\n [\u0026lt;9000000000221f18\u0026gt;] handle_syscall+0xb8/0x158\n\nIn some cases, pmd may be NULL and rely on NULL as the return value for\nprocessing, so it is necessary to determine this situation here.(CVE-2025-38195)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check rcu_read_lock_trace_held() in bpf_map_lookup_percpu_elem()\n\nbpf_map_lookup_percpu_elem() helper is also available for sleepable bpf\nprogram. When BPF JIT is disabled or under 32-bit host,\nbpf_map_lookup_percpu_elem() will not be inlined. Using it in a\nsleepable bpf program will trigger the warning in\nbpf_map_lookup_percpu_elem(), because the bpf program only holds\nrcu_read_lock_trace lock. Therefore, add the missed check.(CVE-2025-38202)",
"id": "OESA-2025-1824",
"modified": "2026-08-06T11:08:54Z",
"published": "2025-07-11T11:08:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1824"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22033"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23141"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37784"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37842"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37933"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38023"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38050"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38067"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38090"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38094"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38118"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38146"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38159"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38163"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38170"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38182"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38195"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38202"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2025-22033",
"CVE-2025-23141",
"CVE-2025-37739",
"CVE-2025-37784",
"CVE-2025-37808",
"CVE-2025-37842",
"CVE-2025-37854",
"CVE-2025-37887",
"CVE-2025-37933",
"CVE-2025-37951",
"CVE-2025-37968",
"CVE-2025-37984",
"CVE-2025-37991",
"CVE-2025-38023",
"CVE-2025-38050",
"CVE-2025-38067",
"CVE-2025-38072",
"CVE-2025-38081",
"CVE-2025-38090",
"CVE-2025-38094",
"CVE-2025-38095",
"CVE-2025-38099",
"CVE-2025-38108",
"CVE-2025-38118",
"CVE-2025-38142",
"CVE-2025-38146",
"CVE-2025-38159",
"CVE-2025-38163",
"CVE-2025-38170",
"CVE-2025-38182",
"CVE-2025-38195",
"CVE-2025-38202"
]
}
oesa-2025-1870
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
crypto: iaa - Fix potential use after free bug
The free_device_compression_mode(iaa_device, device_mode) function frees "device_mode" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free.
The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)(CVE-2024-47732)
In the Linux kernel, the following vulnerability has been resolved:
mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()
If migration succeeded, we called folio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from the old to the new folio. This will set memcg_data of the old folio to 0.
Similarly, if migration failed, memcg_data of the dst folio is left unset.
If we call folio_putback_lru() on such folios (memcg_data == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests:
# ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80
Likely, nothing else goes wrong: putting the last folio reference will remove the folio from the LRU again. So besides memcg complaining, adding the folio to be freed to the LRU is just an unnecessary step.
The new flow resembles what we have in migrate_folio_move(): add the dst to the lru, rem ---truncated---(CVE-2025-21861)
In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()
On the off chance that command stream passed from userspace via ioctl() call to radeon_vce_cs_parse() is weirdly crafted and first command to execute is to encode (case 0x03000001), the function in question will attempt to call radeon_vce_cs_reloc() with size argument that has not been properly initialized. Specifically, 'size' will point to 'tmp' variable before the latter had a chance to be assigned any value.
Play it safe and init 'tmp' with 0, thus ensuring that radeon_vce_cs_reloc() will catch an early error in cases like these.
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)(CVE-2025-21996)
In the Linux kernel, the following vulnerability has been resolved:
arm64: Don't call NULL in do_compat_alignment_fixup()
do_alignment_t32_to_handler() only fixes up alignment faults for specific instructions; it returns NULL otherwise (e.g. LDREX). When that's the case, signal to the caller that it needs to proceed with the regular alignment fault handling (i.e. SIGBUS). Without this patch, the kernel panics:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000006 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000 [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] SMP Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa> libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c> CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1 Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : do_compat_alignment_fixup+0xd8/0x3dc sp : ffff80000f973dd0 x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001 x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000 x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001 Call trace: 0x0 do_alignment_fault+0x40/0x50 do_mem_abort+0x4c/0xa0 el0_da+0x48/0xf0 el0t_32_sync_handler+0x110/0x140 el0t_32_sync+0x190/0x194 Code: bad PC value ---[ end trace 0000000000000000 ]---(CVE-2025-22033)
In the Linux kernel, the following vulnerability has been resolved:
net: libwx: fix Tx L4 checksum
The hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol. There was a bug to set Tx checksum flag for the other protocol that results in Tx ring hang. Fix to compute software checksum for these packets.(CVE-2025-22101)
In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Mask the bd_cnt field in the TX BD properly
The bd_cnt field in the TX BD specifies the total number of BDs for the TX packet. The bd_cnt field has 5 bits and the maximum number supported is 32 with the value 0.
CONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB fragments can approach or exceed the maximum supported by the chip. Add a macro to properly mask the bd_cnt field so that the value 32 will be properly masked and set to 0 in the bd_cnd field.
Without this patch, the out-of-range bd_cnt value will corrupt the TX BD and may cause TX timeout.
The next patch will check for values exceeding 32.(CVE-2025-22108)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses
Acquire a lock on kvm->srcu when userspace is getting MP state to handle a rather extreme edge case where "accepting" APIC events, i.e. processing pending INIT or SIPI, can trigger accesses to guest memory. If the vCPU is in L2 with INIT and a TRIPLE_FAULT request pending, then getting MP state will trigger a nested VM-Exit by way of ->check_nested_events(), and emuating the nested VM-Exit can access guest memory.
The splat was originally hit by syzkaller on a Google-internal kernel, and reproduced on an upstream kernel by hacking the triple_fault_event_test selftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a memory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.
============================= WARNING: suspicious RCU usage 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted
include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1 1 lock held by triple_fault_ev/1256: #0: ffff88810df5a330 (&vcpu->mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]
stack backtrace: CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dump_stack_lvl+0x7f/0x90 lockdep_rcu_suspicious+0x144/0x190 kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm] kvm_vcpu_read_guest+0x3e/0x90 [kvm] read_and_check_msr_entry+0x2e/0x180 [kvm_intel] __nested_vmx_vmexit+0x550/0xde0 [kvm_intel] kvm_check_nested_events+0x1b/0x30 [kvm] kvm_apic_accept_events+0x33/0x100 [kvm] kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm] kvm_vcpu_ioctl+0x33e/0x9a0 [kvm] __x64_sys_ioctl+0x8b/0xb0 do_syscall_64+0x6c/0x170 entry_SYSCALL_64_after_hwframe+0x4b/0x53 </TASK>(CVE-2025-23141)
In the Linux kernel, the following vulnerability has been resolved:
tpm: do not start chip while suspended
Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can lead to a spurious tpm_chip_start() call:
[35985.503771] i2c i2c-1: Transfer while suspended [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810 [35985.503802] Modules linked in: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Tainted: [W]=WARN [35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810 [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Call Trace: [35985.503859] <TASK> [35985.503863] ? __warn+0xd4/0x260 [35985.503868] ? __i2c_transfer+0xbe/0x810 [35985.503874] ? report_bug+0xf3/0x210 [35985.503882] ? handle_bug+0x63/0xb0 [35985.503887] ? exc_invalid_op+0x16/0x50 [35985.503892] ? asm_exc_invalid_op+0x16/0x20 [35985.503904] ? __i2c_transfer+0xbe/0x810 [35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0 [35985.503920] tpm_cr50_i2c_read+0x8e/0x120 [35985.503928] tpm_cr50_request_locality+0x75/0x170 [35985.503935] tpm_chip_start+0x116/0x160 [35985.503942] tpm_try_get_ops+0x57/0x90 [35985.503948] tpm_find_get_ops+0x26/0xd0 [35985.503955] tpm_get_random+0x2d/0x80
Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in such a failure case.(CVE-2025-23149)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()
syzbot reports an UBSAN issue as below:
------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10 index 18446744073709550692 is out of range for type '__le32[5]' (aka 'unsigned int[5]') CPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429 get_nid fs/f2fs/node.h:381 [inline] f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181 f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808 f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836 f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886 f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093 aio_write+0x56b/0x7c0 fs/aio.c:1633 io_submit_one+0x8a7/0x18a0 fs/aio.c:2052 __do_sys_io_submit fs/aio.c:2111 [inline] __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081 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 RIP: 0033:0x7f238798cde9
index 18446744073709550692 (decimal, unsigned long long) = 0xfffffffffffffc64 (hexadecimal, unsigned long long) = -924 (decimal, long long)
In f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to access .i_nid[-924], it means both offset[0] and level should zero.
The possible case should be in f2fs_do_truncate_blocks(), we try to truncate inode size to zero, however, dn.ofs_in_node is zero and dn.node_page is not an inode page, so it fails to truncate inode page, and then pass zeroed free_from to f2fs_truncate_inode_blocks(), result in this issue.
if (dn.ofs_in_node || IS_INODE(dn.node_page)) {
f2fs_truncate_data_blocks_range(&dn, count);
free_from += count;
}
I guess the reason why dn.node_page is not an inode page could be: there are multiple nat entries share the same node block address, once the node block address was reused, f2fs_get_node_page() may load a non-inode block.
Let's add a sanity check for such condition to avoid out-of-bounds access issue.(CVE-2025-37739)
In the Linux kernel, the following vulnerability has been resolved:
net: ti: icss-iep: Fix possible NULL pointer dereference for perout request
The ICSS IEP driver tracks perout and pps enable state with flags. Currently when disabling pps and perout signals during icss_iep_exit(), results in NULL pointer dereference for perout.
To fix the null pointer dereference issue, the icss_iep_perout_enable_hw function can be modified to directly clear the IEP CMP registers when disabling PPS or PEROUT, without referencing the ptp_perout_request structure, as its contents are irrelevant in this case.(CVE-2025-37784)
In the Linux kernel, the following vulnerability has been resolved:
crypto: null - Use spin lock instead of mutex
As the null algorithm may be freed in softirq context through af_alg, use spin locks instead of mutexes to protect the default null algorithm.(CVE-2025-37808)
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: check that event count does not exceed event buffer length
The event count is read from register DWC3_GEVNTCOUNT. There is a check for the count being zero, but not for exceeding the event buffer length. Check that event count does not exceed event buffer length, avoiding an out-of-bounds access when memcpy'ing the event. Crash log: Unable to handle kernel paging request at virtual address ffffffc0129be000 pc : __memcpy+0x114/0x180 lr : dwc3_check_event_buf+0xec/0x348 x3 : 0000000000000030 x2 : 000000000000dfc4 x1 : ffffffc0129be000 x0 : ffffff87aad60080 Call trace: __memcpy+0x114/0x180 dwc3_interrupt+0x24/0x34(CVE-2025-37810)
In the Linux kernel, the following vulnerability has been resolved:
spi: fsl-qspi: use devm function instead of driver remove
Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence.
Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind(CVE-2025-37842)
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Tear down vGIC on failed vCPU creation
If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.
Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error.(CVE-2025-37849)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix mode1 reset crash issue
If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal user space to abort the processes. After process abort exit, user queues still use the GPU to access system memory before h/w is reset while KFD cleanup worker free system memory and free VRAM.
There is use-after-free race bug that KFD allocate and reuse the freed system memory, and user queue write to the same system memory to corrupt the data structure and cause driver crash.
To fix this race, KFD cleanup worker terminate user queues, then flush reset_domain wq to wait for any GPU ongoing reset complete, and then free outstanding BOs.(CVE-2025-37854)
In the Linux kernel, the following vulnerability has been resolved:
pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result
If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the "devlink dev info" devlink command.
This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array.
Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails.(CVE-2025-37887)
In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()
Nouveau is mostly designed in a way that it's expected that fences only ever get signaled through nouveau_fence_signal(). However, in at least one other place, nouveau_fence_done(), can signal fences, too. If that happens (race) a signaled fence remains in the pending list for a while, until it gets removed by nouveau_fence_update().
Should nouveau_fence_context_kill() run in the meantime, this would be a bug because the function would attempt to set an error code on an already signaled fence.
Have nouveau_fence_context_kill() check for a fence being signaled.(CVE-2025-37930)
In the Linux kernel, the following vulnerability has been resolved:
octeon_ep: Fix host hang issue during device reboot
When the host loses heartbeat messages from the device, the driver calls the device-specific ndo_stop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndo_stop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, dev_close should be called instead of the device-specific stop function.dev_close internally calls ndo_stop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndo_stop is not called.(CVE-2025-37933)
In the Linux kernel, the following vulnerability has been resolved:
objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()
If dib8000_set_dds()'s call to dib8000_read32() returns zero, the result is a divide-by-zero. Prevent that from happening.
Fixes the following warning with an UBSAN kernel:
drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()(CVE-2025-37937)
In the Linux kernel, the following vulnerability has been resolved:
arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs
A malicious BPF program may manipulate the branch history to influence what the hardware speculates will happen next.
On exit from a BPF program, emit the BHB mititgation sequence.
This is only applied for 'classic' cBPF programs that are loaded by seccomp.(CVE-2025-37948)
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Add job to pending list if the reset was skipped
When a CL/CSD job times out, we check if the GPU has made any progress since the last timeout. If so, instead of resetting the hardware, we skip the reset and let the timer get rearmed. This gives long-running jobs a chance to complete.
However, when timedout_job() is called, the job in question is removed
from the pending list, which means it won't be automatically freed through
free_job(). Consequently, when we skip the reset and keep the job
running, the job won't be freed when it finally completes.
This situation leads to a memory leak, as exposed in [1] and [2].
Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler when GPU is still active"), this patch ensures the job is put back on the pending list when extending the timeout.(CVE-2025-37951)
In the Linux kernel, the following vulnerability has been resolved:
arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users
Support for eBPF programs loaded by unprivileged users is typically disabled. This means only cBPF programs need to be mitigated for BHB.
In addition, only mitigate cBPF programs that were loaded by an unprivileged user. Privileged users can also load the same program via eBPF, making the mitigation pointless.(CVE-2025-37963)
In the Linux kernel, the following vulnerability has been resolved:
iio: light: opt3001: fix deadlock due to concurrent flag access
The threaded IRQ function in this driver is reading the flag twice: once to lock a mutex and once to unlock it. Even though the code setting the flag is designed to prevent it, there are subtle cases where the flag could be true at the mutex_lock stage and false at the mutex_unlock stage. This results in the mutex not being unlocked, resulting in a deadlock.
Fix it by making the opt3001_irq() code generally more robust, reading the flag into a variable and using the variable value at both stages.(CVE-2025-37968)
In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()
Herbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa implementation's ->key_size() callback returns an unusually large value. Herbert instead suggests (for a division by 8):
X / 8 + !!(X & 7)
Based on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and use it in lieu of DIV_ROUND_UP() for ->key_size() return values.
Additionally, use the macro in ecc_digits_from_bytes(), whose "nbytes" parameter is a ->key_size() return value in some instances, or a user-specified ASN.1 length in the case of ecdsa_get_signature_rs().(CVE-2025-37984)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix double SIGFPE crash
Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.
When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.
The issue can be reproduced with this test program:
root@parisc:~# cat fpe.c
static void fpe_func(int sig, siginfo_t i, void v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); }
int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }
root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception
root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 / 20 vars /) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception(CVE-2025-37991)
In the Linux kernel, the following vulnerability has been resolved:
HID: uclogic: Add NULL check in uclogic_input_configured()
devm_kasprintf() returns NULL when memory allocation fails. Currently, uclogic_input_configured() does not check for this case, which results in a NULL pointer dereference.
Add NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-38007)
In the Linux kernel, the following vulnerability has been resolved:
nfs: handle failure of nfs_get_lock_context in unlock path
When memory is insufficient, the allocation of nfs_lock_context in nfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat an nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM) as valid and proceed to execute rpc_run_task(), this will trigger a NULL pointer dereference in nfs4_locku_prepare. For example:
BUG: kernel NULL pointer dereference, address: 000000000000000c PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 Workqueue: rpciod rpc_async_schedule RIP: 0010:nfs4_locku_prepare+0x35/0xc2 Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3 RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246 RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40 RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38 R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030 R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30 FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0 Call Trace: <TASK> __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Modules linked in: CR2: 000000000000000c ---[ end trace 0000000000000000 ]---
Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails and return NULL to terminate subsequent rpc_run_task, preventing NULL pointer dereference.(CVE-2025-38023)
Linux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States. There is a security vulnerability in Linux kernel that originates from a wrong parameter order, which may cause null pointers to be dereferenced.(CVE-2025-38034)
In the Linux kernel, the following vulnerability has been resolved:
bpf: copy_verifier_state() should copy 'loop_entry' field
The bpf_verifier_state.loop_entry state should be copied by copy_verifier_state(). Otherwise, .loop_entry values from unrelated states would poison env->cur_state.
Additionally, env->stack should not contain any states with .loop_entry != NULL. The states in env->stack are yet to be verified, while .loop_entry is set for states that reached an equivalent state. This means that env->cur_state->loop_entry should always be NULL after pop_stack().
See the selftest in the next commit for an example of the program that is not safe yet is accepted by verifier w/o this fix.
This change has some verification performance impact for selftests:
File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)
arena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%) arena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%) arena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%) iters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%) iters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%) iters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%) kmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%) verifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%) verifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)
And significant negative impact for sched_ext:
File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)
bpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%)
bpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%)
bpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%)
bpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%)
bpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%)
bpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%)
bpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%)
bpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%)
scx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%)
scx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%)
scx_qmap.bpf.o qmap_dispatch
---truncated---(CVE-2025-38060)
In the Linux kernel, the following vulnerability has been resolved:
orangefs: Do not truncate file size
'len' is used to store the result of i_size_read(), so making 'len' a size_t results in truncation to 4GiB on 32-bit systems.(CVE-2025-38065)
In the Linux kernel, the following vulnerability has been resolved:
rseq: Fix segfault on registration when rseq_cs is non-zero
The rseq_cs field is documented as being set to 0 by user-space prior to registration, however this is not currently enforced by the kernel. This can result in a segfault on return to user-space if the value stored in the rseq_cs field doesn't point to a valid struct rseq_cs.
The correct solution to this would be to fail the rseq registration when the rseq_cs field is non-zero. However, some older versions of glibc will reuse the rseq area of previous threads without clearing the rseq_cs field and will also terminate the process if the rseq registration fails in a secondary thread. This wasn't caught in testing because in this case the leftover rseq_cs does point to a valid struct rseq_cs.
What we can do is clear the rseq_cs field on registration when it's non-zero which will prevent segfaults on registration and won't break the glibc versions that reuse rseq areas on thread creation.(CVE-2025-38067)
In the Linux kernel, the following vulnerability has been resolved:
libnvdimm/labels: Fix divide error in nd_label_data_init()
If a faulty CXL memory device returns a broken zero LSA size in its memory device information (Identify Memory Device (Opcode 4000h), CXL spec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm driver:
Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]
Code and flow:
1) CXL Command 4000h returns LSA size = 0 2) config_size is assigned to zero LSA size (CXL pmem driver):
drivers/cxl/pmem.c: .config_size = mds->lsa_size,
3) max_xfer is set to zero (nvdimm driver):
drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);
4) A subsequent DIV_ROUND_UP() causes a division by zero:
drivers/nvdimm/label.c: / Make our initial read size a multiple of max_xfer size / drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer, drivers/nvdimm/label.c- config_size);
Fix this by checking the config size parameter by extending an existing check.(CVE-2025-38072)
In the Linux kernel, the following vulnerability has been resolved:
vhost-scsi: protect vq->log_used with vq->mutex
The vhost-scsi completion path may access vq->log_base when vq->log_used is already set to false.
vhost-thread QEMU-thread
vhost_scsi_complete_cmd_work() -> vhost_add_used() -> vhost_add_used_n() if (unlikely(vq->log_used)) QEMU disables vq->log_used via VHOST_SET_VRING_ADDR. mutex_lock(&vq->mutex); vq->log_used = false now! mutex_unlock(&vq->mutex);
QEMU gfree(vq->log_base)
log_used()
-> log_write(vq->log_base)
Assuming the VMM is QEMU. The vq->log_base is from QEMU userpace and can be reclaimed via gfree(). As a result, this causes invalid memory writes to QEMU userspace.
The control queue path has the same issue.(CVE-2025-38074)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: pcm: Fix race of buffer access at PCM OSS layer
The PCM OSS layer tries to clear the buffer with the silence data at initialization (or reconfiguration) of a stream with the explicit call of snd_pcm_format_set_silence() with runtime->dma_area. But this may lead to a UAF because the accessed runtime->dma_area might be freed concurrently, as it's performed outside the PCM ops.
For avoiding it, move the code into the PCM core and perform it inside the buffer access lock, so that it won't be changed during the operation.(CVE-2025-38078)
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Increase block_sequence array size
[Why] It's possible to generate more than 50 steps in hwss_build_fast_sequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the block_sequence buffer and corrupts block_sequence_steps, causing a crash.
[How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient.(CVE-2025-38080)
In the Linux kernel, the following vulnerability has been resolved:
spi-rockchip: Fix register out of bounds access
Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense.(CVE-2025-38081)
In the Linux kernel, the following vulnerability has been resolved:
drivers/rapidio/rio_cm.c: prevent possible heap overwrite
In
riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send()
cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated.
Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace.(CVE-2025-38090)
A vulnerability was found in Linux Kernel up to 6.14.7 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-833. The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.This is going to have an impact on availability.Upgrading to version 5.10.238, 5.15.184, 6.1.140, 6.6.92, 6.12.30 or 6.14.8 eliminates this vulnerability. Applying the patch 0772a608d799ac0d127c0a36047a2725777aba9d/64675a9c00443b2e8af42af08c38fc1b78b68ba2/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4/3e64d35475aa21d13dab71da51de51923c1a3a48/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19769).(CVE-2025-38094)
A vulnerability has been found in Linux Kernel up to 6.1.139/6.6.91/6.12.29/6.14.7 (Operating System) and classified as critical.The CWE definition for the vulnerability is CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.As an impact it is known to affect availability.Upgrading to version 6.1.140, 6.6.92, 6.12.30 or 6.14.8 eliminates this vulnerability. Applying the patch 3becc659f9cb76b481ad1fb71f54d5c8d6332d3f/c9d2b9a80d06a58f37e0dc8c827075639b443927/fe1bebd0edb22e3536cbc920ec713331d1367ad4/08680c4dadc6e736c75bc2409d833f03f9003c51/72c7d62583ebce7baeb61acce6057c361f73be4a is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19768).(CVE-2025-38095)
A vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.12.30/6.14.8 (Operating System).CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 6.12.31 or 6.14.9 eliminates this vulnerability. Applying the patch f48ee562c095e552a30b8d9cc0566a267b410f8a/ec1f015ec0c6fd250a6564e8452f7bb3160b9cb1/14d17c78a4b1660c443bae9d38c814edea506f62 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19764).(CVE-2025-38099)
A vulnerability classified as problematic was found in Linux Kernel up to 6.16-rc1 (Operating System).The CWE definition for the vulnerability is CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 2790c4ec481be45a80948d059cd7c9a06bc37493/a1bf6a4e9264a685b0e642994031f9c5aad72414/110a47efcf23438ff8d31dbd9c854fae2a48bf98/f569984417a4e12c67366e69bdcb752970de921d/2a71924ca4af59ffc00f0444732b6cd54b153d0e/4b755305b2b0618e857fdadb499365b5f2e478d1/444ad445df5496a785705019268a8a84b84484bb/85a3e0ede38450ea3053b8c45d28cf55208409b8 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38108)
A vulnerability was found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2/6.16-rc1 (Operating System) and classified as critical.Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 3c9aba9cbdf163e2654be9f82d43ff8a04273962/9f66b6531c2b4e996bb61720ee94adb4b2e8d1be/9df3e5e7f7e4653fd9802878cedc36defc5ef42d/32aa2fbe319f33b0318ec6f4fceb63879771a286/e6ed54e86aae9e4f7286ce8d5c73780f91b48d1c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38118)
A vulnerability classified as critical has been found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2 (Operating System).CWE is classifying the issue as CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 6bf529ce84dccc0074dbc704e70aee4aa545057e/4e9e45746b861ebd54c03ef301da2cb8fc990536/19bd9cde38dd4ca1771aed7afba623e7f4247c8e/7eeb3df6f07a886bdfd52757ede127a59a8784dc/25be318324563c63cbd9cb53186203a08d2f83a1 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38142)
A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.15.2 (Operating System).Using CWE to declare the problem leads to CWE-129. The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 4b9a086eedc1fddae632310386098c12155e3d0a/ad17eb86d042d72a59fd184ad1adf34f5eb36843/f26fe7c3002516dd3c288f1012786df31f4d89e0/8ebcd311b4866ab911d1445ead08690e67f0c488/69541e58323ec3e3904e1fa87a6213961b1f52f4/3c1906a3d50cb94fd0a10e97a1c0a40c0f033cb7/0bdc924bfb319fb10d1113cbf091fc26fb7b1f99 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38146)
In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Clear table_sz when rproc_shutdown
There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc.
When starting rproc with a firmware not have resource table,
memcpy(loaded_table, rproc->cached_table, rproc->table_sz) will
trigger dump, because rproc->cache_table is set to NULL during the last
stop operation, but rproc->table_sz is still valid.
This issue is found on i.MX8MP and i.MX9.
Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c
Clear rproc->table_sz to address the issue.(CVE-2025-38152)
A vulnerability classified as problematic has been found in Linux Kernel up to 5.15.185/6.1.141/6.6.93/6.12.33/6.15.2 (Operating System).CWE is classifying the issue as CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.This is going to have an impact on confidentiality.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 1ee8ea6937d13b20f90ff35d71ccc03ba448182d/68a1037f0bac4de9a585aa9c879ef886109f3647/74e18211c2c89ab66c9546baa7408288db61aa0d/c13255389499275bc5489a0b5b7940ccea3aef04/9febcc8bded8be0d7efd8237fcef599b6d93b788/4c2c372de2e108319236203cce6de44d70ae15cd is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19785).(CVE-2025-38159)
A vulnerability was found in Linux Kernel up to 6.15.2 (Operating System). It has been rated as problematic.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 49bc7bf38e42cfa642787e947f5721696ea73ac3/f1b743c1955151bd392539b739a3ad155296be13/6a324d77f7ea1a91d55c4b6ad970e3ac9ab6a20d/25f3776b58c1c45ad2e50ab4b263505b4d2378ca/a39cc43efc1bca74ed9d6cf9e60b995071f7d178/65b3f76592aed5a43c4d79375ac097acf975972b/ccc28c0397f75a3ec9539cceed9db014d7b73869/05872a167c2cab80ef186ef23cc34a6776a1a30c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19781).(CVE-2025-38163)
A vulnerability was found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch de89368de3894a8db27caeb8fd902ba1c49f696a/43be952e885476dafb74aa832c0847b2f4f650c6/6103f9ba51a59afb5a0f32299c837377c5a5a693/c4a4786d93e99517d6f10ed56b9ffba4ce88d3b3/d3eaab3c70905c5467e5c4ea403053d67505adeb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19774).(CVE-2025-38170)
A vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc2 (Operating System).This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 3162d8235c8c4d585525cee8a59d1c180940a968/0f8df5d6f25ac17c52a8bc6418e60a3e63130550/e2b2b7cf6368580114851cb3932f2ad9fbf23386/8c8472855884355caf3d8e0c50adf825f83454b2 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38182)
A vulnerability was found in Linux Kernel (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-252. The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch b427d98d55217b53c88643579fbbd8a4c351a105/985f086f281b7bbb6644851e63af1a17ffff9277/b5c7397b7fd125203c60b59860c168ee92291272/ee084fa96123ede8b0563a1b5a9b23adc43cd50d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38195)
A vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.Impacted is availability.Upgrading to version 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 5e8c658acd1b7c186aeffa46bf08795e121f401a/07d7b8e7ef7d1f812a6211ed531947c56d09e95e/a7b477b64ef5e37cb08dd536ae07c46f9f28262e/f3b840fb1508a80cd8a0efb5c886ae1995a88b24/4d71f2c1e5263a9f042faa71d59515709869dc79/32d05e6cc3a7bf6c8f16f7b7ef8fe80eca0c233e/61ce04601e0d8265ec6d2ffa6df5a7e1bce64854 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38197)
A vulnerability was found in Linux Kernel up to 6.1.141/6.6.94/6.12.34/6.15.3 (Operating System). It has been declared as problematic.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch 2f8c69a72e8ad87b36b8052f789da3cc2b2e186c/7bf4461f1c97207fda757014690d55a447ce859f/2d834477bbc1e8b8a59ff8b0c081529d6bed7b22/b522d4d334f206284b1a44b0b0b2f99fd443b39b/d4965578267e2e81f67c86e2608481e77e9c8569 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38202)
In the Linux kernel, the following vulnerability has been resolved:
media: cxusb: no longer judge rbuf when the write fails
syzbot reported a uninit-value in cxusb_i2c_xfer. [1]
Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf.
In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized.
[1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38229)
A vulnerability was found in Linux Kernel up to 6.15.2/fc2778c42f99c7de52fc004157b3c3ee4dcc208a (Operating System). It has been rated as problematic.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch ac49b7560b4b08b1e4043a29214cc7ad77644c00/e2d2115e56c4a02377189bfc3a9a7933552a7b0f is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38279)
A vulnerability, which was classified as problematic, was found in Linux Kernel (Operating System).CWE is classifying the issue as CWE-74. The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch e7fb4ebee6e900899d2b2e5852c3e2eafcbcad66/ef92b96530d1731d9ac167bc7c193c683cd78fff/6f639c25bfad17d9fd7379ab91ff9678ea9aac85/2bc6dffb4b72d53d6a6ada510269bf548c3f7ae0/0b9bb52796b239de6792d0d68cdc6eb505ebff96/86bc9c742426a16b52a10ef61f5b721aecca2344 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38280)
A vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.As an impact it is known to affect confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 64773b3ea09235168a549a195cba43bb867c4a17/67abac27d806e8f9d4226ec1528540cf73af673a/92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38/01f91d415a8375d85e0c7d3615cd4a168308bb7c/21da6d3561f373898349ca7167c9811c020da695/22f935bc86bdfbde04009f05eee191d220cd8c89/422e565b7889ebfd9c8705a3fc786642afe61fca/39dfc971e42d886e7df01371cd1bef505076d84c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20926).(CVE-2025-38320)
A vulnerability was found in Linux Kernel up to 6.15.3/6.16-rc2 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch a85cc69acdcb05f8cd226b8ea0778b8e2e887e6f/b0823d5fbacb1c551d793cbfe7af24e0d1fa45ed is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38322)
A vulnerability was found in Linux Kernel up to 6.15.3 (Operating System). It has been declared as critical.The CWE definition for the vulnerability is CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch d064c68781c19f378af1ae741d9132d35d24b2bb/8690cd3258455bbae64f809e1d3ee0f043661c71/6805582abb720681dd1c87ff677f155dcf4e86c9/03a162933c4a03b9f1a84f7d8482903c7e1e11bb/83a692a9792aa86249d68a8ac0b9d55ecdd255fa/8e89c17dc8970c5f71a3a991f5724d4c8de42d8c/f78a786ad9a5443a29eef4dae60cde85b7375129/f914b52c379c12288b7623bb814d0508dbe7481d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38346)
In the Linux kernel, the following vulnerability has been resolved:
jfs: fix slab-out-of-bounds read in ea_get()
During the "size_check" label in ea_get(), the code checks if the extended attribute list (xattr) size matches ea_size. If not, it logs "ea_get: invalid extended attribute" and calls print_hex_dump().
Here, EALIST_SIZE(ea_buf->xattr) returns 4110417968, which exceeds INT_MAX (2,147,483,647). Then ea_size is clamped:
int size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf->xattr));
Although clamp_t aims to bound ea_size between 0 and 4110417968, the upper limit is treated as an int, causing an overflow above 2^31 - 1. This leads "size" to wrap around and become negative (-184549328).
The "size" is then passed to print_hex_dump() (called "len" in print_hex_dump()), it is passed as type size_t (an unsigned type), this is then stored inside a variable called "int remaining", which is then assigned to "int linelen" which is then passed to hex_dump_to_buffer(). In print_hex_dump() the for loop, iterates through 0 to len-1, where len is 18446744073525002176, calling hex_dump_to_buffer() on each iteration:
for (i = 0; i < len; i += rowsize) {
linelen = min(remaining, rowsize);
remaining -= rowsize;
hex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,
linebuf, sizeof(linebuf), ascii);
...
}
The expected stopping condition (i < len) is effectively broken since len is corrupted and very large. This eventually leads to the "ptr+i" being passed to hex_dump_to_buffer() to get closer to the end of the actual bounds of "ptr", eventually an out of bounds access is done in hex_dump_to_buffer() in the following for loop:
for (j = 0; j < len; j++) {
if (linebuflen < lx + 2)
goto overflow2;
ch = ptr[j];
...
}
To fix this we should validate "EALIST_SIZE(ea_buf->xattr)" before it is utilised.(CVE-2025-39735)
In the Linux kernel, the following vulnerability has been resolved:
objtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()
If speed_hz < AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the entire amd_spi_freq array without breaking out early, causing 'i' to go beyond the array bounds.
Fix that by stopping the loop when it gets to the last entry, so the low speed_hz value gets clamped up to AMD_SPI_MIN_HZ.
Fixes the following warning with an UBSAN kernel:
drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()(CVE-2025-40014)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"bpftool-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-debugsource-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-devel-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-extra-modules-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-headers-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-source-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-tools-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"kernel-tools-devel-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"perf-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"perf-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"python3-perf-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-101.0.0.107.oe2403sp2.aarch64.rpm"
],
"src": [
"kernel-6.6.0-101.0.0.107.oe2403sp2.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"bpftool-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-debugsource-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-devel-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-extra-modules-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-headers-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-source-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-tools-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"kernel-tools-devel-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"perf-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"perf-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"python3-perf-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-101.0.0.107.oe2403sp2.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP2",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.0-101.0.0.107.oe2403sp2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: iaa - Fix potential use after free bug\n\nThe free_device_compression_mode(iaa_device, device_mode) function frees\n\u0026quot;device_mode\u0026quot; but it iss passed to iaa_compression_modes[i]-\u0026gt;free() a few\nlines later resulting in a use after free.\n\nThe good news is that, so far as I can tell, nothing implements the\n-\u0026gt;free() function and the use after free happens in dead code. But, with\nthis fix, when something does implement it, we\u0026apos;ll be ready. :)(CVE-2024-47732)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/migrate_device: don\u0026apos;t add folio to be freed to LRU in migrate_device_finalize()\n\nIf migration succeeded, we called\nfolio_migrate_flags()-\u0026gt;mem_cgroup_migrate() to migrate the memcg from the\nold to the new folio. This will set memcg_data of the old folio to 0.\n\nSimilarly, if migration failed, memcg_data of the dst folio is left unset.\n\nIf we call folio_putback_lru() on such folios (memcg_data == 0), we will\nadd the folio to be freed to the LRU, making memcg code unhappy. Running\nthe hmm selftests:\n\n # ./hmm-tests\n ...\n # RUN hmm.hmm_device_private.migrate ...\n [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00\n [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff)\n [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9\n [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000\n [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg \u0026amp;\u0026amp; !mem_cgroup_disabled())\n [ 102.087230][T14893] ------------[ cut here ]------------\n [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.090478][T14893] Modules linked in:\n [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151\n [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\n [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.096104][T14893] Code: ...\n [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293\n [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426\n [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880\n [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000\n [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8\n [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000\n [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000\n [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0\n [ 102.113478][T14893] PKRU: 55555554\n [ 102.114172][T14893] Call Trace:\n [ 102.114805][T14893] \u0026lt;TASK\u0026gt;\n [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.116547][T14893] ? __warn.cold+0x110/0x210\n [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.118667][T14893] ? report_bug+0x1b9/0x320\n [ 102.119571][T14893] ? handle_bug+0x54/0x90\n [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50\n [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20\n [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0\n [ 102.123506][T14893] ? dump_page+0x4f/0x60\n [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170\n [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200\n [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10\n [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720\n [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10\n [ 102.129550][T14893] folio_putback_lru+0x16/0x80\n [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530\n [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0\n [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80\n\nLikely, nothing else goes wrong: putting the last folio reference will\nremove the folio from the LRU again. So besides memcg complaining, adding\nthe folio to be freed to the LRU is just an unnecessary step.\n\nThe new flow resembles what we have in migrate_folio_move(): add the dst\nto the lru, rem\n---truncated---(CVE-2025-21861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()\n\nOn the off chance that command stream passed from userspace via\nioctl() call to radeon_vce_cs_parse() is weirdly crafted and\nfirst command to execute is to encode (case 0x03000001), the function\nin question will attempt to call radeon_vce_cs_reloc() with size\nargument that has not been properly initialized. Specifically, \u0026apos;size\u0026apos;\nwill point to \u0026apos;tmp\u0026apos; variable before the latter had a chance to be\nassigned any value.\n\nPlay it safe and init \u0026apos;tmp\u0026apos; with 0, thus ensuring that\nradeon_vce_cs_reloc() will catch an early error in cases like these.\n\nFound by Linux Verification Center (linuxtesting.org) with static\nanalysis tool SVACE.\n\n(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)(CVE-2025-21996)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: Don\u0026apos;t call NULL in do_compat_alignment_fixup()\n\ndo_alignment_t32_to_handler() only fixes up alignment faults for\nspecific instructions; it returns NULL otherwise (e.g. LDREX). When\nthat\u0026apos;s the case, signal to the caller that it needs to proceed with the\nregular alignment fault handling (i.e. SIGBUS). Without this patch, the\nkernel panics:\n\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Mem abort info:\n ESR = 0x0000000086000006\n EC = 0x21: IABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x06: level 2 translation fault\n user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000\n [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000\n Internal error: Oops: 0000000086000006 [#1] SMP\n Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa\u0026gt;\n libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c\u0026gt;\n CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1 Debian 6.1.128-1\n Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021\n pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : 0x0\n lr : do_compat_alignment_fixup+0xd8/0x3dc\n sp : ffff80000f973dd0\n x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000\n x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001\n x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000\n x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001\n Call trace:\n 0x0\n do_alignment_fault+0x40/0x50\n do_mem_abort+0x4c/0xa0\n el0_da+0x48/0xf0\n el0t_32_sync_handler+0x110/0x140\n el0t_32_sync+0x190/0x194\n Code: bad PC value\n ---[ end trace 0000000000000000 ]---(CVE-2025-22033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: libwx: fix Tx L4 checksum\n\nThe hardware only supports L4 checksum offload for TCP/UDP/SCTP protocol.\nThere was a bug to set Tx checksum flag for the other protocol that results\nin Tx ring hang. Fix to compute software checksum for these packets.(CVE-2025-22101)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Mask the bd_cnt field in the TX BD properly\n\nThe bd_cnt field in the TX BD specifies the total number of BDs for\nthe TX packet. The bd_cnt field has 5 bits and the maximum number\nsupported is 32 with the value 0.\n\nCONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB\nfragments can approach or exceed the maximum supported by the chip.\nAdd a macro to properly mask the bd_cnt field so that the value 32\nwill be properly masked and set to 0 in the bd_cnd field.\n\nWithout this patch, the out-of-range bd_cnt value will corrupt the\nTX BD and may cause TX timeout.\n\nThe next patch will check for values exceeding 32.(CVE-2025-22108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Acquire SRCU in KVM_GET_MP_STATE to protect guest memory accesses\n\nAcquire a lock on kvm-\u0026gt;srcu when userspace is getting MP state to handle a\nrather extreme edge case where \u0026quot;accepting\u0026quot; APIC events, i.e. processing\npending INIT or SIPI, can trigger accesses to guest memory. If the vCPU\nis in L2 with INIT *and* a TRIPLE_FAULT request pending, then getting MP\nstate will trigger a nested VM-Exit by way of -\u0026gt;check_nested_events(), and\nemuating the nested VM-Exit can access guest memory.\n\nThe splat was originally hit by syzkaller on a Google-internal kernel, and\nreproduced on an upstream kernel by hacking the triple_fault_event_test\nselftest to stuff a pending INIT, store an MSR on VM-Exit (to generate a\nmemory access on VMX), and do vcpu_mp_state_get() to trigger the scenario.\n\n =============================\n WARNING: suspicious RCU usage\n 6.14.0-rc3-b112d356288b-vmx/pi_lockdep_false_pos-lock #3 Not tainted\n -----------------------------\n include/linux/kvm_host.h:1058 suspicious rcu_dereference_check() usage!\n\n other info that might help us debug this:\n\n rcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by triple_fault_ev/1256:\n #0: ffff88810df5a330 (\u0026amp;vcpu-\u0026gt;mutex){+.+.}-{4:4}, at: kvm_vcpu_ioctl+0x8b/0x9a0 [kvm]\n\n stack backtrace:\n CPU: 11 UID: 1000 PID: 1256 Comm: triple_fault_ev Not tainted 6.14.0-rc3-b112d356288b-vmx #3\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x7f/0x90\n lockdep_rcu_suspicious+0x144/0x190\n kvm_vcpu_gfn_to_memslot+0x156/0x180 [kvm]\n kvm_vcpu_read_guest+0x3e/0x90 [kvm]\n read_and_check_msr_entry+0x2e/0x180 [kvm_intel]\n __nested_vmx_vmexit+0x550/0xde0 [kvm_intel]\n kvm_check_nested_events+0x1b/0x30 [kvm]\n kvm_apic_accept_events+0x33/0x100 [kvm]\n kvm_arch_vcpu_ioctl_get_mpstate+0x30/0x1d0 [kvm]\n kvm_vcpu_ioctl+0x33e/0x9a0 [kvm]\n __x64_sys_ioctl+0x8b/0xb0\n do_syscall_64+0x6c/0x170\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n \u0026lt;/TASK\u0026gt;(CVE-2025-23141)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: do not start chip while suspended\n\nChecking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can\nlead to a spurious tpm_chip_start() call:\n\n[35985.503771] i2c i2c-1: Transfer while suspended\n[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810\n[35985.503802] Modules linked in:\n[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f\n[35985.503814] Tainted: [W]=WARN\n[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810\n[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe \u0026lt;0f\u0026gt; 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5\n[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246\n[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000\n[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001\n[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\n[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820\n[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120\n[35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000\n[35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0\n[35985.503855] Call Trace:\n[35985.503859] \u0026lt;TASK\u0026gt;\n[35985.503863] ? __warn+0xd4/0x260\n[35985.503868] ? __i2c_transfer+0xbe/0x810\n[35985.503874] ? report_bug+0xf3/0x210\n[35985.503882] ? handle_bug+0x63/0xb0\n[35985.503887] ? exc_invalid_op+0x16/0x50\n[35985.503892] ? asm_exc_invalid_op+0x16/0x20\n[35985.503904] ? __i2c_transfer+0xbe/0x810\n[35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0\n[35985.503920] tpm_cr50_i2c_read+0x8e/0x120\n[35985.503928] tpm_cr50_request_locality+0x75/0x170\n[35985.503935] tpm_chip_start+0x116/0x160\n[35985.503942] tpm_try_get_ops+0x57/0x90\n[35985.503948] tpm_find_get_ops+0x26/0xd0\n[35985.503955] tpm_get_random+0x2d/0x80\n\nDon\u0026apos;t move forward with tpm_chip_start() inside tpm_try_get_ops(), unless\nTPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in\nsuch a failure case.(CVE-2025-23149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid out-of-bounds access in f2fs_truncate_inode_blocks()\n\nsyzbot reports an UBSAN issue as below:\n\n------------[ cut here ]------------\nUBSAN: array-index-out-of-bounds in fs/f2fs/node.h:381:10\nindex 18446744073709550692 is out of range for type \u0026apos;__le32[5]\u0026apos; (aka \u0026apos;unsigned int[5]\u0026apos;)\nCPU: 0 UID: 0 PID: 5318 Comm: syz.0.0 Not tainted 6.14.0-rc3-syzkaller-00060-g6537cfb395f3 #0\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 ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_out_of_bounds+0x121/0x150 lib/ubsan.c:429\n get_nid fs/f2fs/node.h:381 [inline]\n f2fs_truncate_inode_blocks+0xa5e/0xf60 fs/f2fs/node.c:1181\n f2fs_do_truncate_blocks+0x782/0x1030 fs/f2fs/file.c:808\n f2fs_truncate_blocks+0x10d/0x300 fs/f2fs/file.c:836\n f2fs_truncate+0x417/0x720 fs/f2fs/file.c:886\n f2fs_file_write_iter+0x1bdb/0x2550 fs/f2fs/file.c:5093\n aio_write+0x56b/0x7c0 fs/aio.c:1633\n io_submit_one+0x8a7/0x18a0 fs/aio.c:2052\n __do_sys_io_submit fs/aio.c:2111 [inline]\n __se_sys_io_submit+0x171/0x2e0 fs/aio.c:2081\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\nRIP: 0033:0x7f238798cde9\n\nindex 18446744073709550692 (decimal, unsigned long long)\n= 0xfffffffffffffc64 (hexadecimal, unsigned long long)\n= -924 (decimal, long long)\n\nIn f2fs_truncate_inode_blocks(), UBSAN detects that get_nid() tries to\naccess .i_nid[-924], it means both offset[0] and level should zero.\n\nThe possible case should be in f2fs_do_truncate_blocks(), we try to\ntruncate inode size to zero, however, dn.ofs_in_node is zero and\ndn.node_page is not an inode page, so it fails to truncate inode page,\nand then pass zeroed free_from to f2fs_truncate_inode_blocks(), result\nin this issue.\n\n\tif (dn.ofs_in_node || IS_INODE(dn.node_page)) {\n\t\tf2fs_truncate_data_blocks_range(\u0026amp;dn, count);\n\t\tfree_from += count;\n\t}\n\nI guess the reason why dn.node_page is not an inode page could be: there\nare multiple nat entries share the same node block address, once the node\nblock address was reused, f2fs_get_node_page() may load a non-inode block.\n\nLet\u0026apos;s add a sanity check for such condition to avoid out-of-bounds access\nissue.(CVE-2025-37739)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ti: icss-iep: Fix possible NULL pointer dereference for perout request\n\nThe ICSS IEP driver tracks perout and pps enable state with flags.\nCurrently when disabling pps and perout signals during icss_iep_exit(),\nresults in NULL pointer dereference for perout.\n\nTo fix the null pointer dereference issue, the icss_iep_perout_enable_hw\nfunction can be modified to directly clear the IEP CMP registers when\ndisabling PPS or PEROUT, without referencing the ptp_perout_request\nstructure, as its contents are irrelevant in this case.(CVE-2025-37784)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: null - Use spin lock instead of mutex\n\nAs the null algorithm may be freed in softirq context through\naf_alg, use spin locks instead of mutexes to protect the default\nnull algorithm.(CVE-2025-37808)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: gadget: check that event count does not exceed event buffer length\n\nThe event count is read from register DWC3_GEVNTCOUNT.\nThere is a check for the count being zero, but not for exceeding the\nevent buffer length.\nCheck that event count does not exceed event buffer length,\navoiding an out-of-bounds access when memcpy\u0026apos;ing the event.\nCrash log:\nUnable to handle kernel paging request at virtual address ffffffc0129be000\npc : __memcpy+0x114/0x180\nlr : dwc3_check_event_buf+0xec/0x348\nx3 : 0000000000000030 x2 : 000000000000dfc4\nx1 : ffffffc0129be000 x0 : ffffff87aad60080\nCall trace:\n__memcpy+0x114/0x180\ndwc3_interrupt+0x24/0x34(CVE-2025-37810)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: fsl-qspi: use devm function instead of driver remove\n\nDriver use devm APIs to manage clk/irq/resources and register the spi\ncontroller, but the legacy remove function will be called first during\ndevice detach and trigger kernel panic. Drop the remove function and use\ndevm_add_action_or_reset() for driver cleanup to ensure the release\nsequence.\n\nTrigger kernel panic on i.MX8MQ by\necho 30bb0000.spi \u0026gt;/sys/bus/platform/drivers/fsl-quadspi/unbind(CVE-2025-37842)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Tear down vGIC on failed vCPU creation\n\nIf kvm_arch_vcpu_create() fails to share the vCPU page with the\nhypervisor, we propagate the error back to the ioctl but leave the\nvGIC vCPU data initialised. Note only does this leak the corresponding\nmemory when the vCPU is destroyed but it can also lead to use-after-free\nif the redistributor device handling tries to walk into the vCPU.\n\nAdd the missing cleanup to kvm_arch_vcpu_create(), ensuring that the\nvGIC vCPU structures are destroyed on error.(CVE-2025-37849)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Fix mode1 reset crash issue\n\nIf HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal\nuser space to abort the processes. After process abort exit, user queues\nstill use the GPU to access system memory before h/w is reset while KFD\ncleanup worker free system memory and free VRAM.\n\nThere is use-after-free race bug that KFD allocate and reuse the freed\nsystem memory, and user queue write to the same system memory to corrupt\nthe data structure and cause driver crash.\n\nTo fix this race, KFD cleanup worker terminate user queues, then flush\nreset_domain wq to wait for any GPU ongoing reset complete, and then\nfree outstanding BOs.(CVE-2025-37854)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result\n\nIf the FW doesn\u0026apos;t support the PDS_CORE_CMD_FW_CONTROL command\nthe driver might at the least print garbage and at the worst\ncrash when the user runs the \u0026quot;devlink dev info\u0026quot; devlink command.\n\nThis happens because the stack variable fw_list is not 0\ninitialized which results in fw_list.num_fw_slots being a\ngarbage value from the stack. Then the driver tries to access\nfw_list.fw_names[i] with i \u0026gt;= ARRAY_SIZE and runs off the end\nof the array.\n\nFix this by initializing the fw_list and by not failing\ncompletely if the devcmd fails because other useful information\nis printed via devlink dev info even if the devcmd fails.(CVE-2025-37887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()\n\nNouveau is mostly designed in a way that it\u0026apos;s expected that fences only\never get signaled through nouveau_fence_signal(). However, in at least\none other place, nouveau_fence_done(), can signal fences, too. If that\nhappens (race) a signaled fence remains in the pending list for a while,\nuntil it gets removed by nouveau_fence_update().\n\nShould nouveau_fence_context_kill() run in the meantime, this would be\na bug because the function would attempt to set an error code on an\nalready signaled fence.\n\nHave nouveau_fence_context_kill() check for a fence being signaled.(CVE-2025-37930)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocteon_ep: Fix host hang issue during device reboot\n\nWhen the host loses heartbeat messages from the device,\nthe driver calls the device-specific ndo_stop function,\nwhich frees the resources. If the driver is unloaded in\nthis scenario, it calls ndo_stop again, attempting to free\nresources that have already been freed, leading to a host\nhang issue. To resolve this, dev_close should be called\ninstead of the device-specific stop function.dev_close\ninternally calls ndo_stop to stop the network interface\nand performs additional cleanup tasks. During the driver\nunload process, if the device is already down, ndo_stop\nis not called.(CVE-2025-37933)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()\n\nIf dib8000_set_dds()\u0026apos;s call to dib8000_read32() returns zero, the result\nis a divide-by-zero. Prevent that from happening.\n\nFixes the following warning with an UBSAN kernel:\n\n drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()(CVE-2025-37937)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: bpf: Add BHB mitigation to the epilogue for cBPF programs\n\nA malicious BPF program may manipulate the branch history to influence\nwhat the hardware speculates will happen next.\n\nOn exit from a BPF program, emit the BHB mititgation sequence.\n\nThis is only applied for \u0026apos;classic\u0026apos; cBPF programs that are loaded by\nseccomp.(CVE-2025-37948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/v3d: Add job to pending list if the reset was skipped\n\nWhen a CL/CSD job times out, we check if the GPU has made any progress\nsince the last timeout. If so, instead of resetting the hardware, we skip\nthe reset and let the timer get rearmed. This gives long-running jobs a\nchance to complete.\n\nHowever, when `timedout_job()` is called, the job in question is removed\nfrom the pending list, which means it won\u0026apos;t be automatically freed through\n`free_job()`. Consequently, when we skip the reset and keep the job\nrunning, the job won\u0026apos;t be freed when it finally completes.\n\nThis situation leads to a memory leak, as exposed in [1] and [2].\n\nSimilarly to commit 704d3d60fec4 (\u0026quot;drm/etnaviv: don\u0026apos;t block scheduler when\nGPU is still active\u0026quot;), this patch ensures the job is put back on the\npending list when extending the timeout.(CVE-2025-37951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: bpf: Only mitigate cBPF programs loaded by unprivileged users\n\nSupport for eBPF programs loaded by unprivileged users is typically\ndisabled. This means only cBPF programs need to be mitigated for BHB.\n\nIn addition, only mitigate cBPF programs that were loaded by an\nunprivileged user. Privileged users can also load the same program\nvia eBPF, making the mitigation pointless.(CVE-2025-37963)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: light: opt3001: fix deadlock due to concurrent flag access\n\nThe threaded IRQ function in this driver is reading the flag twice: once to\nlock a mutex and once to unlock it. Even though the code setting the flag\nis designed to prevent it, there are subtle cases where the flag could be\ntrue at the mutex_lock stage and false at the mutex_unlock stage. This\nresults in the mutex not being unlocked, resulting in a deadlock.\n\nFix it by making the opt3001_irq() code generally more robust, reading the\nflag into a variable and using the variable value at both stages.(CVE-2025-37968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ecdsa - Harden against integer overflows in DIV_ROUND_UP()\n\nHerbert notes that DIV_ROUND_UP() may overflow unnecessarily if an ecdsa\nimplementation\u0026apos;s -\u0026gt;key_size() callback returns an unusually large value.\nHerbert instead suggests (for a division by 8):\n\n X / 8 + !!(X \u0026amp; 7)\n\nBased on this formula, introduce a generic DIV_ROUND_UP_POW2() macro and\nuse it in lieu of DIV_ROUND_UP() for -\u0026gt;key_size() return values.\n\nAdditionally, use the macro in ecc_digits_from_bytes(), whose \u0026quot;nbytes\u0026quot;\nparameter is a -\u0026gt;key_size() return value in some instances, or a\nuser-specified ASN.1 length in the case of ecdsa_get_signature_rs().(CVE-2025-37984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler. Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0. The latter cancels all pending traps. Let\u0026apos;s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n sigset_t set;\n sigemptyset(\u0026amp;set);\n sigaddset(\u0026amp;set, SIGFPE);\n sigprocmask(SIG_UNBLOCK, \u0026amp;set, NULL);\n printf(\u0026quot;GOT signal %d with si_code %ld\\n\u0026quot;, sig, i-\u0026gt;si_code);\n}\n\nint main() {\n struct sigaction action = {\n .sa_sigaction = fpe_func,\n .sa_flags = SA_RESTART|SA_SIGINFO };\n sigaction(SIGFPE, \u0026amp;action, 0);\n feenableexcept(FE_OVERFLOW);\n return printf(\u0026quot;%lf\\n\u0026quot;,1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\u0026quot;./a.out\u0026quot;, [\u0026quot;./a.out\u0026quot;], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception(CVE-2025-37991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: uclogic: Add NULL check in uclogic_input_configured()\n\ndevm_kasprintf() returns NULL when memory allocation fails. Currently,\nuclogic_input_configured() does not check for this case, which results\nin a NULL pointer dereference.\n\nAdd NULL check after devm_kasprintf() to prevent this issue.(CVE-2025-38007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs: handle failure of nfs_get_lock_context in unlock path\n\nWhen memory is insufficient, the allocation of nfs_lock_context in\nnfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treat\nan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)\nas valid and proceed to execute rpc_run_task(), this will trigger a NULL\npointer dereference in nfs4_locku_prepare. For example:\n\nBUG: kernel NULL pointer dereference, address: 000000000000000c\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP PTI\nCPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40\nWorkqueue: rpciod rpc_async_schedule\nRIP: 0010:nfs4_locku_prepare+0x35/0xc2\nCode: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3\nRSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246\nRAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40\nRBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38\nR10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030\nR13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30\nFS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __rpc_execute+0xbc/0x480\n rpc_async_schedule+0x2f/0x40\n process_one_work+0x232/0x5d0\n worker_thread+0x1da/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x10d/0x240\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\nModules linked in:\nCR2: 000000000000000c\n---[ end trace 0000000000000000 ]---\n\nFree the allocated nfs4_unlockdata when nfs_get_lock_context() fails and\nreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointer\ndereference.(CVE-2025-38023)\n\nLinux kernel is the kernel used by Linux, the open source operating system of the Linux Foundation in the United States.\n There is a security vulnerability in Linux kernel that originates from a wrong parameter order, which may cause null pointers to be dereferenced.(CVE-2025-38034)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: copy_verifier_state() should copy \u0026apos;loop_entry\u0026apos; field\n\nThe bpf_verifier_state.loop_entry state should be copied by\ncopy_verifier_state(). Otherwise, .loop_entry values from unrelated\nstates would poison env-\u0026gt;cur_state.\n\nAdditionally, env-\u0026gt;stack should not contain any states with\n.loop_entry != NULL. The states in env-\u0026gt;stack are yet to be verified,\nwhile .loop_entry is set for states that reached an equivalent state.\nThis means that env-\u0026gt;cur_state-\u0026gt;loop_entry should always be NULL after\npop_stack().\n\nSee the selftest in the next commit for an example of the program that\nis not safe yet is accepted by verifier w/o this fix.\n\nThis change has some verification performance impact for selftests:\n\nFile Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)\n---------------------------------- ---------------------------- --------- --------- -------------- ---------- ---------- -------------\narena_htab.bpf.o arena_htab_llvm 717 426 -291 (-40.59%) 57 37 -20 (-35.09%)\narena_htab_asm.bpf.o arena_htab_asm 597 445 -152 (-25.46%) 47 37 -10 (-21.28%)\narena_list.bpf.o arena_list_del 309 279 -30 (-9.71%) 23 14 -9 (-39.13%)\niters.bpf.o iter_subprog_check_stacksafe 155 141 -14 (-9.03%) 15 14 -1 (-6.67%)\niters.bpf.o iter_subprog_iters 1094 1003 -91 (-8.32%) 88 83 -5 (-5.68%)\niters.bpf.o loop_state_deps2 479 725 +246 (+51.36%) 46 63 +17 (+36.96%)\nkmem_cache_iter.bpf.o open_coded_iter 63 59 -4 (-6.35%) 7 6 -1 (-14.29%)\nverifier_bits_iter.bpf.o max_words 92 84 -8 (-8.70%) 8 7 -1 (-12.50%)\nverifier_iterating_callbacks.bpf.o cond_break2 113 107 -6 (-5.31%) 12 12 +0 (+0.00%)\n\nAnd significant negative impact for sched_ext:\n\nFile Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)\n----------------- ---------------------- --------- --------- -------------------- ---------- ---------- ------------------\nbpf.bpf.o lavd_init 7039 14723 +7684 (+109.16%) 490 1139 +649 (+132.45%)\nbpf.bpf.o layered_dispatch 11485 10548 -937 (-8.16%) 848 762 -86 (-10.14%)\nbpf.bpf.o layered_dump 7422 1000001 +992579 (+13373.47%) 681 31178 +30497 (+4478.27%)\nbpf.bpf.o layered_enqueue 16854 71127 +54273 (+322.02%) 1611 6450 +4839 (+300.37%)\nbpf.bpf.o p2dq_dispatch 665 791 +126 (+18.95%) 68 78 +10 (+14.71%)\nbpf.bpf.o p2dq_init 2343 2980 +637 (+27.19%) 201 237 +36 (+17.91%)\nbpf.bpf.o refresh_layer_cpumasks 16487 674760 +658273 (+3992.68%) 1770 65370 +63600 (+3593.22%)\nbpf.bpf.o rusty_select_cpu 1937 40872 +38935 (+2010.07%) 177 3210 +3033 (+1713.56%)\nscx_central.bpf.o central_dispatch 636 2687 +2051 (+322.48%) 63 227 +164 (+260.32%)\nscx_nest.bpf.o nest_init 636 815 +179 (+28.14%) 60 73 +13 (+21.67%)\nscx_qmap.bpf.o qmap_dispatch \n---truncated---(CVE-2025-38060)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\norangefs: Do not truncate file size\n\n\u0026apos;len\u0026apos; is used to store the result of i_size_read(), so making \u0026apos;len\u0026apos;\na size_t results in truncation to 4GiB on 32-bit systems.(CVE-2025-38065)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrseq: Fix segfault on registration when rseq_cs is non-zero\n\nThe rseq_cs field is documented as being set to 0 by user-space prior to\nregistration, however this is not currently enforced by the kernel. This\ncan result in a segfault on return to user-space if the value stored in\nthe rseq_cs field doesn\u0026apos;t point to a valid struct rseq_cs.\n\nThe correct solution to this would be to fail the rseq registration when\nthe rseq_cs field is non-zero. However, some older versions of glibc\nwill reuse the rseq area of previous threads without clearing the\nrseq_cs field and will also terminate the process if the rseq\nregistration fails in a secondary thread. This wasn\u0026apos;t caught in testing\nbecause in this case the leftover rseq_cs does point to a valid struct\nrseq_cs.\n\nWhat we can do is clear the rseq_cs field on registration when it\u0026apos;s\nnon-zero which will prevent segfaults on registration and won\u0026apos;t break\nthe glibc versions that reuse rseq areas on thread creation.(CVE-2025-38067)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibnvdimm/labels: Fix divide error in nd_label_data_init()\n\nIf a faulty CXL memory device returns a broken zero LSA size in its\nmemory device information (Identify Memory Device (Opcode 4000h), CXL\nspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimm\ndriver:\n\n Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI\n RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]\n\nCode and flow:\n\n1) CXL Command 4000h returns LSA size = 0\n2) config_size is assigned to zero LSA size (CXL pmem driver):\n\ndrivers/cxl/pmem.c: .config_size = mds-\u0026gt;lsa_size,\n\n3) max_xfer is set to zero (nvdimm driver):\n\ndrivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd-\u0026gt;nsarea.max_xfer, config_size);\n\n4) A subsequent DIV_ROUND_UP() causes a division by zero:\n\ndrivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */\ndrivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,\ndrivers/nvdimm/label.c- config_size);\n\nFix this by checking the config size parameter by extending an\nexisting check.(CVE-2025-38072)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost-scsi: protect vq-\u0026gt;log_used with vq-\u0026gt;mutex\n\nThe vhost-scsi completion path may access vq-\u0026gt;log_base when vq-\u0026gt;log_used is\nalready set to false.\n\n vhost-thread QEMU-thread\n\nvhost_scsi_complete_cmd_work()\n-\u0026gt; vhost_add_used()\n -\u0026gt; vhost_add_used_n()\n if (unlikely(vq-\u0026gt;log_used))\n QEMU disables vq-\u0026gt;log_used\n via VHOST_SET_VRING_ADDR.\n mutex_lock(\u0026amp;vq-\u0026gt;mutex);\n vq-\u0026gt;log_used = false now!\n mutex_unlock(\u0026amp;vq-\u0026gt;mutex);\n\n\t\t\t\t QEMU gfree(vq-\u0026gt;log_base)\n log_used()\n -\u0026gt; log_write(vq-\u0026gt;log_base)\n\nAssuming the VMM is QEMU. The vq-\u0026gt;log_base is from QEMU userpace and can be\nreclaimed via gfree(). As a result, this causes invalid memory writes to\nQEMU userspace.\n\nThe control queue path has the same issue.(CVE-2025-38074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: pcm: Fix race of buffer access at PCM OSS layer\n\nThe PCM OSS layer tries to clear the buffer with the silence data at\ninitialization (or reconfiguration) of a stream with the explicit call\nof snd_pcm_format_set_silence() with runtime-\u0026gt;dma_area. But this may\nlead to a UAF because the accessed runtime-\u0026gt;dma_area might be freed\nconcurrently, as it\u0026apos;s performed outside the PCM ops.\n\nFor avoiding it, move the code into the PCM core and perform it inside\nthe buffer access lock, so that it won\u0026apos;t be changed during the\noperation.(CVE-2025-38078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Increase block_sequence array size\n\n[Why]\nIt\u0026apos;s possible to generate more than 50 steps in hwss_build_fast_sequence,\nfor example with a 6-pipe asic where all pipes are in one MPC chain. This\noverflows the block_sequence buffer and corrupts block_sequence_steps,\ncausing a crash.\n\n[How]\nExpand block_sequence to 100 items. A naive upper bound on the possible\nnumber of steps for a 6-pipe asic, ignoring the potential for steps to be\nmutually exclusive, is 91 with current code, therefore 100 is sufficient.(CVE-2025-38080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi-rockchip: Fix register out of bounds access\n\nDo not write native chip select stuff for GPIO chip selects.\nGPIOs can be numbered much higher than native CS.\nAlso, it makes no sense.(CVE-2025-38081)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/rapidio/rio_cm.c: prevent possible heap overwrite\n\nIn\n\nriocm_cdev_ioctl(RIO_CM_CHAN_SEND)\n -\u0026gt; cm_chan_msg_send()\n -\u0026gt; riocm_ch_send()\n\ncm_chan_msg_send() checks that userspace didn\u0026apos;t send too much data but\nriocm_ch_send() failed to check that userspace sent sufficient data. The\nresult is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr\nwhich were outside the bounds of the space which cm_chan_msg_send()\nallocated.\n\nAddress this by teaching riocm_ch_send() to check that the entire\nrio_ch_chan_hdr was copied in from userspace.(CVE-2025-38090)\n\nA vulnerability was found in Linux Kernel up to 6.14.7 (Operating System). It has been classified as critical.CWE is classifying the issue as CWE-833. The product contains multiple threads or executable segments that are waiting for each other to release a necessary lock, resulting in deadlock.This is going to have an impact on availability.Upgrading to version 5.10.238, 5.15.184, 6.1.140, 6.6.92, 6.12.30 or 6.14.8 eliminates this vulnerability. Applying the patch 0772a608d799ac0d127c0a36047a2725777aba9d/64675a9c00443b2e8af42af08c38fc1b78b68ba2/aace6b63892ce8307e502a60fe2f5a4bc6e1cfe7/1d60c0781c1bbeaa1196b0d8aad5c435f06cb7c4/3e64d35475aa21d13dab71da51de51923c1a3a48/84f98955a9de0e0f591df85aa1a44f3ebcf1cb37/c92d6089d8ad7d4d815ebcedee3f3907b539ff1f is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19769).(CVE-2025-38094)\n\nA vulnerability has been found in Linux Kernel up to 6.1.139/6.6.91/6.12.29/6.14.7 (Operating System) and classified as critical.The CWE definition for the vulnerability is CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.As an impact it is known to affect availability.Upgrading to version 6.1.140, 6.6.92, 6.12.30 or 6.14.8 eliminates this vulnerability. Applying the patch 3becc659f9cb76b481ad1fb71f54d5c8d6332d3f/c9d2b9a80d06a58f37e0dc8c827075639b443927/fe1bebd0edb22e3536cbc920ec713331d1367ad4/08680c4dadc6e736c75bc2409d833f03f9003c51/72c7d62583ebce7baeb61acce6057c361f73be4a is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19768).(CVE-2025-38095)\n\nA vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.12.30/6.14.8 (Operating System).CWE is classifying the issue as CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.This is going to have an impact on availability.Upgrading to version 6.12.31 or 6.14.9 eliminates this vulnerability. Applying the patch f48ee562c095e552a30b8d9cc0566a267b410f8a/ec1f015ec0c6fd250a6564e8452f7bb3160b9cb1/14d17c78a4b1660c443bae9d38c814edea506f62 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19764).(CVE-2025-38099)\n\nA vulnerability classified as problematic was found in Linux Kernel up to 6.16-rc1 (Operating System).The CWE definition for the vulnerability is CWE-362. The product contains a code sequence that can run concurrently with other code, and the code sequence requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence that is operating concurrently.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 2790c4ec481be45a80948d059cd7c9a06bc37493/a1bf6a4e9264a685b0e642994031f9c5aad72414/110a47efcf23438ff8d31dbd9c854fae2a48bf98/f569984417a4e12c67366e69bdcb752970de921d/2a71924ca4af59ffc00f0444732b6cd54b153d0e/4b755305b2b0618e857fdadb499365b5f2e478d1/444ad445df5496a785705019268a8a84b84484bb/85a3e0ede38450ea3053b8c45d28cf55208409b8 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38108)\n\nA vulnerability was found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2/6.16-rc1 (Operating System) and classified as critical.Using CWE to declare the problem leads to CWE-416. Referencing memory after it has been freed can cause a program to crash, use unexpected values, or execute code.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc2 eliminates this vulnerability. Applying the patch 3c9aba9cbdf163e2654be9f82d43ff8a04273962/9f66b6531c2b4e996bb61720ee94adb4b2e8d1be/9df3e5e7f7e4653fd9802878cedc36defc5ef42d/32aa2fbe319f33b0318ec6f4fceb63879771a286/e6ed54e86aae9e4f7286ce8d5c73780f91b48d1c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38118)\n\nA vulnerability classified as critical has been found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2 (Operating System).CWE is classifying the issue as CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 6bf529ce84dccc0074dbc704e70aee4aa545057e/4e9e45746b861ebd54c03ef301da2cb8fc990536/19bd9cde38dd4ca1771aed7afba623e7f4247c8e/7eeb3df6f07a886bdfd52757ede127a59a8784dc/25be318324563c63cbd9cb53186203a08d2f83a1 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38142)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.15.2 (Operating System).Using CWE to declare the problem leads to CWE-129. The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 4b9a086eedc1fddae632310386098c12155e3d0a/ad17eb86d042d72a59fd184ad1adf34f5eb36843/f26fe7c3002516dd3c288f1012786df31f4d89e0/8ebcd311b4866ab911d1445ead08690e67f0c488/69541e58323ec3e3904e1fa87a6213961b1f52f4/3c1906a3d50cb94fd0a10e97a1c0a40c0f033cb7/0bdc924bfb319fb10d1113cbf091fc26fb7b1f99 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38146)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Clear table_sz when rproc_shutdown\n\nThere is case as below could trigger kernel dump:\nUse U-Boot to start remote processor(rproc) with resource table\npublished to a fixed address by rproc. After Kernel boots up,\nstop the rproc, load a new firmware which doesn\u0026apos;t have resource table\n,and start rproc.\n\nWhen starting rproc with a firmware not have resource table,\n`memcpy(loaded_table, rproc-\u0026gt;cached_table, rproc-\u0026gt;table_sz)` will\ntrigger dump, because rproc-\u0026gt;cache_table is set to NULL during the last\nstop operation, but rproc-\u0026gt;table_sz is still valid.\n\nThis issue is found on i.MX8MP and i.MX9.\n\nDump as below:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\nMem abort info:\n ESR = 0x0000000096000004\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x04: level 0 translation fault\nData abort info:\n ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000\n[0000000000000000] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in:\nCPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38\nHardware name: NXP i.MX8MPlus EVK board (DT)\npstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __pi_memcpy_generic+0x110/0x22c\nlr : rproc_start+0x88/0x1e0\nCall trace:\n __pi_memcpy_generic+0x110/0x22c (P)\n rproc_boot+0x198/0x57c\n state_store+0x40/0x104\n dev_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x120/0x1cc\n vfs_write+0x240/0x378\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x30/0xcc\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n\nClear rproc-\u0026gt;table_sz to address the issue.(CVE-2025-38152)\n\nA vulnerability classified as problematic has been found in Linux Kernel up to 5.15.185/6.1.141/6.6.93/6.12.33/6.15.2 (Operating System).CWE is classifying the issue as CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.This is going to have an impact on confidentiality.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 1ee8ea6937d13b20f90ff35d71ccc03ba448182d/68a1037f0bac4de9a585aa9c879ef886109f3647/74e18211c2c89ab66c9546baa7408288db61aa0d/c13255389499275bc5489a0b5b7940ccea3aef04/9febcc8bded8be0d7efd8237fcef599b6d93b788/4c2c372de2e108319236203cce6de44d70ae15cd is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19785).(CVE-2025-38159)\n\nA vulnerability was found in Linux Kernel up to 6.15.2 (Operating System). It has been rated as problematic.Impacted is confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch 49bc7bf38e42cfa642787e947f5721696ea73ac3/f1b743c1955151bd392539b739a3ad155296be13/6a324d77f7ea1a91d55c4b6ad970e3ac9ab6a20d/25f3776b58c1c45ad2e50ab4b263505b4d2378ca/a39cc43efc1bca74ed9d6cf9e60b995071f7d178/65b3f76592aed5a43c4d79375ac097acf975972b/ccc28c0397f75a3ec9539cceed9db014d7b73869/05872a167c2cab80ef186ef23cc34a6776a1a30c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19781).(CVE-2025-38163)\n\nA vulnerability was found in Linux Kernel up to 6.1.141/6.6.93/6.12.33/6.15.2 (Operating System). It has been classified as problematic.CWE is classifying the issue as CWE-345. The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch de89368de3894a8db27caeb8fd902ba1c49f696a/43be952e885476dafb74aa832c0847b2f4f650c6/6103f9ba51a59afb5a0f32299c837377c5a5a693/c4a4786d93e99517d6f10ed56b9ffba4ce88d3b3/d3eaab3c70905c5467e5c4ea403053d67505adeb is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-19774).(CVE-2025-38170)\n\nA vulnerability, which was classified as problematic, was found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc2 (Operating System).This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 3162d8235c8c4d585525cee8a59d1c180940a968/0f8df5d6f25ac17c52a8bc6418e60a3e63130550/e2b2b7cf6368580114851cb3932f2ad9fbf23386/8c8472855884355caf3d8e0c50adf825f83454b2 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38182)\n\nA vulnerability was found in Linux Kernel (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-252. The product does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch b427d98d55217b53c88643579fbbd8a4c351a105/985f086f281b7bbb6644851e63af1a17ffff9277/b5c7397b7fd125203c60b59860c168ee92291272/ee084fa96123ede8b0563a1b5a9b23adc43cd50d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38195)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit.Impacted is availability.Upgrading to version 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 5e8c658acd1b7c186aeffa46bf08795e121f401a/07d7b8e7ef7d1f812a6211ed531947c56d09e95e/a7b477b64ef5e37cb08dd536ae07c46f9f28262e/f3b840fb1508a80cd8a0efb5c886ae1995a88b24/4d71f2c1e5263a9f042faa71d59515709869dc79/32d05e6cc3a7bf6c8f16f7b7ef8fe80eca0c233e/61ce04601e0d8265ec6d2ffa6df5a7e1bce64854 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38197)\n\nA vulnerability was found in Linux Kernel up to 6.1.141/6.6.94/6.12.34/6.15.3 (Operating System). It has been declared as problematic.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch 2f8c69a72e8ad87b36b8052f789da3cc2b2e186c/7bf4461f1c97207fda757014690d55a447ce859f/2d834477bbc1e8b8a59ff8b0c081529d6bed7b22/b522d4d334f206284b1a44b0b0b2f99fd443b39b/d4965578267e2e81f67c86e2608481e77e9c8569 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38202)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: cxusb: no longer judge rbuf when the write fails\n\nsyzbot reported a uninit-value in cxusb_i2c_xfer. [1]\n\nOnly when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()\nsucceeds and rlen is greater than 0, the read operation of usb_bulk_msg()\nwill be executed to read rlen bytes of data from the dvb device into the\nrbuf.\n\nIn this case, although rlen is 1, the write operation failed which resulted\nin the dvb read operation not being executed, and ultimately variable i was\nnot initialized.\n\n[1]\nBUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]\nBUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196\n cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]\n cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196\n __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1\n i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315\n i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343\n i2c_master_send include/linux/i2c.h:109 [inline]\n i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183\n do_loop_readv_writev fs/read_write.c:848 [inline]\n vfs_writev+0x963/0x14e0 fs/read_write.c:1057\n do_writev+0x247/0x5c0 fs/read_write.c:1101\n __do_sys_writev fs/read_write.c:1169 [inline]\n __se_sys_writev fs/read_write.c:1166 [inline]\n __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166\n x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-38229)\n\nA vulnerability was found in Linux Kernel up to 6.15.2/fc2778c42f99c7de52fc004157b3c3ee4dcc208a (Operating System). It has been rated as problematic.Impacted is confidentiality, integrity, and availability.Upgrading to version 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch ac49b7560b4b08b1e4043a29214cc7ad77644c00/e2d2115e56c4a02377189bfc3a9a7933552a7b0f is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38279)\n\nA vulnerability, which was classified as problematic, was found in Linux Kernel (Operating System).CWE is classifying the issue as CWE-74. The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component.This is going to have an impact on confidentiality, integrity, and availability.Upgrading to version 5.15.186, 6.1.142, 6.6.94, 6.12.34, 6.15.3 or 6.16-rc1 eliminates this vulnerability. Applying the patch e7fb4ebee6e900899d2b2e5852c3e2eafcbcad66/ef92b96530d1731d9ac167bc7c193c683cd78fff/6f639c25bfad17d9fd7379ab91ff9678ea9aac85/2bc6dffb4b72d53d6a6ada510269bf548c3f7ae0/0b9bb52796b239de6792d0d68cdc6eb505ebff96/86bc9c742426a16b52a10ef61f5b721aecca2344 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38280)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc2 (Operating System). It has been declared as problematic.The CWE definition for the vulnerability is CWE-125. The product reads data past the end, or before the beginning, of the intended buffer.As an impact it is known to affect confidentiality.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch 64773b3ea09235168a549a195cba43bb867c4a17/67abac27d806e8f9d4226ec1528540cf73af673a/92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38/01f91d415a8375d85e0c7d3615cd4a168308bb7c/21da6d3561f373898349ca7167c9811c020da695/22f935bc86bdfbde04009f05eee191d220cd8c89/422e565b7889ebfd9c8705a3fc786642afe61fca/39dfc971e42d886e7df01371cd1bef505076d84c is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.The vulnerability is also documented in the vulnerability database at EUVD (EUVD-2025-20926).(CVE-2025-38320)\n\nA vulnerability was found in Linux Kernel up to 6.15.3/6.16-rc2 (Operating System). It has been rated as critical.Using CWE to declare the problem leads to CWE-404. The product does not release or incorrectly releases a resource before it is made available for re-use.Impacted is availability.Upgrading to version 6.15.4 or 6.16-rc3 eliminates this vulnerability. Applying the patch a85cc69acdcb05f8cd226b8ea0778b8e2e887e6f/b0823d5fbacb1c551d793cbfe7af24e0d1fa45ed is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38322)\n\nA vulnerability was found in Linux Kernel up to 6.15.3 (Operating System). It has been declared as critical.The CWE definition for the vulnerability is CWE-119. The product performs operations on a memory buffer, but it can read from or write to a memory location that is outside of the intended boundary of the buffer.As an impact it is known to affect confidentiality, integrity, and availability.Upgrading to version 5.4.295, 5.10.239, 5.15.186, 6.1.142, 6.6.95, 6.12.35, 6.15.4 or 6.16-rc1 eliminates this vulnerability. Applying the patch d064c68781c19f378af1ae741d9132d35d24b2bb/8690cd3258455bbae64f809e1d3ee0f043661c71/6805582abb720681dd1c87ff677f155dcf4e86c9/03a162933c4a03b9f1a84f7d8482903c7e1e11bb/83a692a9792aa86249d68a8ac0b9d55ecdd255fa/8e89c17dc8970c5f71a3a991f5724d4c8de42d8c/f78a786ad9a5443a29eef4dae60cde85b7375129/f914b52c379c12288b7623bb814d0508dbe7481d is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.(CVE-2025-38346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: fix slab-out-of-bounds read in ea_get()\n\nDuring the \u0026quot;size_check\u0026quot; label in ea_get(), the code checks if the extended\nattribute list (xattr) size matches ea_size. If not, it logs\n\u0026quot;ea_get: invalid extended attribute\u0026quot; and calls print_hex_dump().\n\nHere, EALIST_SIZE(ea_buf-\u0026gt;xattr) returns 4110417968, which exceeds\nINT_MAX (2,147,483,647). Then ea_size is clamped:\n\n\tint size = clamp_t(int, ea_size, 0, EALIST_SIZE(ea_buf-\u0026gt;xattr));\n\nAlthough clamp_t aims to bound ea_size between 0 and 4110417968, the upper\nlimit is treated as an int, causing an overflow above 2^31 - 1. This leads\n\u0026quot;size\u0026quot; to wrap around and become negative (-184549328).\n\nThe \u0026quot;size\u0026quot; is then passed to print_hex_dump() (called \u0026quot;len\u0026quot; in\nprint_hex_dump()), it is passed as type size_t (an unsigned\ntype), this is then stored inside a variable called\n\u0026quot;int remaining\u0026quot;, which is then assigned to \u0026quot;int linelen\u0026quot; which\nis then passed to hex_dump_to_buffer(). In print_hex_dump()\nthe for loop, iterates through 0 to len-1, where len is\n18446744073525002176, calling hex_dump_to_buffer()\non each iteration:\n\n\tfor (i = 0; i \u0026lt; len; i += rowsize) {\n\t\tlinelen = min(remaining, rowsize);\n\t\tremaining -= rowsize;\n\n\t\thex_dump_to_buffer(ptr + i, linelen, rowsize, groupsize,\n\t\t\t\t linebuf, sizeof(linebuf), ascii);\n\n\t\t...\n\t}\n\nThe expected stopping condition (i \u0026lt; len) is effectively broken\nsince len is corrupted and very large. This eventually leads to\nthe \u0026quot;ptr+i\u0026quot; being passed to hex_dump_to_buffer() to get closer\nto the end of the actual bounds of \u0026quot;ptr\u0026quot;, eventually an out of\nbounds access is done in hex_dump_to_buffer() in the following\nfor loop:\n\n\tfor (j = 0; j \u0026lt; len; j++) {\n\t\t\tif (linebuflen \u0026lt; lx + 2)\n\t\t\t\tgoto overflow2;\n\t\t\tch = ptr[j];\n\t\t...\n\t}\n\nTo fix this we should validate \u0026quot;EALIST_SIZE(ea_buf-\u0026gt;xattr)\u0026quot;\nbefore it is utilised.(CVE-2025-39735)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nobjtool, spi: amd: Fix out-of-bounds stack access in amd_set_spi_freq()\n\nIf speed_hz \u0026lt; AMD_SPI_MIN_HZ, amd_set_spi_freq() iterates over the\nentire amd_spi_freq array without breaking out early, causing \u0026apos;i\u0026apos; to go\nbeyond the array bounds.\n\nFix that by stopping the loop when it gets to the last entry, so the low\nspeed_hz value gets clamped up to AMD_SPI_MIN_HZ.\n\nFixes the following warning with an UBSAN kernel:\n\n drivers/spi/spi-amd.o: error: objtool: amd_set_spi_freq() falls through to next function amd_spi_set_opcode()(CVE-2025-40014)",
"id": "OESA-2025-1870",
"modified": "2026-08-06T11:08:57Z",
"published": "2025-07-18T11:08:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1870"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47732"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21996"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22033"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22101"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23141"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23149"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37739"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37784"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37808"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37810"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37842"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37849"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37854"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37887"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37930"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37933"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37937"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37948"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37951"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37963"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37968"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37984"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38023"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38034"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38060"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38065"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38067"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38072"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38074"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38078"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38080"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38090"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38094"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38095"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38099"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38108"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38118"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38142"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38146"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38152"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38159"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38163"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38170"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38182"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38195"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38197"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38202"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38229"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38279"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38320"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38322"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38346"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39735"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40014"
}
],
"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-47732",
"CVE-2025-21861",
"CVE-2025-21996",
"CVE-2025-22033",
"CVE-2025-22101",
"CVE-2025-22108",
"CVE-2025-23141",
"CVE-2025-23149",
"CVE-2025-37739",
"CVE-2025-37784",
"CVE-2025-37808",
"CVE-2025-37810",
"CVE-2025-37842",
"CVE-2025-37849",
"CVE-2025-37854",
"CVE-2025-37887",
"CVE-2025-37930",
"CVE-2025-37933",
"CVE-2025-37937",
"CVE-2025-37948",
"CVE-2025-37951",
"CVE-2025-37963",
"CVE-2025-37968",
"CVE-2025-37984",
"CVE-2025-37991",
"CVE-2025-38007",
"CVE-2025-38023",
"CVE-2025-38034",
"CVE-2025-38060",
"CVE-2025-38065",
"CVE-2025-38067",
"CVE-2025-38072",
"CVE-2025-38074",
"CVE-2025-38078",
"CVE-2025-38080",
"CVE-2025-38081",
"CVE-2025-38090",
"CVE-2025-38094",
"CVE-2025-38095",
"CVE-2025-38099",
"CVE-2025-38108",
"CVE-2025-38118",
"CVE-2025-38142",
"CVE-2025-38146",
"CVE-2025-38152",
"CVE-2025-38159",
"CVE-2025-38163",
"CVE-2025-38170",
"CVE-2025-38182",
"CVE-2025-38195",
"CVE-2025-38197",
"CVE-2025-38202",
"CVE-2025-38229",
"CVE-2025-38279",
"CVE-2025-38280",
"CVE-2025-38320",
"CVE-2025-38322",
"CVE-2025-38346",
"CVE-2025-39735",
"CVE-2025-40014"
]
}
oesa-2026-3532
Vulnerability from osv_openeuler
The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
uaccess: fix integer overflow on access_ok()
Three architectures check the end of a user access against the address limit without taking a possible overflow into account. Passing a negative length or another overflow in here returns success when it should not.
Use the most common correct implementation here, which optimizes for a constant 'size' argument, and turns the common case into a single comparison.(CVE-2022-49289)
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix double SIGFPE crash
Camm noticed that on parisc a SIGFPE exception will crash an application with a second SIGFPE in the signal handler. Dave analyzed it, and it happens because glibc uses a double-word floating-point store to atomically update function descriptors. As a result of lazy binding, we hit a floating-point store in fpe_func almost immediately.
When the T bit is set, an assist exception trap occurs when when the co-processor encounters any floating-point instruction except for a double store of register %fr0. The latter cancels all pending traps. Let's fix this by clearing the Trap (T) bit in the FP status register before returning to the signal handler in userspace.
The issue can be reproduced with this test program:
root@parisc:~# cat fpe.c
static void fpe_func(int sig, siginfo_t i, void v) { sigset_t set; sigemptyset(&set); sigaddset(&set, SIGFPE); sigprocmask(SIG_UNBLOCK, &set, NULL); printf("GOT signal %d with si_code %ld\n", sig, i->si_code); }
int main() { struct sigaction action = { .sa_sigaction = fpe_func, .sa_flags = SA_RESTART|SA_SIGINFO }; sigaction(SIGFPE, &action, 0); feenableexcept(FE_OVERFLOW); return printf("%lf\n",1.7976931348623158E308*1.7976931348623158E308); }
root@parisc:~# gcc fpe.c -lm root@parisc:~# ./a.out Floating point exception
root@parisc:~# strace -f ./a.out execve("./a.out", ["./a.out"], 0xf9ac7034 / 20 vars /) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 ... rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} --- --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} --- +++ killed by SIGFPE +++ Floating point exception(CVE-2025-37991)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()
kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries.
Return -ENOMEM on allocation failure to avoid the NULL dereference.(CVE-2025-68190)
In the Linux kernel, the following vulnerability has been resolved:
arm64/fpsimd: signal: Fix restoration of SVE context
When SME is supported, Restoring SVE signal context can go wrong in a few ways, including placing the task into an invalid state where the kernel may read from out-of-bounds memory (and may potentially take a fatal fault) and/or may kill the task with a SIGKILL.
(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into an invalid state where SVCR.SM is set (and sve_state is non-NULL) but TIF_SME is clear, consequently resuting in out-of-bounds memory reads and/or killing the task with SIGKILL.
This can only occur in unusual (but legitimate) cases where the SVE
signal context has either been modified by userspace or was saved in
the context of another task (e.g. as with CRIU), as otherwise the
presence of an SVE signal context with SVE_SIG_FLAG_SM implies that
TIF_SME is already set.
While in this state, task_fpsimd_load() will NOT configure SMCR_ELx
(leaving some arbitrary value configured in hardware) before
restoring SVCR and attempting to restore the streaming mode SVE
registers from memory via sve_load_state(). As the value of
SMCR_ELx.LEN may be larger than the task's streaming SVE vector
length, this may read memory outside of the task's allocated
sve_state, reading unrelated data and/or triggering a fault.
While this can result in secrets being loaded into streaming SVE
registers, these values are never exposed. As TIF_SME is clear,
fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0
accesses to streaming mode SVE registers, so these cannot be
accessed directly at EL0. As fpsimd_save_user_state() verifies the
live vector length before saving (S)SVE state to memory, no secret
values can be saved back to memory (and hence cannot be observed via
ptrace, signals, etc).
When the live vector length doesn't match the expected vector length
for the task, fpsimd_save_user_state() will send a fatal SIGKILL
signal to the task. Hence the task may be killed after executing
userspace for some period of time.
(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the task's SVCR.SM. If SVCR.SM was set prior to restoring the context, then the task will be left in streaming mode unexpectedly, and some register state will be combined inconsistently, though the task will be left in legitimate state from the kernel's PoV.
This can only occur in unusual (but legitimate) cases where ptrace
has been used to set SVCR.SM after entry to the sigreturn syscall,
as syscall entry clears SVCR.SM.
In these cases, the the provided SVE register data will be loaded
into the task's sve_state using the non-streaming SVE vector length
and the FPSIMD registers will be merged into this using the
streaming SVE vector length.
Fix (1) by setting TIF_SME when setting SVCR.SM. This also requires ensuring that the task's sme_state has been allocated, but as this could contain live ZA state, it should not be zeroed. Fix (2) by clearing SVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.
For consistency, I've pulled the manipulation of SVCR, TIF_SVE, TIF_SME, and fp_type earlier, immediately after the allocation of sve_state/sme_state, before the restore of the actual register state. This makes it easier to ensure that these are always modified consistently, even if a fault is taken while reading the register data from the signal context. I do not expect any software to depend on the exact state restored when a fault is taken while reading the context.(CVE-2026-23102)
In the Linux kernel, the following vulnerability has been resolved:
net: ncsi: fix skb leak in error paths
Early return paths in NCSI RX and AEN handlers fail to release the received skb, resulting in a memory leak.
Specifically, ncsi_aen_handler() returns on invalid AEN packets without consuming the skb. Similarly, ncsi_rcv_rsp() exits early when failing to resolve the NCSI device, response handler, or request, leaving the skb unfreed.(CVE-2026-43373)
In the Linux kernel, the following vulnerability has been resolved: selinux: fix overlayfs mmap() and mprotect() access checks The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the "user" file) and the mounter's credentials are sufficient to access the lower level file (the "backing" file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems. This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls. The Linux kernel CVE team has assigned CVE-2026-46054 to this issue.(CVE-2026-46054)
In the Linux kernel, the following vulnerability has been resolved:
fbcon: Avoid OOB font access if console rotation fails
Clear the font buffer if the reallocation during console rotation fails in fbcon_rotate_font(). The putcs implementations for the rotated buffer will return early in this case. See [1] for an example.
Currently, fbcon_rotate_font() keeps the old buffer, which is too small for the rotated font. Printing to the rotated console with a high-enough character code will overflow the font buffer.
v2: - fix typos in commit message(CVE-2026-46191)
In the Linux kernel, the following vulnerability has been resolved:
vsock: fix buffer size clamping order
In vsock_update_buffer_size(), the buffer size was being clamped to the maximum first, and then to the minimum. If a user sets a minimum buffer size larger than the maximum, the minimum check overrides the maximum check, inverting the constraint.
This breaks the intended socket memory boundaries by allowing the vsk->buffer_size to grow beyond the configured vsk->buffer_max_size.
Fix this by checking the minimum first, and then the maximum. This ensures the buffer size never exceeds the buffer_max_size.(CVE-2026-46234)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths
Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer Dereference (NPD) conditions were observed in the lifecycle management of hci_uart.
The primary issue arises because the workqueues (init_ready and
write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY
flag is set during TTY close. If a hangup occurs before setup completes,
hci_uart_tty_close() skips the teardown of these workqueues and
proceeds to free the hu struct. When the scheduled work executes
later, it blindly dereferences the freed hu struct.
Furthermore, several data races and UAFs were identified in the teardown sequence: 1. Calling hci_uart_flush() from hci_uart_close() without effectively disabling write_work causes a race condition where both can concurrently double-free hu->tx_skb. This happens because protocol timers can concurrently invoke hci_uart_tx_wakeup() and requeue write_work. 2. Calling hci_free_dev(hdev) before hu->proto->close(hu) causes a UAF when vendor specific protocol close callbacks dereference hu->hdev. 3. In the initialization error paths, failing to take the proto_lock write lock before clearing PROTO_READY leads to races with active readers. Additionally, hci_uart_tty_receive() accesses hu->hdev outside the read lock, leading to UAFs if the initialization error path frees hdev concurrently.
Fix these synchronization and lifecycle issues by: 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first, followed immediately by a cancel_work_sync(&hu->write_work). Clearing the flag locks out concurrent protocol timers from successfully invoking hci_uart_tx_wakeup(), effectively rendering the cancellation permanent and preventing the tx_skb double-free. 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip hu->proto->flush(). This is perfectly safe in the tty_close path because hu->proto->close() executes shortly after, which intrinsically purges all protocol SKB queues and tears down the state. 3. Relocating hu->proto->close(hu) strictly prior to hci_free_dev(hdev) across all close and error paths to prevent vendor-level UAFs. 4. Moving the hdev->stat.byte_rx increment in hci_uart_tty_receive() inside the proto_lock read-side critical section to safely synchronize with device unregistration. 5. Adding cancel_work_sync(&hu->write_work) to hci_uart_close() to safely flush the workqueue before hci_uart_flush() is invoked via the HCI core. 6. Utilizing cancel_work_sync() instead of disable_work_sync() across all paths to prevent permanently breaking user-space retry capabilities.(CVE-2026-46275)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: terminate the cached volume label after UTF-8 conversion
ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL.
If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator.
Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer.(CVE-2026-53023)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2/dlm: validate qr_numregions in dlm_match_regions()
Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()".
In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION network message is used to drive loops over the qr_regions buffer without sufficient validation. This series fixes two issues:
-
Patch 1 adds a bounds check to reject messages where qr_numregions exceeds O2NM_MAX_REGIONS. The o2net layer only validates message byte length; it does not constrain field values, so a crafted message can set qr_numregions up to 255 and trigger out-of-bounds reads past the 1024-byte qr_regions buffer.
-
Patch 2 fixes an off-by-one in the local-vs-remote comparison loop, which uses '<=' instead of '<', reading one entry past the valid range even when qr_numregions is within bounds.
This patch (of 2):
The qr_numregions field from a DLM_QUERY_REGION network message is used directly as loop bounds in dlm_match_regions() without checking against O2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS (32) entries, a crafted message with qr_numregions > 32 causes out-of-bounds reads past the qr_regions buffer.
Add a bounds check for qr_numregions before entering the loops.(CVE-2026-53043)
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet
The irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and scheduled when RTL_IMR_BCNINT interrupt is triggered by hardware. But it is never killed in rtl_pci_deinit(). When the rtlwifi card probe fails or is being detached, the ieee80211_hw is deallocated. However, irq_prepare_bcn_tasklet may still be running or pending, leading to use-after-free when the freed ieee80211_hw is accessed in _rtl_pci_prepare_bcn_tasklet().
Similar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to ensure that irq_prepare_bcn_tasklet is properly terminated before the ieee80211_hw is released.
The issue was identified through static analysis.(CVE-2026-53112)
In the Linux kernel, the following vulnerability has been resolved:
PCI: use generic driver_override infrastructure
When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.
Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.
Note that calling match() from __driver_attach() without the device lock held is intentional. 1
In the Linux kernel, the following vulnerability has been resolved:
net: ip_gre: require CAP_NET_ADMIN in the device netns for changelink
A tunnel changelink() operates on at most two netns, dev_net(dev) and the tunnel link netns t->net. They differ once the device is created in or moved to a netns other than the one the request runs in. The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev), so a caller privileged there but not in t->net can rewrite a tunnel that lives in t->net.
Add rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in net/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is skipped when the link netns is dev_net(dev), where the rtnl path already checked it. The other patches in this series use the same helper.
Gate ipgre_changelink() and erspan_changelink() with it, at the top of the op before any attribute is parsed, because the parsers update live tunnel fields first. ipgre_netlink_parms() sets t->collect_md before ip_tunnel_changelink() runs.
Commit 8b484efd5cb4 ("ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().") added the same check on the ioctl path. This adds it on RTM_NEWLINK.(CVE-2026-63829)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: validate extension header length before copying to cmsg
ip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR} cmsgs (and their IPV6_2292* legacy counterparts) by trusting the on-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length. The length was validated only at parse time (ipv6_parse_hopopts(), etc.). An nftables payload-write expression can rewrite hdrlen after parsing and before the skb reaches recvmsg; the write itself is in-bounds but put_cmsg() then reads up to ((hdrlen+1) << 3) = 2040 bytes from an 8-byte header. nftables is reachable from an unprivileged user namespace, so this is an unprivileged slab-out-of-bounds read:
BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540 put_cmsg+0x3ac/0x540 udpv6_recvmsg+0xca0/0x1250 sock_recvmsg+0xdf/0x190 ____sys_recvmsg+0x1b1/0x620
Add ipv6_get_exthdr_len() which validates that at least two bytes are accessible before reading the hdrlen field, then checks the computed length against skb_tail_pointer(skb), returning 0 on failure. Extension headers are kept in the linear skb area by pskb_may_pull() during input, so skb_tail_pointer() is the correct bound.
Use ipv6_get_exthdr_len() at all non-AH call sites: the five standalone cmsg blocks (HbH, 2292HbH, 2292DSTOPTS x2, 2292RTHDR) and the three standard cases in the extension-header walk loop (DSTOPTS, ROUTING, default). AH retains an inline bounds check because its length formula differs ((ptr[1]+2)<<2).
The walk loop also gets a pre-read bounds check at the top to validate ptr before any case accesses ptr[0] or ptr[1].
When the walk loop detects a corrupted header, return from the function instead of continuing to process later socket options.(CVE-2026-63920)
In the Linux kernel, the following vulnerability has been resolved:
ip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().
After patch 1/2 in this series, vti6_update() unlinks and relinks the tunnel through t->net. vti6_siocdevprivate() still uses dev_net(dev) for the collision lookup. For a tunnel moved through IFLA_NET_NS_FD, dev_net(dev) is the new netns, not t->net.
SIOCCHGTUNNEL on a migrated tunnel then runs:
net = dev_net(dev) / migrated netns / t = vti6_locate(net, &p1, false) / misses target in t->net / ... t = netdev_priv(dev) vti6_update(t, &p1, false) / mutates t->net's hash /
A caller in the migrated netns picks params that match a tunnel in the creation netns. The lookup in dev_net(dev) finds nothing. vti6_update() prepends the migrated tunnel at the head of the creation netns hash bucket for those params. Later lookups in the creation netns resolve to the migrated device. xfrm receive delivers the matched packets through a device the caller controls.
Reachable from an unprivileged user namespace (unshare --user --map-root-user --net). Cross tenant scope on container hosts.
Switch the SIOCCHGTUNNEL path on a non fallback device to use t->net for the lookup. The lookup now matches the netns vti6_update() operates on.
Also add ns_capable(self->net->user_ns, CAP_NET_ADMIN) before the lookup. The check at the top of the case is against dev_net(dev)->user_ns, which after migration is the attacker's netns. A caller there can pick params absent from self->net, the lookup returns NULL, t becomes self, and vti6_update() inserts the device into the creation netns hash. The new check requires CAP_NET_ADMIN in the creation netns user_ns too.
SIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep dev_net(dev), which equals init_net there.(CVE-2026-63921)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: synproxy: refresh tcphdr after skb_ensure_writable
synproxy_tstamp_adjust() rewrites the TCP timestamp option in place and then patches the TCP checksum via inet_proto_csum_replace4() on the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and ipv6_synproxy_hook() obtain that pointer with skb_header_pointer() before calling in, so it may either alias skb->head directly or point at the caller's on-stack _tcph buffer.
Between obtaining the pointer and using it, the function calls skb_ensure_writable(skb, optend), which on a cloned or non-linear skb invokes pskb_expand_head() and frees the old skb->head. After that point the cached th is stale:
caller (ipv[46]_synproxy_hook)
th = skb_header_pointer(skb, ..., &_tcph)
synproxy_tstamp_adjust(skb, protoff, th, ...)
skb_ensure_writable(skb, optend)
pskb_expand_head() /* kfree(old skb->head) */
...
inet_proto_csum_replace4(&th->check, ...)
/* writes into freed head, or
into the caller's stack copy
leaving the on-wire checksum
stale */
The option bytes are written through skb->data and are fine; only the checksum update goes through th and so lands in the wrong place. The result is either a write into freed slab memory or a packet leaving with a checksum that does not match its payload.
Fix by re-deriving th from skb->data + protoff immediately after skb_ensure_writable() succeeds, so the subsequent checksum update targets the linear, writable header.(CVE-2026-64007)
In the Linux kernel, the following vulnerability has been resolved:
ipv4: raw: reject IP_HDRINCL packets with ihl < 5
raw_send_hdrinc() validates that the caller-supplied IPv4 header fits within the message length:
iphlen = iph->ihl * 4;
err = -EINVAL;
if (iphlen > length)
goto error_free;
if (iphlen >= sizeof(*iph)) {
/* fix up saddr, tot_len, id, csum, transport_header */
}
It does not, however, reject ihl < 5. For such a packet the "if (iphlen >= sizeof(*iph))" branch is skipped, leaving the crafted iphdr untouched, but the packet is still handed to __ip_local_out() and onward. Downstream consumers that read iph->ihl assume a sane value: net/ipv4/ah4.c:ah_output() in particular subtracts sizeof(struct iphdr) from top_iph->ihl * 4 and passes the (signed-int-negative, then cast to size_t) result to memcpy(), producing an OOB access of length close to SIZE_MAX and a host kernel panic.
An IPv4 header with ihl < 5 is malformed by definition (RFC 791: "Internet Header Length is the length of the internet header in 32 bit words ... Note that the minimum value for a correct header is 5."). The kernel should not be willing to inject such a packet into its own output path.
Reject "iphlen < sizeof(*iph)" alongside the existing "iphlen > length" check. This matches the principle that locally constructed packets that re-enter the IP stack must pass the same basic sanity tests that a foreign packet would be subjected to.
Once this lands, the "if (iphlen >= sizeof(*iph))" wrapper around the fixup branch becomes redundant; left in place to keep the patch minimal and backport-friendly. A follow-up can unwrap it.
Note that commit 86f4c90a1c5c ("ipv4, ipv6: ensure raw socket message is big enough to hold an IP header") ensures the message buffer is large enough to hold an iphdr, but does not constrain the self-reported iph->ihl.
Reachability: the malformed packet source is any caller with CAP_NET_RAW, including an unprivileged process in a user+net namespace on a kernel with CONFIG_USER_NS=y. The reproduced AH crash also requires a matching xfrm AH policy on the outgoing route; a container granted CAP_NET_ADMIN can install that state and policy in its netns. Loopback bypasses xfrm_output, so the trigger uses a real netdev.
Reproduced on UML + KASAN: kernel-mode fault at addr 0x0 with memcpy_orig at the crash site. Same shape reproduces inside a rootless Docker container with --cap-add NET_ADMIN on a stock distro kernel.(CVE-2026-64114)
In the Linux kernel, the following vulnerability has been resolved:
ALSA: asihpi: Fix potential OOB array access at reading cache
find_control() to retrieve a cached info accesses the array with the given index blindly, which may lead to an OOB array access. Add a sanity check for avoiding it.(CVE-2026-64133)
In the Linux kernel, the following vulnerability has been resolved:
fuse: re-lock request before returning from fuse_ref_folio()
fuse_ref_folio() unlocks the request but does not re-lock it before returning. fuse_chan_abort() can end the request and the async end callback (eg fuse_writepage_free()) can free the args while the subsequent copy chain logic after fuse_ref_folio() accesses them, leading to use-after-free issues.
Fix this by locking the request in fuse_ref_folio() before returning.(CVE-2026-64266)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes
Reject invalid net.ipv4.tcp_reordering values before they reach TCP
socket state. The sysctl is stored as an int but copied into the
u32 tp->reordering field for new sockets, so negative writes wrap
to large values.
With tcp_mtu_probing=2, the wrapped value can overflow the
tcp_mtu_probe() size calculation and drive the MTU probing path into
an out-of-bounds read. Route tcp_reordering writes through
proc_dointvec_minmax() and require it to be at least 1. Also require
tcp_max_reordering to be at least 1 so the configured maximum cannot
become negative either.
When registering the table for a non-init network namespace, relocate
extra2 pointers that refer into init_net.ipv4 so the
tcp_reordering upper bound follows that namespace's
tcp_max_reordering.
Harden tcp_mtu_probe() itself by computing size_needed as u64.
This keeps the send queue and window checks from being bypassed through
signed integer overflow.(CVE-2026-64422)
In the Linux kernel, the following vulnerability has been resolved:
net: af_key: initialize alg_key_len for IPComp states
pfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by allocating x->calg and copying only the algorithm name:
x->calg = kmalloc_obj(*x->calg);
if (!x->calg) {
err = -ENOMEM;
goto out;
}
strcpy(x->calg->alg_name, a->name);
x->props.calgo = sa->sadb_sa_encrypt;
Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->alg_key_len. IPComp carries no key and the allocation only reserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field is left containing uninitialized slab data.
calg->alg_key_len is later used as a length by xfrm_algo_clone() when an IPComp state is cloned during XFRM_MSG_MIGRATE:
xfrm_state_migrate()
xfrm_state_clone_and_setup()
x->calg = xfrm_algo_clone(orig->calg);
kmemdup(orig, xfrm_alg_len(orig));
where xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With a non-zero garbage alg_key_len, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating it triggers (net-next, KASAN, init_on_alloc=0):
BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: <TASK> dump_stack_lvl+0x10e/0x1f0 print_report+0xf7/0x600 kasan_report+0xe4/0x120 kasan_check_range+0x105/0x1b0 __asan_memcpy+0x23/0x60 kmemdup_noprof+0x44/0x60 xfrm_state_migrate+0x70a/0x1da0 xfrm_migrate+0x753/0x18a0 xfrm_do_migrate+0xb47/0xf10 xfrm_user_rcv_msg+0x411/0xb50 netlink_rcv_skb+0x158/0x420 xfrm_netlink_rcv+0x71/0x90 netlink_unicast+0x584/0x850 netlink_sendmsg+0x8b0/0xdc0 _syssendmsg+0x9f7/0xb90 _sys_sendmsg+0x134/0x1d0 __sys_sendmsg+0x16d/0x220 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK>
Allocated by task 9287: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 pfkey_add+0x2652/0x2ea0 pfkey_process+0x6d0/0x830 pfkey_sendmsg+0x42c/0x850 __sys_sendto+0x461/0x4b0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x116/0x7d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4)
Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail.
The XFRM netlink path is not affected: verify_one_alg() rejects an XFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via XFRM_MSG_NEWSA is always self-consistent.
Initialize calg->alg_key_len to 0, matching the aalg/ealg branches.(CVE-2026-64436)
In the Linux kernel, the following vulnerability has been resolved:
drm/edid: fix OOB read in drm_parse_tiled_block()
drm_parse_tiled_block() casts the DisplayID block to a struct displayid_tiled_block and reads the full fixed layout up to tile->topology_id[7] without checking block->num_bytes. The DisplayID iterator only validates the declared payload length, so a crafted EDID can advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or DATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at the end of a DisplayID extension. The read then runs past the end of the exact-sized kmemdup()'d EDID allocation, a heap out-of-bounds read.
Reject blocks shorter than the spec's 22-byte tiled payload before reading the fixed struct, as drm_parse_vesa_mso_data() already does.
BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update Read of size 2 at addr ffff888010077700 by task exploit/147 dump_stack_lvl (lib/dump_stack.c:94 ...) print_report (mm/kasan/report.c:378 ...) kasan_report (mm/kasan/report.c:595) drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581) bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574) drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426) status_store (drivers/gpu/drm/drm_sysfs.c:219) ... vfs_write (fs/read_write.c:595 fs/read_write.c:688) ksys_write (fs/read_write.c:740)(CVE-2026-64546)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: fix NVM tag length underflow in TLV parser
In the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is "while (idx < length - sizeof(struct tlv_type_nvm))". "length" is a signed int from the firmware TLV header and sizeof(struct tlv_type_nvm) is a size_t (12), so "length" is converted to size_t and any firmware-supplied "length" < 12 makes the subtraction wrap to a huge value. The loop body then reads a 12-byte struct tlv_type_nvm past the end of the short vmalloc'd firmware buffer (and the EDL_TAG_ID_* handlers can write past it).
Rewrite the bound as "idx + sizeof(struct tlv_type_nvm) <= length"; both operands are non-negative, so it no longer underflows and a "length" too small for one record correctly skips the loop.
BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421) Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52 Workqueue: hci0 hci_power_on Call Trace: ... kasan_report (mm/kasan/report.c:595) qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617) qca_uart_setup (drivers/bluetooth/btqca.c:948) qca_setup (drivers/bluetooth/hci_qca.c:2029) hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438) hci_dev_open_sync (net/bluetooth/hci_sync.c:5227) hci_power_on (net/bluetooth/hci_core.c:920) process_one_work (kernel/workqueue.c:3322) worker_thread (kernel/workqueue.c:3486) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245)(CVE-2026-64573)
In the Linux kernel, the following vulnerability has been resolved:
ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()
ceph_handle_caps() reads snap_trace_len from the wire-format ceph_mds_caps header and uses it unconditionally to build a fake end pointer (snaptrace + snaptrace_len) that is later handed to ceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case:
snaptrace = h + 1;
snaptrace_len = le32_to_cpu(h->snap_trace_len);
p = snaptrace + snaptrace_len;
...
case CEPH_CAP_OP_IMPORT:
if (snaptrace_len) {
...
if (ceph_update_snap_trace(mdsc, snaptrace,
snaptrace + snaptrace_len,
false, &realm)) { ... }
ceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm from snaptrace using ceph_decode_need(&p, e, sizeof(*ri), bad) with the attacker-supplied fake end e == snaptrace + snaptrace_len. With snaptrace_len == 0xFFFFFFFF the bound check is trivially satisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past the legitimate msg->front buffer, and ri->num_snaps / ri->num_prior_parent_snaps then drive further out-of-bounds reads of the encoded snap arrays.
The eleven msg_version >= 2 .. msg_version >= 12 decoder blocks above the op switch each catch this OOB through their ceph_decode_*_safe() / ceph_decode_need() helpers, but they sit behind a hdr.version-gated if, so a malicious or compromised MDS that sets msg->hdr.version = 1 reaches the IMPORT path with no version-gated decoder having validated snap_trace_len. The shape has been present since ceph_handle_caps() was introduced.
Validate snap_trace_len against the message front buffer before consuming it, using the canonical ceph_decode_need() / ceph_has_room() helper. The helper bounds the length with subtraction (n <= end - p, guarded by end >= p) rather than pointer addition, so it is wrap-safe for the attacker-controlled u32 length on 32-bit builds where p + snap_trace_len could overflow the address space. This matches the rest of the ceph decode path (e.g. the pool_ns_len check a few lines below), and the existing goto bad cleanup already covers this exit path.(CVE-2026-68160)
In the Linux kernel, the following vulnerability has been resolved:
tpm: Make the TPM character devices non-seekable
The TPM character devices expose a sequential command/response interface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE enabled.
After a command leaves a response pending, pread(fd, buf, 16, 0x1400) passes 0x1400 as off to tpm_common_read(). The transfer length is bounded by response_length, but the offset is used unchecked when forming data_buffer + off. A sufficiently large offset therefore causes an out-of-bounds heap read through copy_to_user() and, if the copy succeeds, an out-of-bounds zero-write through the following memset().
Positional I/O does not provide coherent semantics for this interface. An arbitrary pread offset cannot represent how much of a response has been consumed sequentially. The write callback always stores a command at the start of data_buffer, while pwrite() does not update file->f_pos and can leave the sequential read cursor stale.
Call nonseekable_open() from both open handlers. This removes FMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to fail with -ESPIPE before reaching the TPM callbacks, and explicitly marks the files non-seekable. Normal read() and write() continue to use the existing sequential f_pos cursor, leaving the response state machine unchanged.
Tested on Linux 6.12 with KASAN and a swtpm TPM2 device:
- sequential partial reads returned the complete response
- pread() and preadv() with offset 0x1400 returned -ESPIPE
- pwrite() and pwritev() with offset zero returned -ESPIPE
- the pending response remained intact after the rejected operations
- a subsequent normal command/response cycle completed normally
- no KASAN report was produced.(CVE-2026-72135)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_u32: reject invalid shift counts
u32_match_it() executes rule-supplied shift operands on a 32-bit value. A malformed u32 rule can provide a shift count of 32 or more, triggering an undefined shift out-of-bounds during packet evaluation.
Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in u32_mt_checkentry() and reject malformed rules before they reach the packet path.(CVE-2026-72350)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"perf-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-330.0.0.231.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"perf-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-330.0.0.231.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-330.0.0.231.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-330.0.0.231.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "Critical"
},
"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\nuaccess: fix integer overflow on access_ok()\n\nThree architectures check the end of a user access against the\naddress limit without taking a possible overflow into account.\nPassing a negative length or another overflow in here returns\nsuccess when it should not.\n\nUse the most common correct implementation here, which optimizes\nfor a constant \u0026apos;size\u0026apos; argument, and turns the common case into a\nsingle comparison.(CVE-2022-49289)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix double SIGFPE crash\n\nCamm noticed that on parisc a SIGFPE exception will crash an application with\na second SIGFPE in the signal handler. Dave analyzed it, and it happens\nbecause glibc uses a double-word floating-point store to atomically update\nfunction descriptors. As a result of lazy binding, we hit a floating-point\nstore in fpe_func almost immediately.\n\nWhen the T bit is set, an assist exception trap occurs when when the\nco-processor encounters *any* floating-point instruction except for a double\nstore of register %fr0. The latter cancels all pending traps. Let\u0026apos;s fix this\nby clearing the Trap (T) bit in the FP status register before returning to the\nsignal handler in userspace.\n\nThe issue can be reproduced with this test program:\n\nroot@parisc:~# cat fpe.c\n\nstatic void fpe_func(int sig, siginfo_t *i, void *v) {\n sigset_t set;\n sigemptyset(\u0026amp;set);\n sigaddset(\u0026amp;set, SIGFPE);\n sigprocmask(SIG_UNBLOCK, \u0026amp;set, NULL);\n printf(\u0026quot;GOT signal %d with si_code %ld\\n\u0026quot;, sig, i-\u0026gt;si_code);\n}\n\nint main() {\n struct sigaction action = {\n .sa_sigaction = fpe_func,\n .sa_flags = SA_RESTART|SA_SIGINFO };\n sigaction(SIGFPE, \u0026amp;action, 0);\n feenableexcept(FE_OVERFLOW);\n return printf(\u0026quot;%lf\\n\u0026quot;,1.7976931348623158E308*1.7976931348623158E308);\n}\n\nroot@parisc:~# gcc fpe.c -lm\nroot@parisc:~# ./a.out\n Floating point exception\n\nroot@parisc:~# strace -f ./a.out\n execve(\u0026quot;./a.out\u0026quot;, [\u0026quot;./a.out\u0026quot;], 0xf9ac7034 /* 20 vars */) = 0\n getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0\n ...\n rt_sigaction(SIGFPE, {sa_handler=0x1110a, sa_mask=[], sa_flags=SA_RESTART|SA_SIGINFO}, NULL, 8) = 0\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0x1078f} ---\n --- SIGFPE {si_signo=SIGFPE, si_code=FPE_FLTOVF, si_addr=0xf8f21237} ---\n +++ killed by SIGFPE +++\n Floating point exception(CVE-2025-37991)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()\n\nkcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws\nremains NULL while ectx.ws_size is set, leading to a potential NULL\npointer dereference in atom_get_src_int() when accessing WS entries.\n\nReturn -ENOMEM on allocation failure to avoid the NULL dereference.(CVE-2025-68190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: signal: Fix restoration of SVE context\n\nWhen SME is supported, Restoring SVE signal context can go wrong in a\nfew ways, including placing the task into an invalid state where the\nkernel may read from out-of-bounds memory (and may potentially take a\nfatal fault) and/or may kill the task with a SIGKILL.\n\n(1) Restoring a context with SVE_SIG_FLAG_SM set can place the task into\n an invalid state where SVCR.SM is set (and sve_state is non-NULL)\n but TIF_SME is clear, consequently resuting in out-of-bounds memory\n reads and/or killing the task with SIGKILL.\n\n This can only occur in unusual (but legitimate) cases where the SVE\n signal context has either been modified by userspace or was saved in\n the context of another task (e.g. as with CRIU), as otherwise the\n presence of an SVE signal context with SVE_SIG_FLAG_SM implies that\n TIF_SME is already set.\n\n While in this state, task_fpsimd_load() will NOT configure SMCR_ELx\n (leaving some arbitrary value configured in hardware) before\n restoring SVCR and attempting to restore the streaming mode SVE\n registers from memory via sve_load_state(). As the value of\n SMCR_ELx.LEN may be larger than the task\u0026apos;s streaming SVE vector\n length, this may read memory outside of the task\u0026apos;s allocated\n sve_state, reading unrelated data and/or triggering a fault.\n\n While this can result in secrets being loaded into streaming SVE\n registers, these values are never exposed. As TIF_SME is clear,\n fpsimd_bind_task_to_cpu() will configure CPACR_ELx.SMEN to trap EL0\n accesses to streaming mode SVE registers, so these cannot be\n accessed directly at EL0. As fpsimd_save_user_state() verifies the\n live vector length before saving (S)SVE state to memory, no secret\n values can be saved back to memory (and hence cannot be observed via\n ptrace, signals, etc).\n\n When the live vector length doesn\u0026apos;t match the expected vector length\n for the task, fpsimd_save_user_state() will send a fatal SIGKILL\n signal to the task. Hence the task may be killed after executing\n userspace for some period of time.\n\n(2) Restoring a context with SVE_SIG_FLAG_SM clear does not clear the\n task\u0026apos;s SVCR.SM. If SVCR.SM was set prior to restoring the context,\n then the task will be left in streaming mode unexpectedly, and some\n register state will be combined inconsistently, though the task will\n be left in legitimate state from the kernel\u0026apos;s PoV.\n\n This can only occur in unusual (but legitimate) cases where ptrace\n has been used to set SVCR.SM after entry to the sigreturn syscall,\n as syscall entry clears SVCR.SM.\n\n In these cases, the the provided SVE register data will be loaded\n into the task\u0026apos;s sve_state using the non-streaming SVE vector length\n and the FPSIMD registers will be merged into this using the\n streaming SVE vector length.\n\nFix (1) by setting TIF_SME when setting SVCR.SM. This also requires\nensuring that the task\u0026apos;s sme_state has been allocated, but as this could\ncontain live ZA state, it should not be zeroed. Fix (2) by clearing\nSVCR.SM when restoring a SVE signal context with SVE_SIG_FLAG_SM clear.\n\nFor consistency, I\u0026apos;ve pulled the manipulation of SVCR, TIF_SVE, TIF_SME,\nand fp_type earlier, immediately after the allocation of\nsve_state/sme_state, before the restore of the actual register state.\nThis makes it easier to ensure that these are always modified\nconsistently, even if a fault is taken while reading the register data\nfrom the signal context. I do not expect any software to depend on the\nexact state restored when a fault is taken while reading the context.(CVE-2026-23102)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ncsi: fix skb leak in error paths\n\nEarly return paths in NCSI RX and AEN handlers fail to release\nthe received skb, resulting in a memory leak.\n\nSpecifically, ncsi_aen_handler() returns on invalid AEN packets\nwithout consuming the skb. Similarly, ncsi_rcv_rsp() exits early\nwhen failing to resolve the NCSI device, response handler, or\nrequest, leaving the skb unfreed.(CVE-2026-43373)\n\nIn the Linux kernel, the following vulnerability has been resolved: selinux: fix overlayfs mmap() and mprotect() access checks The existing SELinux security model for overlayfs is to allow access if the current task is able to access the top level file (the \u0026quot;user\u0026quot; file) and the mounter\u0026apos;s credentials are sufficient to access the lower level file (the \u0026quot;backing\u0026quot; file). Unfortunately, the current code does not properly enforce these access controls for both mmap() and mprotect() operations on overlayfs filesystems. This patch makes use of the newly created security_mmap_backing_file() LSM hook to provide the missing backing file enforcement for mmap() operations, and leverages the backing file API and new LSM blob to provide the necessary information to properly enforce the mprotect() access controls. The Linux kernel CVE team has assigned CVE-2026-46054 to this issue.(CVE-2026-46054)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: Avoid OOB font access if console rotation fails\n\nClear the font buffer if the reallocation during console rotation fails\nin fbcon_rotate_font(). The putcs implementations for the rotated buffer\nwill return early in this case. See [1] for an example.\n\nCurrently, fbcon_rotate_font() keeps the old buffer, which is too small\nfor the rotated font. Printing to the rotated console with a high-enough\ncharacter code will overflow the font buffer.\n\nv2:\n- fix typos in commit message(CVE-2026-46191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvsock: fix buffer size clamping order\n\nIn vsock_update_buffer_size(), the buffer size was being clamped to the\nmaximum first, and then to the minimum. If a user sets a minimum buffer\nsize larger than the maximum, the minimum check overrides the maximum\ncheck, inverting the constraint.\n\nThis breaks the intended socket memory boundaries by allowing the\nvsk-\u0026gt;buffer_size to grow beyond the configured vsk-\u0026gt;buffer_max_size.\n\nFix this by checking the minimum first, and then the maximum. This\nensures the buffer size never exceeds the buffer_max_size.(CVE-2026-46234)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_uart: fix UAFs and race conditions in close and init paths\n\nVulnerabilities leading to Use-After-Free (UAF) and Null Pointer\nDereference (NPD) conditions were observed in the lifecycle management\nof hci_uart.\n\nThe primary issue arises because the workqueues (init_ready and\nwrite_work) are only flushed/cancelled if the HCI_UART_PROTO_READY\nflag is set during TTY close. If a hangup occurs before setup completes,\nhci_uart_tty_close() skips the teardown of these workqueues and\nproceeds to free the `hu` struct. When the scheduled work executes\nlater, it blindly dereferences the freed `hu` struct.\n\nFurthermore, several data races and UAFs were identified in the teardown\nsequence:\n1. Calling hci_uart_flush() from hci_uart_close() without effectively\n disabling write_work causes a race condition where both can concurrently\n double-free hu-\u0026gt;tx_skb. This happens because protocol timers can\n concurrently invoke hci_uart_tx_wakeup() and requeue write_work.\n2. Calling hci_free_dev(hdev) before hu-\u0026gt;proto-\u0026gt;close(hu) causes a UAF\n when vendor specific protocol close callbacks dereference hu-\u0026gt;hdev.\n3. In the initialization error paths, failing to take the proto_lock\n write lock before clearing PROTO_READY leads to races with active\n readers. Additionally, hci_uart_tty_receive() accesses hu-\u0026gt;hdev\n outside the read lock, leading to UAFs if the initialization error\n path frees hdev concurrently.\n\nFix these synchronization and lifecycle issues by:\n1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first,\n followed immediately by a cancel_work_sync(\u0026amp;hu-\u0026gt;write_work). Clearing\n the flag locks out concurrent protocol timers from successfully invoking\n hci_uart_tx_wakeup(), effectively rendering the cancellation permanent\n and preventing the tx_skb double-free.\n2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip\n hu-\u0026gt;proto-\u0026gt;flush(). This is perfectly safe in the tty_close path\n because hu-\u0026gt;proto-\u0026gt;close() executes shortly after, which intrinsically\n purges all protocol SKB queues and tears down the state.\n3. Relocating hu-\u0026gt;proto-\u0026gt;close(hu) strictly prior to hci_free_dev(hdev)\n across all close and error paths to prevent vendor-level UAFs.\n4. Moving the hdev-\u0026gt;stat.byte_rx increment in hci_uart_tty_receive()\n inside the proto_lock read-side critical section to safely synchronize\n with device unregistration.\n5. Adding cancel_work_sync(\u0026amp;hu-\u0026gt;write_work) to hci_uart_close() to safely\n flush the workqueue before hci_uart_flush() is invoked via the HCI core.\n6. Utilizing cancel_work_sync() instead of disable_work_sync() across\n all paths to prevent permanently breaking user-space retry capabilities.(CVE-2026-46275)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: terminate the cached volume label after UTF-8 conversion\n\nntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s()\nand stores the result in sbi-\u0026gt;volume.label. The converted label is later\nexposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only\nreturns the number of bytes written and does not add a trailing NUL.\n\nIf the converted label fills the entire fixed buffer,\nntfs3_label_show() can read past the end of sbi-\u0026gt;volume.label while\nlooking for a terminator.\n\nTerminate the cached label explicitly after a successful conversion and\nclamp the exact-full case to the last byte of the buffer.(CVE-2026-53023)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nocfs2/dlm: validate qr_numregions in dlm_match_regions()\n\nPatch series \u0026quot;ocfs2/dlm: fix two bugs in dlm_match_regions()\u0026quot;.\n\nIn dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION\nnetwork message is used to drive loops over the qr_regions buffer without\nsufficient validation. This series fixes two issues:\n\n- Patch 1 adds a bounds check to reject messages where qr_numregions\n exceeds O2NM_MAX_REGIONS. The o2net layer only validates message\n byte length; it does not constrain field values, so a crafted message\n can set qr_numregions up to 255 and trigger out-of-bounds reads past\n the 1024-byte qr_regions buffer.\n\n- Patch 2 fixes an off-by-one in the local-vs-remote comparison loop,\n which uses \u0026apos;\u0026lt;=\u0026apos; instead of \u0026apos;\u0026lt;\u0026apos;, reading one entry past the valid range\n even when qr_numregions is within bounds.\n\n\nThis patch (of 2):\n\nThe qr_numregions field from a DLM_QUERY_REGION network message is used\ndirectly as loop bounds in dlm_match_regions() without checking against\nO2NM_MAX_REGIONS. Since qr_regions is sized for at most O2NM_MAX_REGIONS\n(32) entries, a crafted message with qr_numregions \u0026gt; 32 causes\nout-of-bounds reads past the qr_regions buffer.\n\nAdd a bounds check for qr_numregions before entering the loops.(CVE-2026-53043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: pci: fix possible use-after-free caused by unfinished irq_prepare_bcn_tasklet\n\nThe irq_prepare_bcn_tasklet is initialized in rtl_pci_init() and\nscheduled when RTL_IMR_BCNINT interrupt is triggered by hardware.\nBut it is never killed in rtl_pci_deinit(). When the rtlwifi card\nprobe fails or is being detached, the ieee80211_hw is deallocated.\nHowever, irq_prepare_bcn_tasklet may still be running or pending,\nleading to use-after-free when the freed ieee80211_hw is accessed\nin _rtl_pci_prepare_bcn_tasklet().\n\nSimilar to irq_tasklet, add tasklet_kill() in rtl_pci_deinit() to\nensure that irq_prepare_bcn_tasklet is properly terminated before\nthe ieee80211_hw is released.\n\nThe issue was identified through static analysis.(CVE-2026-53112)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nPCI: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-53120)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ip_gre: require CAP_NET_ADMIN in the device netns for changelink\n\nA tunnel changelink() operates on at most two netns, dev_net(dev) and\nthe tunnel link netns t-\u0026gt;net. They differ once the device is created in\nor moved to a netns other than the one the request runs in. The rtnl\nchangelink path checks CAP_NET_ADMIN only against dev_net(dev), so a\ncaller privileged there but not in t-\u0026gt;net can rewrite a tunnel that\nlives in t-\u0026gt;net.\n\nAdd rtnl_dev_link_net_capable() next to rtnl_get_net_ns_capable() in\nnet/core/rtnetlink.c. It requires CAP_NET_ADMIN in the link netns and is\nskipped when the link netns is dev_net(dev), where the rtnl path already\nchecked it. The other patches in this series use the same helper.\n\nGate ipgre_changelink() and erspan_changelink() with it, at the top of\nthe op before any attribute is parsed, because the parsers update live\ntunnel fields first. ipgre_netlink_parms() sets t-\u0026gt;collect_md before\nip_tunnel_changelink() runs.\n\nCommit 8b484efd5cb4 (\u0026quot;ip6: vti: Use ip6_tnl.net in\nvti6_siocdevprivate().\u0026quot;) added the same check on the ioctl path. This\nadds it on RTM_NEWLINK.(CVE-2026-63829)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: validate extension header length before copying to cmsg\n\nip6_datagram_recv_specific_ctl() builds IPV6_{HOPOPTS,DSTOPTS,RTHDR}\ncmsgs (and their IPV6_2292* legacy counterparts) by trusting the\non-wire hdrlen byte (ptr[1]) when computing the put_cmsg() length.\nThe length was validated only at parse time (ipv6_parse_hopopts(),\netc.). An nftables payload-write expression can rewrite hdrlen after\nparsing and before the skb reaches recvmsg; the write itself is\nin-bounds but put_cmsg() then reads up to ((hdrlen+1) \u0026lt;\u0026lt; 3) = 2040\nbytes from an 8-byte header. nftables is reachable from an\nunprivileged user namespace, so this is an unprivileged\nslab-out-of-bounds read:\n\n BUG: KASAN: slab-out-of-bounds in put_cmsg+0x3ac/0x540\n put_cmsg+0x3ac/0x540\n udpv6_recvmsg+0xca0/0x1250\n sock_recvmsg+0xdf/0x190\n ____sys_recvmsg+0x1b1/0x620\n\nAdd ipv6_get_exthdr_len() which validates that at least two bytes\nare accessible before reading the hdrlen field, then checks the\ncomputed length against skb_tail_pointer(skb), returning 0 on\nfailure. Extension headers are kept in the linear skb area by\npskb_may_pull() during input, so skb_tail_pointer() is the correct\nbound.\n\nUse ipv6_get_exthdr_len() at all non-AH call sites: the five\nstandalone cmsg blocks (HbH, 2292HbH, 2292DSTOPTS x2, 2292RTHDR)\nand the three standard cases in the extension-header walk loop\n(DSTOPTS, ROUTING, default). AH retains an inline bounds check\nbecause its length formula differs ((ptr[1]+2)\u0026lt;\u0026lt;2).\n\nThe walk loop also gets a pre-read bounds check at the top to\nvalidate ptr before any case accesses ptr[0] or ptr[1].\n\nWhen the walk loop detects a corrupted header, return from the\nfunction instead of continuing to process later socket options.(CVE-2026-63920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nip6: vti: Use ip6_tnl.net in vti6_siocdevprivate().\n\nAfter patch 1/2 in this series, vti6_update() unlinks and relinks\nthe tunnel through t-\u0026gt;net. vti6_siocdevprivate() still uses\ndev_net(dev) for the collision lookup. For a tunnel moved through\nIFLA_NET_NS_FD, dev_net(dev) is the new netns, not t-\u0026gt;net.\n\nSIOCCHGTUNNEL on a migrated tunnel then runs:\n\n net = dev_net(dev) /* migrated netns */\n t = vti6_locate(net, \u0026amp;p1, false) /* misses target in t-\u0026gt;net */\n ...\n t = netdev_priv(dev)\n vti6_update(t, \u0026amp;p1, false) /* mutates t-\u0026gt;net\u0026apos;s hash */\n\nA caller in the migrated netns picks params that match a tunnel\nin the creation netns. The lookup in dev_net(dev) finds nothing.\nvti6_update() prepends the migrated tunnel at the head of the\ncreation netns hash bucket for those params. Later lookups in\nthe creation netns resolve to the migrated device. xfrm receive\ndelivers the matched packets through a device the caller controls.\n\nReachable from an unprivileged user namespace (unshare --user\n--map-root-user --net). Cross tenant scope on container hosts.\n\nSwitch the SIOCCHGTUNNEL path on a non fallback device to use\nt-\u0026gt;net for the lookup. The lookup now matches the netns\nvti6_update() operates on.\n\nAlso add ns_capable(self-\u0026gt;net-\u0026gt;user_ns, CAP_NET_ADMIN) before\nthe lookup. The check at the top of the case is against\ndev_net(dev)-\u0026gt;user_ns, which after migration is the attacker\u0026apos;s\nnetns. A caller there can pick params absent from self-\u0026gt;net,\nthe lookup returns NULL, t becomes self, and vti6_update()\ninserts the device into the creation netns hash. The new check\nrequires CAP_NET_ADMIN in the creation netns user_ns too.\n\nSIOCADDTUNNEL and SIOCCHGTUNNEL on the fallback device keep\ndev_net(dev), which equals init_net there.(CVE-2026-63921)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: synproxy: refresh tcphdr after skb_ensure_writable\n\nsynproxy_tstamp_adjust() rewrites the TCP timestamp option in place\nand then patches the TCP checksum via inet_proto_csum_replace4() on\nthe caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and\nipv6_synproxy_hook() obtain that pointer with skb_header_pointer()\nbefore calling in, so it may either alias skb-\u0026gt;head directly or\npoint at the caller\u0026apos;s on-stack _tcph buffer.\n\nBetween obtaining the pointer and using it, the function calls\nskb_ensure_writable(skb, optend), which on a cloned or non-linear\nskb invokes pskb_expand_head() and frees the old skb-\u0026gt;head. After\nthat point the cached th is stale:\n\n caller (ipv[46]_synproxy_hook)\n th = skb_header_pointer(skb, ..., \u0026amp;_tcph)\n synproxy_tstamp_adjust(skb, protoff, th, ...)\n skb_ensure_writable(skb, optend)\n pskb_expand_head() /* kfree(old skb-\u0026gt;head) */\n ...\n inet_proto_csum_replace4(\u0026amp;th-\u0026gt;check, ...)\n /* writes into freed head, or\n into the caller\u0026apos;s stack copy\n leaving the on-wire checksum\n stale */\n\nThe option bytes are written through skb-\u0026gt;data and are fine; only\nthe checksum update goes through th and so lands in the wrong\nplace. The result is either a write into freed slab memory or a\npacket leaving with a checksum that does not match its payload.\n\nFix by re-deriving th from skb-\u0026gt;data + protoff immediately after\nskb_ensure_writable() succeeds, so the subsequent checksum update\ntargets the linear, writable header.(CVE-2026-64007)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: raw: reject IP_HDRINCL packets with ihl \u0026lt; 5\n\nraw_send_hdrinc() validates that the caller-supplied IPv4 header\nfits within the message length:\n\n iphlen = iph-\u0026gt;ihl * 4;\n err = -EINVAL;\n if (iphlen \u0026gt; length)\n goto error_free;\n\n if (iphlen \u0026gt;= sizeof(*iph)) {\n /* fix up saddr, tot_len, id, csum, transport_header */\n }\n\nIt does not, however, reject ihl \u0026lt; 5. For such a packet the\n\u0026quot;if (iphlen \u0026gt;= sizeof(*iph))\u0026quot; branch is skipped, leaving the\ncrafted iphdr untouched, but the packet is still handed to\n__ip_local_out() and onward. Downstream consumers that read\niph-\u0026gt;ihl assume a sane value: net/ipv4/ah4.c:ah_output() in\nparticular subtracts sizeof(struct iphdr) from top_iph-\u0026gt;ihl * 4\nand passes the (signed-int-negative, then cast to size_t)\nresult to memcpy(), producing an OOB access of length close to\nSIZE_MAX and a host kernel panic.\n\nAn IPv4 header with ihl \u0026lt; 5 is malformed by definition (RFC 791:\n\u0026quot;Internet Header Length is the length of the internet header in\n32 bit words ... Note that the minimum value for a correct header\nis 5.\u0026quot;). The kernel should not be willing to inject such a\npacket into its own output path.\n\nReject \u0026quot;iphlen \u0026lt; sizeof(*iph)\u0026quot; alongside the existing\n\u0026quot;iphlen \u0026gt; length\u0026quot; check. This matches the principle that locally\nconstructed packets that re-enter the IP stack must pass the same\nbasic sanity tests that a foreign packet would be subjected to.\n\nOnce this lands, the \u0026quot;if (iphlen \u0026gt;= sizeof(*iph))\u0026quot; wrapper around\nthe fixup branch becomes redundant; left in place to keep the\npatch minimal and backport-friendly. A follow-up can unwrap it.\n\nNote that commit 86f4c90a1c5c (\u0026quot;ipv4, ipv6: ensure raw socket\nmessage is big enough to hold an IP header\u0026quot;) ensures the message\nbuffer is large enough to hold an iphdr, but does not constrain\nthe self-reported iph-\u0026gt;ihl.\n\nReachability: the malformed packet source is any caller with\nCAP_NET_RAW, including an unprivileged process in a user+net\nnamespace on a kernel with CONFIG_USER_NS=y. The reproduced AH\ncrash also requires a matching xfrm AH policy on the outgoing\nroute; a container granted CAP_NET_ADMIN can install that state\nand policy in its netns. Loopback bypasses xfrm_output, so the\ntrigger uses a real netdev.\n\nReproduced on UML + KASAN: kernel-mode fault at addr 0x0 with\nmemcpy_orig at the crash site. Same shape reproduces inside a\nrootless Docker container with --cap-add NET_ADMIN on a stock\ndistro kernel.(CVE-2026-64114)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nALSA: asihpi: Fix potential OOB array access at reading cache\n\nfind_control() to retrieve a cached info accesses the array with the\ngiven index blindly, which may lead to an OOB array access.\nAdd a sanity check for avoiding it.(CVE-2026-64133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: re-lock request before returning from fuse_ref_folio()\n\nfuse_ref_folio() unlocks the request but does not re-lock it before\nreturning. fuse_chan_abort() can end the request and the async end\ncallback (eg fuse_writepage_free()) can free the args while the\nsubsequent copy chain logic after fuse_ref_folio() accesses them,\nleading to use-after-free issues.\n\nFix this by locking the request in fuse_ref_folio() before returning.(CVE-2026-64266)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: bound TCP reordering sysctl writes and MTU probe sizes\n\nReject invalid `net.ipv4.tcp_reordering` values before they reach TCP\nsocket state. The sysctl is stored as an `int` but copied into the\n`u32` `tp-\u0026gt;reordering` field for new sockets, so negative writes wrap\nto large values.\n\nWith `tcp_mtu_probing=2`, the wrapped value can overflow the\n`tcp_mtu_probe()` size calculation and drive the MTU probing path into\nan out-of-bounds read. Route `tcp_reordering` writes through\n`proc_dointvec_minmax()` and require it to be at least 1. Also require\n`tcp_max_reordering` to be at least 1 so the configured maximum cannot\nbecome negative either.\n\nWhen registering the table for a non-init network namespace, relocate\n`extra2` pointers that refer into `init_net.ipv4` so the\n`tcp_reordering` upper bound follows that namespace\u0026apos;s\n`tcp_max_reordering`.\n\nHarden `tcp_mtu_probe()` itself by computing `size_needed` as `u64`.\nThis keeps the send queue and window checks from being bypassed through\nsigned integer overflow.(CVE-2026-64422)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_key: initialize alg_key_len for IPComp states\n\npfkey_msg2xfrm_state() handles the IPComp (SADB_X_SATYPE_IPCOMP) case by\nallocating x-\u0026gt;calg and copying only the algorithm name:\n\n\tx-\u0026gt;calg = kmalloc_obj(*x-\u0026gt;calg);\n\tif (!x-\u0026gt;calg) {\n\t\terr = -ENOMEM;\n\t\tgoto out;\n\t}\n\tstrcpy(x-\u0026gt;calg-\u0026gt;alg_name, a-\u0026gt;name);\n\tx-\u0026gt;props.calgo = sa-\u0026gt;sadb_sa_encrypt;\n\nUnlike the authentication (x-\u0026gt;aalg) and encryption (x-\u0026gt;ealg) branches of\nthe same function, the compression branch never initializes\ncalg-\u0026gt;alg_key_len. IPComp carries no key and the allocation only\nreserves sizeof(struct xfrm_algo) (i.e. no room for a key), so the field\nis left containing uninitialized slab data.\n\ncalg-\u0026gt;alg_key_len is later used as a length by xfrm_algo_clone() when an\nIPComp state is cloned during XFRM_MSG_MIGRATE:\n\n\txfrm_state_migrate()\n\t xfrm_state_clone_and_setup()\n\t x-\u0026gt;calg = xfrm_algo_clone(orig-\u0026gt;calg);\n\t kmemdup(orig, xfrm_alg_len(orig));\n\nwhere xfrm_alg_len() returns sizeof(*alg) + (alg_key_len + 7) / 8. With\na non-zero garbage alg_key_len, kmemdup() reads past the end of the\n68-byte calg object. Adding an IPComp SA via PF_KEY and then migrating\nit triggers (net-next, KASAN, init_on_alloc=0):\n\n BUG: KASAN: slab-out-of-bounds in kmemdup_noprof+0x44/0x60\n Read of size 4164 at addr ff11000025a74980 by task diag2/9287\n CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1\n Call Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x10e/0x1f0\n print_report+0xf7/0x600\n kasan_report+0xe4/0x120\n kasan_check_range+0x105/0x1b0\n __asan_memcpy+0x23/0x60\n kmemdup_noprof+0x44/0x60\n xfrm_state_migrate+0x70a/0x1da0\n xfrm_migrate+0x753/0x18a0\n xfrm_do_migrate+0xb47/0xf10\n xfrm_user_rcv_msg+0x411/0xb50\n netlink_rcv_skb+0x158/0x420\n xfrm_netlink_rcv+0x71/0x90\n netlink_unicast+0x584/0x850\n netlink_sendmsg+0x8b0/0xdc0\n ____sys_sendmsg+0x9f7/0xb90\n ___sys_sendmsg+0x134/0x1d0\n __sys_sendmsg+0x16d/0x220\n do_syscall_64+0x116/0x7d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n \u0026lt;/TASK\u0026gt;\n\n Allocated by task 9287:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n pfkey_add+0x2652/0x2ea0\n pfkey_process+0x6d0/0x830\n pfkey_sendmsg+0x42c/0x850\n __sys_sendto+0x461/0x4b0\n __x64_sys_sendto+0xe0/0x1c0\n do_syscall_64+0x116/0x7d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n The buggy address belongs to the object at ff11000025a74980\n which belongs to the cache kmalloc-96 of size 96\n The buggy address is located 0 bytes inside of\n allocated 68-byte region [ff11000025a74980, ff11000025a749c4)\n\nDepending on the uninitialized value the same field can instead request\nan oversized kmemdup() allocation and make the migration clone fail.\n\nThe XFRM netlink path is not affected: verify_one_alg() rejects an\nXFRMA_ALG_COMP attribute shorter than xfrm_alg_len(), so a calg added via\nXFRM_MSG_NEWSA is always self-consistent.\n\nInitialize calg-\u0026gt;alg_key_len to 0, matching the aalg/ealg branches.(CVE-2026-64436)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/edid: fix OOB read in drm_parse_tiled_block()\n\ndrm_parse_tiled_block() casts the DisplayID block to a\nstruct displayid_tiled_block and reads the full fixed layout up to\ntile-\u0026gt;topology_id[7] without checking block-\u0026gt;num_bytes. The DisplayID\niterator only validates the declared payload length, so a crafted EDID\ncan advertise a tiled-display block (tag DATA_BLOCK_TILED_DISPLAY, or\nDATA_BLOCK_2_TILED_DISPLAY_TOPOLOGY for v2.0) with a small num_bytes at\nthe end of a DisplayID extension. The read then runs past the end of the\nexact-sized kmemdup()\u0026apos;d EDID allocation, a heap out-of-bounds read.\n\nReject blocks shorter than the spec\u0026apos;s 22-byte tiled payload before\nreading the fixed struct, as drm_parse_vesa_mso_data() already does.\n\n BUG: KASAN: slab-out-of-bounds in drm_edid_connector_update\n Read of size 2 at addr ffff888010077700 by task exploit/147\n dump_stack_lvl (lib/dump_stack.c:94 ...)\n print_report (mm/kasan/report.c:378 ...)\n kasan_report (mm/kasan/report.c:595)\n drm_edid_connector_update (drivers/gpu/drm/drm_edid.c:7581)\n bochs_connector_helper_get_modes (drivers/gpu/drm/tiny/bochs.c:574)\n drm_helper_probe_single_connector_modes (drivers/gpu/drm/drm_probe_helper.c:426)\n status_store (drivers/gpu/drm/drm_sysfs.c:219)\n ...\n vfs_write (fs/read_write.c:595 fs/read_write.c:688)\n ksys_write (fs/read_write.c:740)(CVE-2026-64546)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: qca: fix NVM tag length underflow in TLV parser\n\nIn the TLV_TYPE_NVM branch of qca_tlv_check_data() the tag loop bound is\n\u0026quot;while (idx \u0026lt; length - sizeof(struct tlv_type_nvm))\u0026quot;. \u0026quot;length\u0026quot; is a signed\nint from the firmware TLV header and sizeof(struct tlv_type_nvm) is a\nsize_t (12), so \u0026quot;length\u0026quot; is converted to size_t and any firmware-supplied\n\u0026quot;length\u0026quot; \u0026lt; 12 makes the subtraction wrap to a huge value. The loop body\nthen reads a 12-byte struct tlv_type_nvm past the end of the short\nvmalloc\u0026apos;d firmware buffer (and the EDL_TAG_ID_* handlers can write past it).\n\nRewrite the bound as \u0026quot;idx + sizeof(struct tlv_type_nvm) \u0026lt;= length\u0026quot;; both\noperands are non-negative, so it no longer underflows and a \u0026quot;length\u0026quot; too\nsmall for one record correctly skips the loop.\n\n BUG: KASAN: vmalloc-out-of-bounds in qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421)\n Read of size 2 at addr ffffc900000e5004 by task kworker/u9:0/52\n Workqueue: hci0 hci_power_on\n Call Trace:\n ...\n kasan_report (mm/kasan/report.c:595)\n qca_download_firmware.isra.0 (drivers/bluetooth/btqca.c:421 drivers/bluetooth/btqca.c:617)\n qca_uart_setup (drivers/bluetooth/btqca.c:948)\n qca_setup (drivers/bluetooth/hci_qca.c:2029)\n hci_uart_setup (drivers/bluetooth/hci_ldisc.c:438)\n hci_dev_open_sync (net/bluetooth/hci_sync.c:5227)\n hci_power_on (net/bluetooth/hci_core.c:920)\n process_one_work (kernel/workqueue.c:3322)\n worker_thread (kernel/workqueue.c:3486)\n kthread (kernel/kthread.c:436)\n ret_from_fork (arch/x86/kernel/process.c:158)\n ret_from_fork_asm (arch/x86/entry/entry_64.S:245)(CVE-2026-64573)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()\n\nceph_handle_caps() reads snap_trace_len from the wire-format\nceph_mds_caps header and uses it unconditionally to build a fake\nend pointer (snaptrace + snaptrace_len) that is later handed to\nceph_update_snap_trace() in the CEPH_CAP_OP_IMPORT case:\n\n snaptrace = h + 1;\n snaptrace_len = le32_to_cpu(h-\u0026gt;snap_trace_len);\n p = snaptrace + snaptrace_len;\n ...\n case CEPH_CAP_OP_IMPORT:\n if (snaptrace_len) {\n ...\n if (ceph_update_snap_trace(mdsc, snaptrace,\n snaptrace + snaptrace_len,\n false, \u0026amp;realm)) { ... }\n\nceph_update_snap_trace() then decodes a struct ceph_mds_snap_realm\nfrom snaptrace using ceph_decode_need(\u0026amp;p, e, sizeof(*ri), bad)\nwith the attacker-supplied fake end e == snaptrace + snaptrace_len.\nWith snaptrace_len == 0xFFFFFFFF the bound check is trivially\nsatisfied, ri = p reads sizeof(struct ceph_mds_snap_realm) past\nthe legitimate msg-\u0026gt;front buffer, and ri-\u0026gt;num_snaps /\nri-\u0026gt;num_prior_parent_snaps then drive further out-of-bounds\nreads of the encoded snap arrays.\n\nThe eleven msg_version \u0026gt;= 2 .. msg_version \u0026gt;= 12 decoder blocks\nabove the op switch each catch this OOB through their\nceph_decode_*_safe() / ceph_decode_need() helpers, but they sit\nbehind a hdr.version-gated if, so a malicious or compromised\nMDS that sets msg-\u0026gt;hdr.version = 1 reaches the IMPORT path with\nno version-gated decoder having validated snap_trace_len. The\nshape has been present since ceph_handle_caps() was introduced.\n\nValidate snap_trace_len against the message front buffer before\nconsuming it, using the canonical ceph_decode_need() / ceph_has_room()\nhelper. The helper bounds the length with subtraction (n \u0026lt;= end - p,\nguarded by end \u0026gt;= p) rather than pointer addition, so it is wrap-safe\nfor the attacker-controlled u32 length on 32-bit builds where\np + snap_trace_len could overflow the address space. This matches the\nrest of the ceph decode path (e.g. the pool_ns_len check a few lines\nbelow), and the existing goto bad cleanup already covers this exit\npath.(CVE-2026-68160)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Make the TPM character devices non-seekable\n\nThe TPM character devices expose a sequential command/response\ninterface, but their open handlers leave FMODE_PREAD and FMODE_PWRITE\nenabled.\n\nAfter a command leaves a response pending, pread(fd, buf, 16, 0x1400)\npasses 0x1400 as *off to tpm_common_read(). The transfer length is\nbounded by response_length, but the offset is used unchecked when\nforming data_buffer + *off. A sufficiently large offset therefore causes\nan out-of-bounds heap read through copy_to_user() and, if the copy\nsucceeds, an out-of-bounds zero-write through the following memset().\n\nPositional I/O does not provide coherent semantics for this interface.\nAn arbitrary pread offset cannot represent how much of a response has\nbeen consumed sequentially. The write callback always stores a command\nat the start of data_buffer, while pwrite() does not update file-\u0026gt;f_pos\nand can leave the sequential read cursor stale.\n\nCall nonseekable_open() from both open handlers. This removes\nFMODE_PREAD and FMODE_PWRITE, causing positional reads and writes to\nfail with -ESPIPE before reaching the TPM callbacks, and explicitly\nmarks the files non-seekable. Normal read() and write() continue to use\nthe existing sequential f_pos cursor, leaving the response state machine\nunchanged.\n\nTested on Linux 6.12 with KASAN and a swtpm TPM2 device:\n\n - sequential partial reads returned the complete response\n - pread() and preadv() with offset 0x1400 returned -ESPIPE\n - pwrite() and pwritev() with offset zero returned -ESPIPE\n - the pending response remained intact after the rejected operations\n - a subsequent normal command/response cycle completed normally\n - no KASAN report was produced.(CVE-2026-72135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_u32: reject invalid shift counts\n\nu32_match_it() executes rule-supplied shift operands on a 32-bit\nvalue. A malformed u32 rule can provide a shift count of 32 or more,\ntriggering an undefined shift out-of-bounds during packet evaluation.\n\nValidate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in\nu32_mt_checkentry() and reject malformed rules before they reach the\npacket path.(CVE-2026-72350)",
"id": "OESA-2026-3532",
"modified": "2026-08-30T04:15:17Z",
"published": "2026-08-30T04:15:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3532"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49289"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37991"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68190"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23102"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43373"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46054"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46191"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46234"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46275"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53023"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53043"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53112"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53120"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63829"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63920"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63921"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64007"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64114"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64133"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64266"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64422"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64436"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64546"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64573"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68160"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72135"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72350"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49289",
"CVE-2025-37991",
"CVE-2025-68190",
"CVE-2026-23102",
"CVE-2026-43373",
"CVE-2026-46054",
"CVE-2026-46191",
"CVE-2026-46234",
"CVE-2026-46275",
"CVE-2026-53023",
"CVE-2026-53043",
"CVE-2026-53112",
"CVE-2026-53120",
"CVE-2026-63829",
"CVE-2026-63920",
"CVE-2026-63921",
"CVE-2026-64007",
"CVE-2026-64114",
"CVE-2026-64133",
"CVE-2026-64266",
"CVE-2026-64422",
"CVE-2026-64436",
"CVE-2026-64546",
"CVE-2026-64573",
"CVE-2026-68160",
"CVE-2026-72135",
"CVE-2026-72350"
]
}
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.