Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2024-58069 (GCVE-0-2024-58069)
Vulnerability from cvelistv5 – Published: 2025-03-06 15:54 – Updated: 2026-08-05 11:47- CWE-787 - Out-of-bounds Write
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| Linux | Linux |
Affected:
fadfd092ee9138825d8c2a4f95719d2e2e3202b9 , < 21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4
(git)
Affected: fadfd092ee9138825d8c2a4f95719d2e2e3202b9 , < 6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c (git) Affected: fadfd092ee9138825d8c2a4f95719d2e2e3202b9 , < e5536677da803ed54a29a446515c28dce7d3d574 (git) Affected: fadfd092ee9138825d8c2a4f95719d2e2e3202b9 , < c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1 (git) Affected: fadfd092ee9138825d8c2a4f95719d2e2e3202b9 , < 9adefa7b9559d0f21034a5d5ec1b55840c9348b9 (git) Affected: fadfd092ee9138825d8c2a4f95719d2e2e3202b9 , < e5e06455760f2995b16a176033909347929d1128 (git) Affected: fadfd092ee9138825d8c2a4f95719d2e2e3202b9 , < 517aedb365f2c94e2d7e0b908ac7127df76203a1 (git) Affected: fadfd092ee9138825d8c2a4f95719d2e2e3202b9 , < 3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c (git) |
guessed | |
| Linux | Linux |
Affected:
5.2
Unaffected: 0 , < 5.2 (semver) Unaffected: 5.4.291 , ≤ 5.4.* (semver) Unaffected: 5.10.235 , ≤ 5.10.* (semver) Unaffected: 5.15.179 , ≤ 5.15.* (semver) Unaffected: 6.1.129 , ≤ 6.1.* (semver) Unaffected: 6.6.76 , ≤ 6.6.* (semver) Unaffected: 6.12.13 , ≤ 6.12.* (semver) Unaffected: 6.13.2 , ≤ 6.13.* (semver) Unaffected: 6.14 , ≤ * (original_commit_for_fix) |
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-58069",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:27:38.670709Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "CWE-787 Out-of-bounds Write",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T19:36:36.659Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-03T19:34:03.211Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/rtc/rtc-pcf85063.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "e5536677da803ed54a29a446515c28dce7d3d574",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "9adefa7b9559d0f21034a5d5ec1b55840c9348b9",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "e5e06455760f2995b16a176033909347929d1128",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "517aedb365f2c94e2d7e0b908ac7127df76203a1",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/rtc/rtc-pcf85063.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.129",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.76",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.291",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.76",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.13",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.2",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14",
"versionStartIncluding": "5.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable callback is reached by reading the local sysfs binary attribute /sys/bus/nvmem/devices/pcf85063_nvram*/nvmem (or by an in-kernel nvmem-cell consumer); no network or adjacent-network path exists to an I2C RTC driver.\nAC:L - A single open()+read() with a count under 4 bytes deterministically causes regmap_read() to store 4 bytes into the smaller kernfs-allocated buffer; there is no race, no timing window, and no condition outside the attacker\u0027s control.\nPR:L - nvmem_cfg does not set root_only, so nvmem_bin_attr_get_umode() grants mode 0644 and any unprivileged local user (or container process) can read the nvmem attribute and trigger the overflow.\nUI:N - The attacker triggers the write entirely on their own by reading a sysfs file; no victim action, mount, or file open by another user is required.\nS:U - The out-of-bounds write corrupts kernel heap/stack memory within the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The 3-byte out-of-bounds write corrupts memory adjacent to the target buffer (including stack slots holding lengths, indices and pointers in nvmem_cell_prepare_write_buffer()), and such memory corruption can be leveraged to influence subsequent reads and disclose kernel memory.\nI:H - This is a straightforward out-of-bounds write (CWE-787) past a 1-byte heap or stack buffer, corrupting adjacent kernel objects and stack frame state, which per kernel scoring practice for OOB writes constitutes a high integrity impact.\nA:H - The OOB store smashes adjacent stack data (potentially the stack canary, causing a panic) and is a KASAN-reported slab-out-of-bounds write that panics on kasan.fault=panic/panic_on_warn builds, and it is repeatable at will by any local user."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:47:31.980Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4"
},
{
"url": "https://git.kernel.org/stable/c/6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c"
},
{
"url": "https://git.kernel.org/stable/c/e5536677da803ed54a29a446515c28dce7d3d574"
},
{
"url": "https://git.kernel.org/stable/c/c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1"
},
{
"url": "https://git.kernel.org/stable/c/9adefa7b9559d0f21034a5d5ec1b55840c9348b9"
},
{
"url": "https://git.kernel.org/stable/c/e5e06455760f2995b16a176033909347929d1128"
},
{
"url": "https://git.kernel.org/stable/c/517aedb365f2c94e2d7e0b908ac7127df76203a1"
},
{
"url": "https://git.kernel.org/stable/c/3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c"
}
],
"title": "rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-58069",
"datePublished": "2025-03-06T15:54:09.480Z",
"dateReserved": "2025-03-06T15:52:09.181Z",
"dateUpdated": "2026-08-05T11:47:31.980Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2024-58069",
"date": "2026-09-20",
"epss": "0.00229",
"percentile": "0.13987"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/rtc/rtc-pcf85063.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "e5536677da803ed54a29a446515c28dce7d3d574",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "9adefa7b9559d0f21034a5d5ec1b55840c9348b9",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "e5e06455760f2995b16a176033909347929d1128",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "517aedb365f2c94e2d7e0b908ac7127df76203a1",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/rtc/rtc-pcf85063.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.129",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.76",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "18F68456-FFB3-4E0E-A802-F3E41C67B10E",
"versionEndExcluding": "5.4.291",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "545121FA-DE31-4154-9446-C2000FB4104D",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C708062C-4E1B-465F-AE6D-C09C46400875",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2DA5009C-C9B9-4A1D-9B96-78427E8F232C",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A6D70701-9CB6-4222-A957-00A419878993",
"versionEndExcluding": "6.6.76",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2897389C-A8C3-4D69-90F2-E701B3D66373",
"versionEndExcluding": "6.12.13",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6D4116B1-1BFD-4F23-BA84-169CC05FC5A3",
"versionEndExcluding": "6.13.2",
"versionStartIncluding": "6.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: pcf85063: se corrige una posible escritura OOB en la lectura NVMEM PCF85063 La interfaz nvmem admite tama\u00f1os de b\u00fafer variables, mientras que la interfaz regmap opera con almacenamiento de tama\u00f1o fijo. Si un cliente nvmem usa un tama\u00f1o de b\u00fafer menor a 4 bytes, regmap_read escribir\u00e1 fuera de los l\u00edmites ya que espera que el b\u00fafer apunte a una int sin signo. Corrija esto usando una int sin signo intermedia para contener el valor."
}
],
"id": "CVE-2024-58069",
"lastModified": "2026-06-17T08:14:33.710",
"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"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-58069",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:27:38.670709Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-03-06T16:15:53.373",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/517aedb365f2c94e2d7e0b908ac7127df76203a1"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/9adefa7b9559d0f21034a5d5ec1b55840c9348b9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e5536677da803ed54a29a446515c28dce7d3d574"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e5e06455760f2995b16a176033909347929d1128"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-787"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-787"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Moderate",
"current_release_date": "2026-06-29T23:03:43+00:00",
"cve": "CVE-2024-58069",
"id": "CVE-2024-58069",
"initial_release_date": "2024-01-01T00:00:00+00:00",
"product_status:fixed": "614",
"product_status:known_affected": "22",
"product_status:known_not_affected": "90",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "kernel: rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-58069.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"providerMetadata": {
"dateUpdated": "2025-11-03T19:34:03.211Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
}
],
"title": "CVE Program Container"
},
{
"metrics": [
{
"cvssV3_1": {
"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"
}
},
{
"other": {
"content": {
"id": "CVE-2024-58069",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:27:38.670709Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-787",
"description": "CWE-787 Out-of-bounds Write",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-10-01T16:57:29.106Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/rtc/rtc-pcf85063.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "e5536677da803ed54a29a446515c28dce7d3d574",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "9adefa7b9559d0f21034a5d5ec1b55840c9348b9",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "e5e06455760f2995b16a176033909347929d1128",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "517aedb365f2c94e2d7e0b908ac7127df76203a1",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/rtc/rtc-pcf85063.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.129",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.76",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.4.291",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.76",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.13",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.13.2",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.14",
"versionStartIncluding": "5.2",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The vulnerable callback is reached by reading the local sysfs binary attribute /sys/bus/nvmem/devices/pcf85063_nvram*/nvmem (or by an in-kernel nvmem-cell consumer); no network or adjacent-network path exists to an I2C RTC driver.\nAC:L - A single open()+read() with a count under 4 bytes deterministically causes regmap_read() to store 4 bytes into the smaller kernfs-allocated buffer; there is no race, no timing window, and no condition outside the attacker\u0027s control.\nPR:L - nvmem_cfg does not set root_only, so nvmem_bin_attr_get_umode() grants mode 0644 and any unprivileged local user (or container process) can read the nvmem attribute and trigger the overflow.\nUI:N - The attacker triggers the write entirely on their own by reading a sysfs file; no victim action, mount, or file open by another user is required.\nS:U - The out-of-bounds write corrupts kernel heap/stack memory within the same kernel security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - The 3-byte out-of-bounds write corrupts memory adjacent to the target buffer (including stack slots holding lengths, indices and pointers in nvmem_cell_prepare_write_buffer()), and such memory corruption can be leveraged to influence subsequent reads and disclose kernel memory.\nI:H - This is a straightforward out-of-bounds write (CWE-787) past a 1-byte heap or stack buffer, corrupting adjacent kernel objects and stack frame state, which per kernel scoring practice for OOB writes constitutes a high integrity impact.\nA:H - The OOB store smashes adjacent stack data (potentially the stack canary, causing a panic) and is a KASAN-reported slab-out-of-bounds write that panics on kasan.fault=panic/panic_on_warn builds, and it is repeatable at will by any local user."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T11:47:31.980Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4"
},
{
"url": "https://git.kernel.org/stable/c/6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c"
},
{
"url": "https://git.kernel.org/stable/c/e5536677da803ed54a29a446515c28dce7d3d574"
},
{
"url": "https://git.kernel.org/stable/c/c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1"
},
{
"url": "https://git.kernel.org/stable/c/9adefa7b9559d0f21034a5d5ec1b55840c9348b9"
},
{
"url": "https://git.kernel.org/stable/c/e5e06455760f2995b16a176033909347929d1128"
},
{
"url": "https://git.kernel.org/stable/c/517aedb365f2c94e2d7e0b908ac7127df76203a1"
},
{
"url": "https://git.kernel.org/stable/c/3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c"
}
],
"title": "rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2024-58069",
"datePublished": "2025-03-06T15:54:09.480Z",
"dateReserved": "2025-03-06T15:52:09.181Z",
"dateUpdated": "2026-08-05T11:47:31.980Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
CERTFR-2025-AVI-0625
Vulnerability from certfr_avis - Published: 2025-07-25 - Updated: 2025-07-25
De multiples vulnérabilités ont été découvertes dans Ubuntu Ubuntu. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, un déni de service à distance et une atteinte à la confidentialité 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 20.04 ESM",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 24.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 25.04",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
},
{
"description": "Ubuntu 22.04 LTS",
"product": {
"name": "Ubuntu",
"vendor": {
"name": "Ubuntu",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2024-26686",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26686"
},
{
"name": "CVE-2023-52572",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52572"
},
{
"name": "CVE-2024-26739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26739"
},
{
"name": "CVE-2023-52757",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52757"
},
{
"name": "CVE-2024-35866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35866"
},
{
"name": "CVE-2024-35867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35867"
},
{
"name": "CVE-2024-35943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35943"
},
{
"name": "CVE-2024-35790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35790"
},
{
"name": "CVE-2024-36945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36945"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2024-36908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36908"
},
{
"name": "CVE-2024-27402",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27402"
},
{
"name": "CVE-2024-42230",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42230"
},
{
"name": "CVE-2022-48893",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48893"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2024-46812",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46812"
},
{
"name": "CVE-2024-46821",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46821"
},
{
"name": "CVE-2024-46751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46751"
},
{
"name": "CVE-2024-46753",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46753"
},
{
"name": "CVE-2024-46774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46774"
},
{
"name": "CVE-2024-46787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46787"
},
{
"name": "CVE-2024-46816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46816"
},
{
"name": "CVE-2024-49960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49960"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2024-50272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50272"
},
{
"name": "CVE-2024-50280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50280"
},
{
"name": "CVE-2024-49989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49989"
},
{
"name": "CVE-2024-50125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50125"
},
{
"name": "CVE-2024-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53051"
},
{
"name": "CVE-2024-53144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53144"
},
{
"name": "CVE-2024-8805",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8805"
},
{
"name": "CVE-2024-56551",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56551"
},
{
"name": "CVE-2024-53168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53168"
},
{
"name": "CVE-2024-56664",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56664"
},
{
"name": "CVE-2024-50258",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50258"
},
{
"name": "CVE-2024-53203",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53203"
},
{
"name": "CVE-2024-56608",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56608"
},
{
"name": "CVE-2024-53128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53128"
},
{
"name": "CVE-2024-49887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49887"
},
{
"name": "CVE-2024-56751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56751"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-57994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57994"
},
{
"name": "CVE-2025-21705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21705"
},
{
"name": "CVE-2025-21715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21715"
},
{
"name": "CVE-2025-21716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21716"
},
{
"name": "CVE-2025-21719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21719"
},
{
"name": "CVE-2025-21724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21724"
},
{
"name": "CVE-2025-21725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21725"
},
{
"name": "CVE-2025-21728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21728"
},
{
"name": "CVE-2025-21733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21733"
},
{
"name": "CVE-2025-21753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21753"
},
{
"name": "CVE-2025-21754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21754"
},
{
"name": "CVE-2025-21799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21799"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2022-49063",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49063"
},
{
"name": "CVE-2022-49535",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49535"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2024-54458",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54458"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-57981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57981"
},
{
"name": "CVE-2024-57986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57986"
},
{
"name": "CVE-2024-57993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57993"
},
{
"name": "CVE-2024-57997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57997"
},
{
"name": "CVE-2024-57998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57998"
},
{
"name": "CVE-2024-58001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58001"
},
{
"name": "CVE-2024-58007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58007"
},
{
"name": "CVE-2024-58010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58010"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2024-58016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58016"
},
{
"name": "CVE-2024-58017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58017"
},
{
"name": "CVE-2024-58034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58034"
},
{
"name": "CVE-2024-58051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58051"
},
{
"name": "CVE-2024-58052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58052"
},
{
"name": "CVE-2024-58054",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58054"
},
{
"name": "CVE-2024-58055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58055"
},
{
"name": "CVE-2024-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58056"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2024-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58061"
},
{
"name": "CVE-2024-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58063"
},
{
"name": "CVE-2024-58068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58068"
},
{
"name": "CVE-2024-58069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58069"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2024-58076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58076"
},
{
"name": "CVE-2024-58077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58077"
},
{
"name": "CVE-2024-58080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58080"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2024-58085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58085"
},
{
"name": "CVE-2025-21707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21707"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-21711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21711"
},
{
"name": "CVE-2025-21722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21722"
},
{
"name": "CVE-2025-21726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21726"
},
{
"name": "CVE-2025-21727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21727"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2025-21734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21734"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-21736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21736"
},
{
"name": "CVE-2025-21738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21738"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2025-21745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21745"
},
{
"name": "CVE-2025-21748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21748"
},
{
"name": "CVE-2025-21749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21749"
},
{
"name": "CVE-2025-21750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21750"
},
{
"name": "CVE-2025-21804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21804"
},
{
"name": "CVE-2025-21806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21806"
},
{
"name": "CVE-2025-21811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21811"
},
{
"name": "CVE-2025-21812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21812"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21820"
},
{
"name": "CVE-2025-21826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21826"
},
{
"name": "CVE-2025-21829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21829"
},
{
"name": "CVE-2025-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21830"
},
{
"name": "CVE-2025-21832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21832"
},
{
"name": "CVE-2024-57974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57974"
},
{
"name": "CVE-2024-57990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57990"
},
{
"name": "CVE-2024-57999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57999"
},
{
"name": "CVE-2024-58002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58002"
},
{
"name": "CVE-2024-58005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58005"
},
{
"name": "CVE-2024-58006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58006"
},
{
"name": "CVE-2024-58019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58019"
},
{
"name": "CVE-2024-58057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58057"
},
{
"name": "CVE-2024-58078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58078"
},
{
"name": "CVE-2024-58079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58079"
},
{
"name": "CVE-2025-21714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21714"
},
{
"name": "CVE-2025-21723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21723"
},
{
"name": "CVE-2025-21732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21732"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2025-21741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21741"
},
{
"name": "CVE-2025-21742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21742"
},
{
"name": "CVE-2025-21743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21743"
},
{
"name": "CVE-2025-21810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21810"
},
{
"name": "CVE-2025-21815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21815"
},
{
"name": "CVE-2025-21825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21825"
},
{
"name": "CVE-2025-21828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21828"
},
{
"name": "CVE-2025-21839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21839"
},
{
"name": "CVE-2025-21721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21721"
},
{
"name": "CVE-2025-21941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21941"
},
{
"name": "CVE-2025-21956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21956"
},
{
"name": "CVE-2025-21957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21957"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2025-21962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21962"
},
{
"name": "CVE-2025-21963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21963"
},
{
"name": "CVE-2025-21964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21964"
},
{
"name": "CVE-2025-21968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21968"
},
{
"name": "CVE-2025-21970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21970"
},
{
"name": "CVE-2025-21975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21975"
},
{
"name": "CVE-2025-21981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21981"
},
{
"name": "CVE-2025-21991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21991"
},
{
"name": "CVE-2025-21992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21992"
},
{
"name": "CVE-2025-21994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21994"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-21999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21999"
},
{
"name": "CVE-2025-22004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22004"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2025-22008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22008"
},
{
"name": "CVE-2025-22010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22010"
},
{
"name": "CVE-2025-22014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22014"
},
{
"name": "CVE-2025-2312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2312"
},
{
"name": "CVE-2023-53034",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-53034"
},
{
"name": "CVE-2024-46742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46742"
},
{
"name": "CVE-2025-21853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21853"
},
{
"name": "CVE-2025-22025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22025"
},
{
"name": "CVE-2025-22027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22027"
},
{
"name": "CVE-2025-22035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22035"
},
{
"name": "CVE-2025-22044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22044"
},
{
"name": "CVE-2025-22045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22045"
},
{
"name": "CVE-2025-22050",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22050"
},
{
"name": "CVE-2025-22054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22054"
},
{
"name": "CVE-2025-22055",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22055"
},
{
"name": "CVE-2025-22056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22056"
},
{
"name": "CVE-2025-22060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22060"
},
{
"name": "CVE-2025-22063",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22063"
},
{
"name": "CVE-2025-22066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22066"
},
{
"name": "CVE-2025-22071",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22071"
},
{
"name": "CVE-2025-22073",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22073"
},
{
"name": "CVE-2025-22075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22075"
},
{
"name": "CVE-2025-22079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22079"
},
{
"name": "CVE-2025-22081",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22081"
},
{
"name": "CVE-2025-22086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22086"
},
{
"name": "CVE-2025-22089",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22089"
},
{
"name": "CVE-2025-22097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22097"
},
{
"name": "CVE-2025-23136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23136"
},
{
"name": "CVE-2025-23138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23138"
},
{
"name": "CVE-2025-37785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37785"
},
{
"name": "CVE-2025-37838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37838"
},
{
"name": "CVE-2025-38152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38152"
},
{
"name": "CVE-2025-38575",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38575"
},
{
"name": "CVE-2025-38637",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38637"
},
{
"name": "CVE-2025-39728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39728"
},
{
"name": "CVE-2025-39735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-39735"
},
{
"name": "CVE-2024-58081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58081"
},
{
"name": "CVE-2022-49728",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49728"
},
{
"name": "CVE-2024-58018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58018"
},
{
"name": "CVE-2024-58070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58070"
},
{
"name": "CVE-2024-58093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58093"
},
{
"name": "CVE-2025-21808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21808"
},
{
"name": "CVE-2025-22018",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22018"
},
{
"name": "CVE-2025-22020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22020"
},
{
"name": "CVE-2025-22062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22062"
},
{
"name": "CVE-2025-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23145"
},
{
"name": "CVE-2025-37798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37798"
},
{
"name": "CVE-2025-37749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37749"
},
{
"name": "CVE-2025-22021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22021"
},
{
"name": "CVE-2025-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23140"
},
{
"name": "CVE-2025-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23142"
},
{
"name": "CVE-2025-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23144"
},
{
"name": "CVE-2025-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23146"
},
{
"name": "CVE-2025-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23147"
},
{
"name": "CVE-2025-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23148"
},
{
"name": "CVE-2025-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23150"
},
{
"name": "CVE-2025-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23151"
},
{
"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-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23158"
},
{
"name": "CVE-2025-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23159"
},
{
"name": "CVE-2025-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23161"
},
{
"name": "CVE-2025-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23163"
},
{
"name": "CVE-2025-37738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37738"
},
{
"name": "CVE-2025-37739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37739"
},
{
"name": "CVE-2025-37740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37740"
},
{
"name": "CVE-2025-37741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37741"
},
{
"name": "CVE-2025-37742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37742"
},
{
"name": "CVE-2025-37756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37756"
},
{
"name": "CVE-2025-37757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37757"
},
{
"name": "CVE-2025-37758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37758"
},
{
"name": "CVE-2025-37765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37765"
},
{
"name": "CVE-2025-37766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37766"
},
{
"name": "CVE-2025-37767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37767"
},
{
"name": "CVE-2025-37768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37768"
},
{
"name": "CVE-2025-37770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37770"
},
{
"name": "CVE-2025-37771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37771"
},
{
"name": "CVE-2025-37773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37773"
},
{
"name": "CVE-2025-37780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37780"
},
{
"name": "CVE-2025-37781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37781"
},
{
"name": "CVE-2025-37787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37787"
},
{
"name": "CVE-2025-37788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37788"
},
{
"name": "CVE-2025-37789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37789"
},
{
"name": "CVE-2025-37790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37790"
},
{
"name": "CVE-2025-37792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37792"
},
{
"name": "CVE-2025-37794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37794"
},
{
"name": "CVE-2025-37796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37796"
},
{
"name": "CVE-2025-37797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37797"
},
{
"name": "CVE-2025-37803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37803"
},
{
"name": "CVE-2025-37805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37805"
},
{
"name": "CVE-2025-37808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37808"
},
{
"name": "CVE-2025-37810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37810"
},
{
"name": "CVE-2025-37811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37811"
},
{
"name": "CVE-2025-37812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37812"
},
{
"name": "CVE-2025-37817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37817"
},
{
"name": "CVE-2025-37823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37823"
},
{
"name": "CVE-2025-37824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37824"
},
{
"name": "CVE-2025-37829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37829"
},
{
"name": "CVE-2025-37830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37830"
},
{
"name": "CVE-2025-37836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37836"
},
{
"name": "CVE-2025-37839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37839"
},
{
"name": "CVE-2025-37840",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37840"
},
{
"name": "CVE-2025-37841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37841"
},
{
"name": "CVE-2025-37844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37844"
},
{
"name": "CVE-2025-37850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37850"
},
{
"name": "CVE-2025-37851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37851"
},
{
"name": "CVE-2025-37857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37857"
},
{
"name": "CVE-2025-37858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37858"
},
{
"name": "CVE-2025-37859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37859"
},
{
"name": "CVE-2025-37862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37862"
},
{
"name": "CVE-2025-37867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37867"
},
{
"name": "CVE-2025-37871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37871"
},
{
"name": "CVE-2025-37875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37875"
},
{
"name": "CVE-2025-37881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37881"
},
{
"name": "CVE-2025-37883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37883"
},
{
"name": "CVE-2025-37885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37885"
},
{
"name": "CVE-2025-37889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37889"
},
{
"name": "CVE-2025-37892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37892"
},
{
"name": "CVE-2025-37937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37937"
},
{
"name": "CVE-2025-37940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37940"
},
{
"name": "CVE-2025-37982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37982"
},
{
"name": "CVE-2025-37983",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37983"
},
{
"name": "CVE-2025-37985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37985"
},
{
"name": "CVE-2025-37989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37989"
},
{
"name": "CVE-2025-37819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37819"
},
{
"name": "CVE-2025-37890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37890"
},
{
"name": "CVE-2025-37897",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37897"
},
{
"name": "CVE-2025-37901",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37901"
},
{
"name": "CVE-2025-37903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37903"
},
{
"name": "CVE-2025-37905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37905"
},
{
"name": "CVE-2025-37909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37909"
},
{
"name": "CVE-2025-37911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37911"
},
{
"name": "CVE-2025-37912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37912"
},
{
"name": "CVE-2025-37913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37913"
},
{
"name": "CVE-2025-37914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37914"
},
{
"name": "CVE-2025-37915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37915"
},
{
"name": "CVE-2025-37917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37917"
},
{
"name": "CVE-2025-37921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37921"
},
{
"name": "CVE-2025-37923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37923"
},
{
"name": "CVE-2025-37924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37924"
},
{
"name": "CVE-2025-37927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37927"
},
{
"name": "CVE-2025-37928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37928"
},
{
"name": "CVE-2025-37929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37929"
},
{
"name": "CVE-2025-37930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37930"
},
{
"name": "CVE-2025-37932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37932"
},
{
"name": "CVE-2025-37936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37936"
},
{
"name": "CVE-2025-37949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37949"
},
{
"name": "CVE-2025-37964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37964"
},
{
"name": "CVE-2025-37967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37967"
},
{
"name": "CVE-2025-37969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37969"
},
{
"name": "CVE-2025-37970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37970"
},
{
"name": "CVE-2025-37990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37990"
},
{
"name": "CVE-2025-37991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37991"
},
{
"name": "CVE-2025-37750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37750"
},
{
"name": "CVE-2025-37974",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37974"
},
{
"name": "CVE-2022-49168",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49168"
},
{
"name": "CVE-2025-37891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37891"
},
{
"name": "CVE-2025-37900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37900"
},
{
"name": "CVE-2025-37918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37918"
},
{
"name": "CVE-2025-37931",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37931"
},
{
"name": "CVE-2025-37933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37933"
},
{
"name": "CVE-2025-37998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37998"
},
{
"name": "CVE-2022-49636",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49636"
},
{
"name": "CVE-2025-37997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37997"
},
{
"name": "CVE-2025-38000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38000"
},
{
"name": "CVE-2025-38001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38001"
},
{
"name": "CVE-2024-57982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57982"
},
{
"name": "CVE-2024-58053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58053"
},
{
"name": "CVE-2025-21720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21720"
},
{
"name": "CVE-2025-37934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37934"
},
{
"name": "CVE-2025-37946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37946"
},
{
"name": "CVE-2025-37992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37992"
},
{
"name": "CVE-2025-37994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37994"
},
{
"name": "CVE-2025-37995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37995"
},
{
"name": "CVE-2025-38005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38005"
},
{
"name": "CVE-2025-38009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38009"
},
{
"name": "CVE-2025-38023",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38023"
},
{
"name": "CVE-2025-38024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38024"
},
{
"name": "CVE-2022-21546",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21546"
},
{
"name": "CVE-2025-38177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38177"
},
{
"name": "CVE-2024-57953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57953"
},
{
"name": "CVE-2024-57975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57975"
},
{
"name": "CVE-2024-57984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57984"
},
{
"name": "CVE-2024-58003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58003"
},
{
"name": "CVE-2024-58082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58082"
},
{
"name": "CVE-2025-21710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21710"
},
{
"name": "CVE-2025-21798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21798"
},
{
"name": "CVE-2025-21801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21801"
},
{
"name": "CVE-2025-21809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21809"
},
{
"name": "CVE-2025-21816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21816"
},
{
"name": "CVE-2025-37894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37894"
},
{
"name": "CVE-2025-37895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37895"
},
{
"name": "CVE-2025-37896",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37896"
},
{
"name": "CVE-2025-37898",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37898"
},
{
"name": "CVE-2025-37899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37899"
},
{
"name": "CVE-2025-37904",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37904"
},
{
"name": "CVE-2025-37906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37906"
},
{
"name": "CVE-2025-37907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37907"
},
{
"name": "CVE-2025-37908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37908"
},
{
"name": "CVE-2025-37910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37910"
},
{
"name": "CVE-2025-37916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37916"
},
{
"name": "CVE-2025-37919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37919"
},
{
"name": "CVE-2025-37920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37920"
},
{
"name": "CVE-2025-37922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37922"
},
{
"name": "CVE-2025-37926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37926"
},
{
"name": "CVE-2025-37935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37935"
},
{
"name": "CVE-2025-38094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38094"
},
{
"name": "CVE-2025-38216",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38216"
}
],
"initial_release_date": "2025-07-25T00:00:00",
"last_revision_date": "2025-07-25T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0625",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-07-25T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Ex\u00e9cution de code arbitraire \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 Ubuntu Ubuntu. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, un d\u00e9ni de service \u00e0 distance et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2025-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7651-5",
"url": "https://ubuntu.com/security/notices/USN-7651-5"
},
{
"published_at": "2025-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7651-6",
"url": "https://ubuntu.com/security/notices/USN-7651-6"
},
{
"published_at": "2025-07-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7654-3",
"url": "https://ubuntu.com/security/notices/USN-7654-3"
},
{
"published_at": "2025-07-21",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7611-4",
"url": "https://ubuntu.com/security/notices/USN-7611-4"
},
{
"published_at": "2025-07-24",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7665-2",
"url": "https://ubuntu.com/security/notices/USN-7665-2"
},
{
"published_at": "2025-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7651-3",
"url": "https://ubuntu.com/security/notices/USN-7651-3"
},
{
"published_at": "2025-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7649-2",
"url": "https://ubuntu.com/security/notices/USN-7649-2"
},
{
"published_at": "2025-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7665-1",
"url": "https://ubuntu.com/security/notices/USN-7665-1"
},
{
"published_at": "2025-07-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7654-2",
"url": "https://ubuntu.com/security/notices/USN-7654-2"
},
{
"published_at": "2025-07-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7655-1",
"url": "https://ubuntu.com/security/notices/USN-7655-1"
},
{
"published_at": "2025-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7654-4",
"url": "https://ubuntu.com/security/notices/USN-7654-4"
},
{
"published_at": "2025-07-18",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7651-2",
"url": "https://ubuntu.com/security/notices/USN-7651-2"
},
{
"published_at": "2025-07-22",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7651-4",
"url": "https://ubuntu.com/security/notices/USN-7651-4"
}
]
}
CERTFR-2025-AVI-0758
Vulnerability from certfr_avis - Published: 2025-09-05 - Updated: 2025-09-05
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 à distance, un déni de service à distance et une atteinte à la confidentialité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
{
"$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 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-2023-52477",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52477"
},
{
"name": "CVE-2024-26686",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26686"
},
{
"name": "CVE-2024-27074",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27074"
},
{
"name": "CVE-2024-26739",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26739"
},
{
"name": "CVE-2021-47345",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-47345"
},
{
"name": "CVE-2024-35866",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35866"
},
{
"name": "CVE-2024-35867",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35867"
},
{
"name": "CVE-2024-35943",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35943"
},
{
"name": "CVE-2024-35790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35790"
},
{
"name": "CVE-2024-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38540"
},
{
"name": "CVE-2024-38541",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38541"
},
{
"name": "CVE-2024-36908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-36908"
},
{
"name": "CVE-2024-27402",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27402"
},
{
"name": "CVE-2022-48893",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48893"
},
{
"name": "CVE-2024-42322",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-42322"
},
{
"name": "CVE-2024-46751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46751"
},
{
"name": "CVE-2024-46774",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46774"
},
{
"name": "CVE-2024-46787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46787"
},
{
"name": "CVE-2024-46816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46816"
},
{
"name": "CVE-2024-47685",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47685"
},
{
"name": "CVE-2024-49960",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49960"
},
{
"name": "CVE-2024-50047",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50047"
},
{
"name": "CVE-2024-50073",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50073"
},
{
"name": "CVE-2024-50272",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50272"
},
{
"name": "CVE-2024-50280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50280"
},
{
"name": "CVE-2024-27407",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27407"
},
{
"name": "CVE-2024-49989",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49989"
},
{
"name": "CVE-2024-50125",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50125"
},
{
"name": "CVE-2024-53051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53051"
},
{
"name": "CVE-2024-50202",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50202"
},
{
"name": "CVE-2024-53130",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53130"
},
{
"name": "CVE-2024-53131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53131"
},
{
"name": "CVE-2024-50051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50051"
},
{
"name": "CVE-2024-50258",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50258"
},
{
"name": "CVE-2024-53203",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53203"
},
{
"name": "CVE-2024-53128",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53128"
},
{
"name": "CVE-2024-49887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49887"
},
{
"name": "CVE-2024-56751",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56751"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-57994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57994"
},
{
"name": "CVE-2025-21705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21705"
},
{
"name": "CVE-2025-21715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21715"
},
{
"name": "CVE-2025-21716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21716"
},
{
"name": "CVE-2025-21719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21719"
},
{
"name": "CVE-2025-21724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21724"
},
{
"name": "CVE-2025-21725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21725"
},
{
"name": "CVE-2025-21728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21728"
},
{
"name": "CVE-2025-21733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21733"
},
{
"name": "CVE-2025-21753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21753"
},
{
"name": "CVE-2025-21754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21754"
},
{
"name": "CVE-2025-21767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21767"
},
{
"name": "CVE-2025-21790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21790"
},
{
"name": "CVE-2025-21795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21795"
},
{
"name": "CVE-2025-21799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21799"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2022-49063",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49063"
},
{
"name": "CVE-2022-49535",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49535"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2025-21772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21772"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2024-54458",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54458"
},
{
"name": "CVE-2024-57834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57834"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-57981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57981"
},
{
"name": "CVE-2024-57986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57986"
},
{
"name": "CVE-2024-57993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57993"
},
{
"name": "CVE-2024-57997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57997"
},
{
"name": "CVE-2024-57998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57998"
},
{
"name": "CVE-2024-58001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58001"
},
{
"name": "CVE-2024-58007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58007"
},
{
"name": "CVE-2024-58010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58010"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2024-58016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58016"
},
{
"name": "CVE-2024-58017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58017"
},
{
"name": "CVE-2024-58020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58020"
},
{
"name": "CVE-2024-58034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58034"
},
{
"name": "CVE-2024-58051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58051"
},
{
"name": "CVE-2024-58052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58052"
},
{
"name": "CVE-2024-58054",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58054"
},
{
"name": "CVE-2024-58055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58055"
},
{
"name": "CVE-2024-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58056"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2024-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58061"
},
{
"name": "CVE-2024-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58063"
},
{
"name": "CVE-2024-58068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58068"
},
{
"name": "CVE-2024-58069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58069"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2024-58076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58076"
},
{
"name": "CVE-2024-58077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58077"
},
{
"name": "CVE-2024-58080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58080"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2024-58085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58085"
},
{
"name": "CVE-2024-58086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58086"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2025-21706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21706"
},
{
"name": "CVE-2025-21707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21707"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-21711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21711"
},
{
"name": "CVE-2025-21722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21722"
},
{
"name": "CVE-2025-21726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21726"
},
{
"name": "CVE-2025-21727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21727"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2025-21734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21734"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-21736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21736"
},
{
"name": "CVE-2025-21738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21738"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2025-21745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21745"
},
{
"name": "CVE-2025-21748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21748"
},
{
"name": "CVE-2025-21749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21749"
},
{
"name": "CVE-2025-21750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21750"
},
{
"name": "CVE-2025-21758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21758"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2025-21761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21761"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2025-21764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21764"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2025-21766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21766"
},
{
"name": "CVE-2025-21775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21775"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21779"
},
{
"name": "CVE-2025-21781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21781"
},
{
"name": "CVE-2025-21782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21782"
},
{
"name": "CVE-2025-21787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21787"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2025-21792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21792"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-21804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21804"
},
{
"name": "CVE-2025-21806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21806"
},
{
"name": "CVE-2025-21811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21811"
},
{
"name": "CVE-2025-21812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21812"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21820"
},
{
"name": "CVE-2025-21821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21821"
},
{
"name": "CVE-2025-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21823"
},
{
"name": "CVE-2025-21826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21826"
},
{
"name": "CVE-2025-21829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21829"
},
{
"name": "CVE-2025-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21830"
},
{
"name": "CVE-2025-21832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21832"
},
{
"name": "CVE-2025-21835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21835"
},
{
"name": "CVE-2024-52559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52559"
},
{
"name": "CVE-2024-57974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57974"
},
{
"name": "CVE-2024-57990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57990"
},
{
"name": "CVE-2024-57999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57999"
},
{
"name": "CVE-2024-58002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58002"
},
{
"name": "CVE-2024-58005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58005"
},
{
"name": "CVE-2024-58006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58006"
},
{
"name": "CVE-2024-58019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58019"
},
{
"name": "CVE-2024-58057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58057"
},
{
"name": "CVE-2024-58078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58078"
},
{
"name": "CVE-2024-58079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58079"
},
{
"name": "CVE-2025-21714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21714"
},
{
"name": "CVE-2025-21723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21723"
},
{
"name": "CVE-2025-21732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21732"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2025-21741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21741"
},
{
"name": "CVE-2025-21742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21742"
},
{
"name": "CVE-2025-21743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21743"
},
{
"name": "CVE-2025-21759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21759"
},
{
"name": "CVE-2025-21773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21773"
},
{
"name": "CVE-2025-21784",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21784"
},
{
"name": "CVE-2025-21793",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21793"
},
{
"name": "CVE-2025-21810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21810"
},
{
"name": "CVE-2025-21815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21815"
},
{
"name": "CVE-2025-21825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21825"
},
{
"name": "CVE-2025-21828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21828"
},
{
"name": "CVE-2025-21838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21838"
},
{
"name": "CVE-2025-21839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21839"
},
{
"name": "CVE-2025-21844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21844"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2025-21847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21847"
},
{
"name": "CVE-2025-21848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21848"
},
{
"name": "CVE-2025-21855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21855"
},
{
"name": "CVE-2025-21856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21856"
},
{
"name": "CVE-2025-21857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21857"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2025-21859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21859"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-21862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21862"
},
{
"name": "CVE-2025-21864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21864"
},
{
"name": "CVE-2025-21866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21866"
},
{
"name": "CVE-2025-21869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21869"
},
{
"name": "CVE-2025-21870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21870"
},
{
"name": "CVE-2025-21871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21871"
},
{
"name": "CVE-2024-57977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57977"
},
{
"name": "CVE-2025-21712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21712"
},
{
"name": "CVE-2025-21721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21721"
},
{
"name": "CVE-2025-21867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21867"
},
{
"name": "CVE-2025-21887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21887"
},
{
"name": "CVE-2024-46742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46742"
},
{
"name": "CVE-2025-21853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21853"
},
{
"name": "CVE-2025-22027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22027"
},
{
"name": "CVE-2025-37838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37838"
},
{
"name": "CVE-2024-58081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58081"
},
{
"name": "CVE-2024-58018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58018"
},
{
"name": "CVE-2024-58070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58070"
},
{
"name": "CVE-2024-58088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58088"
},
{
"name": "CVE-2024-58093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58093"
},
{
"name": "CVE-2025-21768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21768"
},
{
"name": "CVE-2025-21808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21808"
},
{
"name": "CVE-2025-21836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21836"
},
{
"name": "CVE-2025-21854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21854"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2025-22062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22062"
},
{
"name": "CVE-2025-23145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23145"
},
{
"name": "CVE-2025-37798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37798"
},
{
"name": "CVE-2025-37749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37749"
},
{
"name": "CVE-2025-23140",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23140"
},
{
"name": "CVE-2025-23142",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23142"
},
{
"name": "CVE-2025-23144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23144"
},
{
"name": "CVE-2025-23146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23146"
},
{
"name": "CVE-2025-23147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23147"
},
{
"name": "CVE-2025-23148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23148"
},
{
"name": "CVE-2025-23150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23150"
},
{
"name": "CVE-2025-23151",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23151"
},
{
"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-23158",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23158"
},
{
"name": "CVE-2025-23159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23159"
},
{
"name": "CVE-2025-23161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23161"
},
{
"name": "CVE-2025-23163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23163"
},
{
"name": "CVE-2025-37738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37738"
},
{
"name": "CVE-2025-37739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37739"
},
{
"name": "CVE-2025-37740",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37740"
},
{
"name": "CVE-2025-37741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37741"
},
{
"name": "CVE-2025-37742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37742"
},
{
"name": "CVE-2025-37752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37752"
},
{
"name": "CVE-2025-37756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37756"
},
{
"name": "CVE-2025-37757",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37757"
},
{
"name": "CVE-2025-37758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37758"
},
{
"name": "CVE-2025-37765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37765"
},
{
"name": "CVE-2025-37766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37766"
},
{
"name": "CVE-2025-37767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37767"
},
{
"name": "CVE-2025-37768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37768"
},
{
"name": "CVE-2025-37770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37770"
},
{
"name": "CVE-2025-37771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37771"
},
{
"name": "CVE-2025-37773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37773"
},
{
"name": "CVE-2025-37780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37780"
},
{
"name": "CVE-2025-37781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37781"
},
{
"name": "CVE-2025-37787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37787"
},
{
"name": "CVE-2025-37788",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37788"
},
{
"name": "CVE-2025-37789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37789"
},
{
"name": "CVE-2025-37790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37790"
},
{
"name": "CVE-2025-37792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37792"
},
{
"name": "CVE-2025-37794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37794"
},
{
"name": "CVE-2025-37796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37796"
},
{
"name": "CVE-2025-37797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37797"
},
{
"name": "CVE-2025-37803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37803"
},
{
"name": "CVE-2025-37805",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37805"
},
{
"name": "CVE-2025-37808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37808"
},
{
"name": "CVE-2025-37810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37810"
},
{
"name": "CVE-2025-37811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37811"
},
{
"name": "CVE-2025-37812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37812"
},
{
"name": "CVE-2025-37817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37817"
},
{
"name": "CVE-2025-37823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37823"
},
{
"name": "CVE-2025-37824",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37824"
},
{
"name": "CVE-2025-37829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37829"
},
{
"name": "CVE-2025-37830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37830"
},
{
"name": "CVE-2025-37836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37836"
},
{
"name": "CVE-2025-37839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37839"
},
{
"name": "CVE-2025-37840",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37840"
},
{
"name": "CVE-2025-37841",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37841"
},
{
"name": "CVE-2025-37844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37844"
},
{
"name": "CVE-2025-37850",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37850"
},
{
"name": "CVE-2025-37851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37851"
},
{
"name": "CVE-2025-37857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37857"
},
{
"name": "CVE-2025-37858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37858"
},
{
"name": "CVE-2025-37859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37859"
},
{
"name": "CVE-2025-37862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37862"
},
{
"name": "CVE-2025-37867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37867"
},
{
"name": "CVE-2025-37871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37871"
},
{
"name": "CVE-2025-37875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37875"
},
{
"name": "CVE-2025-37881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37881"
},
{
"name": "CVE-2025-37883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37883"
},
{
"name": "CVE-2025-37885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37885"
},
{
"name": "CVE-2025-37892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37892"
},
{
"name": "CVE-2025-37940",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37940"
},
{
"name": "CVE-2025-37982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37982"
},
{
"name": "CVE-2025-37983",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37983"
},
{
"name": "CVE-2025-37985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37985"
},
{
"name": "CVE-2025-37989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37989"
},
{
"name": "CVE-2025-37819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37819"
},
{
"name": "CVE-2025-37890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37890"
},
{
"name": "CVE-2025-37905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37905"
},
{
"name": "CVE-2025-37909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37909"
},
{
"name": "CVE-2025-37911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37911"
},
{
"name": "CVE-2025-37912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37912"
},
{
"name": "CVE-2025-37913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37913"
},
{
"name": "CVE-2025-37914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37914"
},
{
"name": "CVE-2025-37915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37915"
},
{
"name": "CVE-2025-37923",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37923"
},
{
"name": "CVE-2025-37927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37927"
},
{
"name": "CVE-2025-37930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37930"
},
{
"name": "CVE-2025-37932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37932"
},
{
"name": "CVE-2025-37949",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37949"
},
{
"name": "CVE-2025-37964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37964"
},
{
"name": "CVE-2025-37967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37967"
},
{
"name": "CVE-2025-37969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37969"
},
{
"name": "CVE-2025-37970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37970"
},
{
"name": "CVE-2025-37990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37990"
},
{
"name": "CVE-2025-37991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37991"
},
{
"name": "CVE-2025-37750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37750"
},
{
"name": "CVE-2025-37974",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37974"
},
{
"name": "CVE-2022-49168",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49168"
},
{
"name": "CVE-2025-21868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21868"
},
{
"name": "CVE-2025-37998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37998"
},
{
"name": "CVE-2025-37997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37997"
},
{
"name": "CVE-2025-38000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38000"
},
{
"name": "CVE-2025-38001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38001"
},
{
"name": "CVE-2024-57982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57982"
},
{
"name": "CVE-2024-58053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58053"
},
{
"name": "CVE-2025-21720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21720"
},
{
"name": "CVE-2025-37992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37992"
},
{
"name": "CVE-2025-37994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37994"
},
{
"name": "CVE-2025-37995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37995"
},
{
"name": "CVE-2025-38003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38003"
},
{
"name": "CVE-2025-38004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38004"
},
{
"name": "CVE-2025-38005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38005"
},
{
"name": "CVE-2025-38009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38009"
},
{
"name": "CVE-2025-38023",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38023"
},
{
"name": "CVE-2025-38024",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38024"
},
{
"name": "CVE-2025-38031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38031"
},
{
"name": "CVE-2025-38043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38043"
},
{
"name": "CVE-2025-38044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38044"
},
{
"name": "CVE-2025-38065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38065"
},
{
"name": "CVE-2025-38068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38068"
},
{
"name": "CVE-2025-38072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38072"
},
{
"name": "CVE-2025-38077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38077"
},
{
"name": "CVE-2025-38078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38078"
},
{
"name": "CVE-2025-38079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38079"
},
{
"name": "CVE-2025-38083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38083"
},
{
"name": "CVE-2022-21546",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21546"
},
{
"name": "CVE-2025-38061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38061"
},
{
"name": "CVE-2025-38177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38177"
},
{
"name": "CVE-2024-57953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57953"
},
{
"name": "CVE-2024-57975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57975"
},
{
"name": "CVE-2024-57984",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57984"
},
{
"name": "CVE-2024-58003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58003"
},
{
"name": "CVE-2024-58082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58082"
},
{
"name": "CVE-2025-21710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21710"
},
{
"name": "CVE-2025-21798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21798"
},
{
"name": "CVE-2025-21801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21801"
},
{
"name": "CVE-2025-21809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21809"
},
{
"name": "CVE-2025-21816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21816"
},
{
"name": "CVE-2025-38094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38094"
},
{
"name": "CVE-2025-38052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38052"
},
{
"name": "CVE-2025-38034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38034"
},
{
"name": "CVE-2025-38035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38035"
},
{
"name": "CVE-2025-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38037"
},
{
"name": "CVE-2025-38048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38048"
},
{
"name": "CVE-2025-38051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38051"
},
{
"name": "CVE-2025-38058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38058"
},
{
"name": "CVE-2025-38066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38066"
},
{
"name": "CVE-2025-38075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38075"
},
{
"name": "CVE-2025-38174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38174"
},
{
"name": "CVE-2025-38350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38350"
},
{
"name": "CVE-2024-54456",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54456"
},
{
"name": "CVE-2025-21746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21746"
},
{
"name": "CVE-2025-21783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21783"
},
{
"name": "CVE-2025-21786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21786"
}
],
"initial_release_date": "2025-09-05T00:00:00",
"last_revision_date": "2025-09-05T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0758",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-09-05T00:00:00.000000"
}
],
"risks": [
{
"description": "D\u00e9ni de service \u00e0 distance"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
}
],
"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 \u00e0 distance, un d\u00e9ni de service \u00e0 distance et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans le noyau Linux d\u0027Ubuntu",
"vendor_advisories": [
{
"published_at": "2025-09-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7726-4",
"url": "https://ubuntu.com/security/notices/USN-7726-4"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7725-1",
"url": "https://ubuntu.com/security/notices/USN-7725-1"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7726-2",
"url": "https://ubuntu.com/security/notices/USN-7726-2"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7703-4",
"url": "https://ubuntu.com/security/notices/USN-7703-4"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7726-3",
"url": "https://ubuntu.com/security/notices/USN-7726-3"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7724-1",
"url": "https://ubuntu.com/security/notices/USN-7724-1"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7727-2",
"url": "https://ubuntu.com/security/notices/USN-7727-2"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7725-2",
"url": "https://ubuntu.com/security/notices/USN-7725-2"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7704-5",
"url": "https://ubuntu.com/security/notices/USN-7704-5"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7727-1",
"url": "https://ubuntu.com/security/notices/USN-7727-1"
},
{
"published_at": "2025-09-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7727-3",
"url": "https://ubuntu.com/security/notices/USN-7727-3"
},
{
"published_at": "2025-08-28",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7726-1",
"url": "https://ubuntu.com/security/notices/USN-7726-1"
},
{
"published_at": "2025-09-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7712-2",
"url": "https://ubuntu.com/security/notices/USN-7712-2"
},
{
"published_at": "2025-09-02",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7725-3",
"url": "https://ubuntu.com/security/notices/USN-7725-3"
},
{
"published_at": "2025-09-03",
"title": "Bulletin de s\u00e9curit\u00e9 Ubuntu USN-7737-1",
"url": "https://ubuntu.com/security/notices/USN-7737-1"
}
]
}
CERTFR-2025-AVI-0969
Vulnerability from certfr_avis - Published: 2025-11-06 - Updated: 2025-11-06
De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer un problème de sécurité non spécifié par l'éditeur.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| VMware | Tanzu Kubernetes Runtime | GenAI sur Tanzu Platform pour Cloud Foundry versions antérieures à 10.2.5 | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry versions antérieures à 6.0.20+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Noble) versions antérieures à 1.90.x | ||
| VMware | Tanzu Kubernetes Runtime | NodeJS Buildpack versions antérieures à 1.8.58 | ||
| VMware | Tanzu Kubernetes Runtime | Python Buildpack versions antérieures à 1.8.63 | ||
| VMware | Tanzu Kubernetes Runtime | VMware Tanzu pour MySQL sur Tanzu Platform versions antérieures à 10.1.0 | ||
| VMware | Tanzu Kubernetes Runtime | API Gateway pour VMware Tanzu Platform versions antérieures à 2.4.0 | ||
| VMware | Tanzu Kubernetes Runtime | PHP Buildpack versions antérieures à 4.6.49 | ||
| VMware | Tanzu Kubernetes Runtime | Single Sign-On pour VMware Tanzu Platform versions antérieures à 1.16.14 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy FIPS) versions antérieures à 1.915.x | ||
| VMware | Tanzu Application Service | CredHub Service Broker versions antérieures à 1.6.6 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy FIPS) versions antérieures à 1.943.x | ||
| VMware | Tanzu Kubernetes Runtime | Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions antérieures à 10.2.4+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry Windows versions antérieures à 6.0.20+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy) versions antérieures à 1.915.x | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry Windows versions antérieures à 10.2.3+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Single Sign-On pour VMware Tanzu Application Service versions antérieures à 1.16.13 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy) versions antérieures à 1.943.x | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry isolation segment versions antérieures à 6.0.20+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Noble) versions antérieures à 1.77.x | ||
| VMware | Services Suite | Platform Automation Toolkit versions antérieures à 5.3.2 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy Azure Light) versions antérieures à 1.906.x | ||
| VMware | Tanzu Kubernetes Runtime | Spring Cloud Data Flow pour VMware Tanzu versions antérieures à 1.14.9 | ||
| VMware | Tanzu Kubernetes Runtime | App Autoscaler CLI Plugin pour VMware Tanzu Platform versions antérieures à 250.5.9 | ||
| VMware | Tanzu Kubernetes Runtime | Spring Cloud Services pour VMware Tanzu versions antérieures à 3.3.10 | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry versions antérieures à 10.2.3+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Concourse pour VMware Tanzu versions antérieures à 7.14.1+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Platform pour Cloud Foundry isolation segment versions antérieures à 10.2.3+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Platform Services pour VMware Tanzu Platform versions antérieures à 10.3.0 | ||
| VMware | Tanzu Kubernetes Runtime | Ruby Buildpack versions antérieures à 1.10.46 | ||
| VMware | Tanzu Kubernetes Runtime | Elastic Application Runtime pour VMware Tanzu Platform versions antérieures à 6.0.21+LTS-T | ||
| VMware | Tanzu Kubernetes Runtime | Telemetry pour VMware Tanzu Platform versions antérieures à 2.3.0 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Noble) versions antérieures à 1.103.x | ||
| VMware | Tanzu Kubernetes Runtime | Tanzu Hub versions antérieures à 10.3.0 | ||
| VMware | Tanzu Kubernetes Runtime | Stemcells (Ubuntu Jammy) versions antérieures à 1.906.x |
| Title | Publication Time | Tags | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "GenAI sur Tanzu Platform pour Cloud Foundry versions ant\u00e9rieures \u00e0 10.2.5",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry versions ant\u00e9rieures \u00e0 6.0.20+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Noble) versions ant\u00e9rieures \u00e0 1.90.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "NodeJS Buildpack versions ant\u00e9rieures \u00e0 1.8.58",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Python Buildpack versions ant\u00e9rieures \u00e0 1.8.63",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "VMware Tanzu pour MySQL sur Tanzu Platform versions ant\u00e9rieures \u00e0 10.1.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "API Gateway pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 2.4.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "PHP Buildpack versions ant\u00e9rieures \u00e0 4.6.49",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Single Sign-On pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 1.16.14",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy FIPS) versions ant\u00e9rieures \u00e0 1.915.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "CredHub Service Broker versions ant\u00e9rieures \u00e0 1.6.6",
"product": {
"name": "Tanzu Application Service",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy FIPS) versions ant\u00e9rieures \u00e0 1.943.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Elastic Application Runtime Windows add-on pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.2.4+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry Windows versions ant\u00e9rieures \u00e0 6.0.20+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy) versions ant\u00e9rieures \u00e0 1.915.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry Windows versions ant\u00e9rieures \u00e0 10.2.3+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Single Sign-On pour VMware Tanzu Application Service versions ant\u00e9rieures \u00e0 1.16.13",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy) versions ant\u00e9rieures \u00e0 1.943.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry isolation segment versions ant\u00e9rieures \u00e0 6.0.20+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Noble) versions ant\u00e9rieures \u00e0 1.77.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Platform Automation Toolkit versions ant\u00e9rieures \u00e0 5.3.2",
"product": {
"name": "Services Suite",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy Azure Light) versions ant\u00e9rieures \u00e0 1.906.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Spring Cloud Data Flow pour VMware Tanzu versions ant\u00e9rieures \u00e0 1.14.9",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "App Autoscaler CLI Plugin pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 250.5.9",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Spring Cloud Services pour VMware Tanzu versions ant\u00e9rieures \u00e0 3.3.10",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry versions ant\u00e9rieures \u00e0 10.2.3+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Concourse pour VMware Tanzu versions ant\u00e9rieures \u00e0 7.14.1+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Platform pour Cloud Foundry isolation segment versions ant\u00e9rieures \u00e0 10.2.3+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Platform Services pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 10.3.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Ruby Buildpack versions ant\u00e9rieures \u00e0 1.10.46",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Elastic Application Runtime pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 6.0.21+LTS-T",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Telemetry pour VMware Tanzu Platform versions ant\u00e9rieures \u00e0 2.3.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Noble) versions ant\u00e9rieures \u00e0 1.103.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Tanzu Hub versions ant\u00e9rieures \u00e0 10.3.0",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
},
{
"description": "Stemcells (Ubuntu Jammy) versions ant\u00e9rieures \u00e0 1.906.x",
"product": {
"name": "Tanzu Kubernetes Runtime",
"vendor": {
"name": "VMware",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2006-3082",
"url": "https://www.cve.org/CVERecord?id=CVE-2006-3082"
},
{
"name": "CVE-2013-2064",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-2064"
},
{
"name": "CVE-2014-8140",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-8140"
},
{
"name": "CVE-2014-8139",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-8139"
},
{
"name": "CVE-2014-8141",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-8141"
},
{
"name": "CVE-2015-4779",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4779"
},
{
"name": "CVE-2015-4780",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4780"
},
{
"name": "CVE-2015-4787",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4787"
},
{
"name": "CVE-2015-4790",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4790"
},
{
"name": "CVE-2015-4778",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4778"
},
{
"name": "CVE-2015-4782",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4782"
},
{
"name": "CVE-2015-4789",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4789"
},
{
"name": "CVE-2015-4764",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4764"
},
{
"name": "CVE-2015-4783",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4783"
},
{
"name": "CVE-2015-2583",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2583"
},
{
"name": "CVE-2015-4781",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4781"
},
{
"name": "CVE-2015-4776",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4776"
},
{
"name": "CVE-2015-4786",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4786"
},
{
"name": "CVE-2015-2656",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2656"
},
{
"name": "CVE-2015-4788",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4788"
},
{
"name": "CVE-2015-4785",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4785"
},
{
"name": "CVE-2015-4754",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4754"
},
{
"name": "CVE-2015-4775",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4775"
},
{
"name": "CVE-2015-4777",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4777"
},
{
"name": "CVE-2015-2640",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2640"
},
{
"name": "CVE-2015-4774",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4774"
},
{
"name": "CVE-2015-2626",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2626"
},
{
"name": "CVE-2015-2624",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2624"
},
{
"name": "CVE-2015-4784",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-4784"
},
{
"name": "CVE-2015-2654",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-2654"
},
{
"name": "CVE-2017-7244",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7244"
},
{
"name": "CVE-2017-6004",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6004"
},
{
"name": "CVE-2017-7186",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7186"
},
{
"name": "CVE-2017-7246",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7246"
},
{
"name": "CVE-2018-10919",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-10919"
},
{
"name": "CVE-2020-2754",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2754"
},
{
"name": "CVE-2020-2756",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2756"
},
{
"name": "CVE-2020-2805",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2805"
},
{
"name": "CVE-2020-2830",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2830"
},
{
"name": "CVE-2020-2757",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2757"
},
{
"name": "CVE-2020-2800",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2800"
},
{
"name": "CVE-2020-2803",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2803"
},
{
"name": "CVE-2020-2755",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2755"
},
{
"name": "CVE-2020-2781",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2781"
},
{
"name": "CVE-2020-2773",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2773"
},
{
"name": "CVE-2019-13136",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-13136"
},
{
"name": "CVE-2020-14579",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14579"
},
{
"name": "CVE-2020-14577",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14577"
},
{
"name": "CVE-2020-14578",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14578"
},
{
"name": "CVE-2020-14621",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14621"
},
{
"name": "CVE-2020-14583",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14583"
},
{
"name": "CVE-2020-14581",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14581"
},
{
"name": "CVE-2020-14664",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14664"
},
{
"name": "CVE-2020-14593",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14593"
},
{
"name": "CVE-2020-14556",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14556"
},
{
"name": "CVE-2019-19906",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-19906"
},
{
"name": "CVE-2019-12900",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-12900"
},
{
"name": "CVE-2020-14796",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14796"
},
{
"name": "CVE-2020-14803",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14803"
},
{
"name": "CVE-2020-14792",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14792"
},
{
"name": "CVE-2020-14779",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14779"
},
{
"name": "CVE-2020-14798",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14798"
},
{
"name": "CVE-2020-14797",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14797"
},
{
"name": "CVE-2020-14781",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14781"
},
{
"name": "CVE-2020-14782",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14782"
},
{
"name": "CVE-2020-14155",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14155"
},
{
"name": "CVE-2019-20838",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-20838"
},
{
"name": "CVE-2019-25013",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-25013"
},
{
"name": "CVE-2020-28196",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-28196"
},
{
"name": "CVE-2021-2161",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2161"
},
{
"name": "CVE-2021-2163",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2163"
},
{
"name": "CVE-2021-25217",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-25217"
},
{
"name": "CVE-2019-13232",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-13232"
},
{
"name": "CVE-2021-0561",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-0561"
},
{
"name": "CVE-2021-29921",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-29921"
},
{
"name": "CVE-2014-3577",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-3577"
},
{
"name": "CVE-2012-6153",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-6153"
},
{
"name": "CVE-2015-5262",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-5262"
},
{
"name": "CVE-2020-8908",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-8908"
},
{
"name": "CVE-2021-2388",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2388"
},
{
"name": "CVE-2021-2341",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2341"
},
{
"name": "CVE-2021-2369",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-2369"
},
{
"name": "CVE-2020-10029",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10029"
},
{
"name": "CVE-2013-0340",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-0340"
},
{
"name": "CVE-2019-18276",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-18276"
},
{
"name": "CVE-2021-3520",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3520"
},
{
"name": "CVE-2021-3421",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3421"
},
{
"name": "CVE-2021-3326",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3326"
},
{
"name": "CVE-2019-2708",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-2708"
},
{
"name": "CVE-2020-27618",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27618"
},
{
"name": "CVE-2021-36222",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36222"
},
{
"name": "CVE-2021-35603",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35603"
},
{
"name": "CVE-2021-35560",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35560"
},
{
"name": "CVE-2021-35586",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35586"
},
{
"name": "CVE-2021-35559",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35559"
},
{
"name": "CVE-2021-35567",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35567"
},
{
"name": "CVE-2021-35578",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35578"
},
{
"name": "CVE-2021-35550",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35550"
},
{
"name": "CVE-2021-35561",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35561"
},
{
"name": "CVE-2021-35565",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35565"
},
{
"name": "CVE-2021-35588",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35588"
},
{
"name": "CVE-2021-35564",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35564"
},
{
"name": "CVE-2021-35556",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35556"
},
{
"name": "CVE-2021-43527",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43527"
},
{
"name": "CVE-2021-44717",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44717"
},
{
"name": "CVE-2021-36221",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36221"
},
{
"name": "CVE-2021-29923",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-29923"
},
{
"name": "CVE-2021-34558",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-34558"
},
{
"name": "CVE-2021-36976",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36976"
},
{
"name": "CVE-2022-21349",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21349"
},
{
"name": "CVE-2022-21291",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21291"
},
{
"name": "CVE-2022-21340",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21340"
},
{
"name": "CVE-2022-21282",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21282"
},
{
"name": "CVE-2022-21271",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21271"
},
{
"name": "CVE-2022-21341",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21341"
},
{
"name": "CVE-2022-21365",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21365"
},
{
"name": "CVE-2022-21305",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21305"
},
{
"name": "CVE-2022-21366",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21366"
},
{
"name": "CVE-2022-21360",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21360"
},
{
"name": "CVE-2022-21296",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21296"
},
{
"name": "CVE-2022-21293",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21293"
},
{
"name": "CVE-2022-21248",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21248"
},
{
"name": "CVE-2022-21299",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21299"
},
{
"name": "CVE-2022-21294",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21294"
},
{
"name": "CVE-2022-21283",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21283"
},
{
"name": "CVE-2021-3737",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3737"
},
{
"name": "CVE-2021-44716",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44716"
},
{
"name": "CVE-2021-3733",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3733"
},
{
"name": "CVE-2021-41772",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41772"
},
{
"name": "CVE-2021-41771",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-41771"
},
{
"name": "CVE-2022-37967",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-37967"
},
{
"name": "CVE-2022-45061",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45061"
},
{
"name": "CVE-2022-40674",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40674"
},
{
"name": "CVE-2022-3602",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3602"
},
{
"name": "CVE-2022-37434",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-37434"
},
{
"name": "CVE-2022-2309",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2309"
},
{
"name": "CVE-2022-43680",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43680"
},
{
"name": "CVE-2022-29824",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29824"
},
{
"name": "CVE-2022-23308",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23308"
},
{
"name": "CVE-2022-35737",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-35737"
},
{
"name": "CVE-2022-40303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40303"
},
{
"name": "CVE-2022-40304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40304"
},
{
"name": "CVE-2022-21476",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21476"
},
{
"name": "CVE-2022-42898",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42898"
},
{
"name": "CVE-2022-30633",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30633"
},
{
"name": "CVE-2022-1705",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1705"
},
{
"name": "CVE-2022-27664",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27664"
},
{
"name": "CVE-2022-28131",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28131"
},
{
"name": "CVE-2022-32148",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32148"
},
{
"name": "CVE-2022-32189",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32189"
},
{
"name": "CVE-2022-1962",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1962"
},
{
"name": "CVE-2022-30635",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30635"
},
{
"name": "CVE-2022-30631",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30631"
},
{
"name": "CVE-2022-30632",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30632"
},
{
"name": "CVE-2022-30630",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30630"
},
{
"name": "CVE-2022-0696",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0696"
},
{
"name": "CVE-2022-3786",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3786"
},
{
"name": "CVE-2022-0714",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0714"
},
{
"name": "CVE-2022-29526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29526"
},
{
"name": "CVE-2022-34903",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34903"
},
{
"name": "CVE-2022-3515",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3515"
},
{
"name": "CVE-2022-32205",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32205"
},
{
"name": "CVE-2022-32206",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32206"
},
{
"name": "CVE-2018-25032",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-25032"
},
{
"name": "CVE-2022-3996",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3996"
},
{
"name": "CVE-2022-22942",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22942"
},
{
"name": "CVE-2022-23773",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23773"
},
{
"name": "CVE-2022-0391",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0391"
},
{
"name": "CVE-2022-23772",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23772"
},
{
"name": "CVE-2022-23806",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23806"
},
{
"name": "CVE-2022-0158",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0158"
},
{
"name": "CVE-2022-0156",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0156"
},
{
"name": "CVE-2018-11813",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11813"
},
{
"name": "CVE-2018-1000075",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000075"
},
{
"name": "CVE-2018-18384",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-18384"
},
{
"name": "CVE-2019-8325",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8325"
},
{
"name": "CVE-2019-8322",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8322"
},
{
"name": "CVE-2018-1000073",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000073"
},
{
"name": "CVE-2018-1000079",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000079"
},
{
"name": "CVE-2019-8324",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8324"
},
{
"name": "CVE-2018-1000076",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000076"
},
{
"name": "CVE-2018-1000074",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000074"
},
{
"name": "CVE-2018-1000078",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000078"
},
{
"name": "CVE-2018-1000077",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000077"
},
{
"name": "CVE-2019-1010238",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-1010238"
},
{
"name": "CVE-2019-8323",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8323"
},
{
"name": "CVE-2022-0351",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0351"
},
{
"name": "CVE-2022-0319",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0319"
},
{
"name": "CVE-2022-21434",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21434"
},
{
"name": "CVE-2022-21443",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21443"
},
{
"name": "CVE-2022-21496",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21496"
},
{
"name": "CVE-2022-21426",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21426"
},
{
"name": "CVE-2021-20266",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20266"
},
{
"name": "CVE-2022-24921",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24921"
},
{
"name": "CVE-2022-1434",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1434"
},
{
"name": "CVE-2022-1292",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1292"
},
{
"name": "CVE-2022-1343",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1343"
},
{
"name": "CVE-2022-1473",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1473"
},
{
"name": "CVE-2022-0530",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0530"
},
{
"name": "CVE-2021-3521",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3521"
},
{
"name": "CVE-2021-39293",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-39293"
},
{
"name": "CVE-2022-27774",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27774"
},
{
"name": "CVE-2022-27775",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27775"
},
{
"name": "CVE-2022-22576",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22576"
},
{
"name": "CVE-2022-27776",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27776"
},
{
"name": "CVE-2022-2068",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2068"
},
{
"name": "CVE-2022-2097",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2097"
},
{
"name": "CVE-2022-24407",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24407"
},
{
"name": "CVE-2017-7500",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7500"
},
{
"name": "CVE-2021-33574",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33574"
},
{
"name": "CVE-2017-11164",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-11164"
},
{
"name": "CVE-2021-37750",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37750"
},
{
"name": "CVE-2022-21541",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21541"
},
{
"name": "CVE-2022-34169",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34169"
},
{
"name": "CVE-2022-21540",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21540"
},
{
"name": "CVE-2022-24070",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24070"
},
{
"name": "CVE-2021-28544",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-28544"
},
{
"name": "CVE-2021-31566",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31566"
},
{
"name": "CVE-2021-23177",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23177"
},
{
"name": "CVE-2021-3999",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3999"
},
{
"name": "CVE-2022-23218",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23218"
},
{
"name": "CVE-2022-23219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-23219"
},
{
"name": "CVE-2022-28327",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28327"
},
{
"name": "CVE-2022-24675",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24675"
},
{
"name": "CVE-2022-27782",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27782"
},
{
"name": "CVE-2022-38476",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-38476"
},
{
"name": "CVE-2022-26488",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26488"
},
{
"name": "CVE-2022-32208",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32208"
},
{
"name": "CVE-2022-27781",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27781"
},
{
"name": "CVE-2022-32207",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32207"
},
{
"name": "CVE-2022-3358",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3358"
},
{
"name": "CVE-2022-1271",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1271"
},
{
"name": "CVE-2021-4189",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4189"
},
{
"name": "CVE-2012-5783",
"url": "https://www.cve.org/CVERecord?id=CVE-2012-5783"
},
{
"name": "CVE-2022-1587",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1587"
},
{
"name": "CVE-2022-21626",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21626"
},
{
"name": "CVE-2022-21619",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21619"
},
{
"name": "CVE-2022-21628",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21628"
},
{
"name": "CVE-2022-21624",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-21624"
},
{
"name": "CVE-2022-1725",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1725"
},
{
"name": "CVE-2022-29458",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29458"
},
{
"name": "CVE-2022-28739",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28739"
},
{
"name": "CVE-2022-1897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1897"
},
{
"name": "CVE-2022-1420",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1420"
},
{
"name": "CVE-2021-39537",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-39537"
},
{
"name": "CVE-2022-1674",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1674"
},
{
"name": "CVE-2022-1622",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1622"
},
{
"name": "CVE-2022-37454",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-37454"
},
{
"name": "CVE-2023-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21830"
},
{
"name": "CVE-2023-21843",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21843"
},
{
"name": "CVE-2020-10735",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10735"
},
{
"name": "CVE-2022-32221",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32221"
},
{
"name": "CVE-2022-42916",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42916"
},
{
"name": "CVE-2022-35252",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-35252"
},
{
"name": "CVE-2022-42915",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42915"
},
{
"name": "CVE-2022-43551",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43551"
},
{
"name": "CVE-2022-43552",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43552"
},
{
"name": "CVE-2022-40897",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
},
{
"name": "CVE-2022-4304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4304"
},
{
"name": "CVE-2022-4203",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4203"
},
{
"name": "CVE-2023-0286",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0286"
},
{
"name": "CVE-2023-0401",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0401"
},
{
"name": "CVE-2023-0215",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0215"
},
{
"name": "CVE-2023-0217",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0217"
},
{
"name": "CVE-2023-0216",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0216"
},
{
"name": "CVE-2022-4450",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4450"
},
{
"name": "CVE-2023-0767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0767"
},
{
"name": "CVE-2015-20107",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-20107"
},
{
"name": "CVE-2022-1586",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1586"
},
{
"name": "CVE-2022-25147",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25147"
},
{
"name": "CVE-2022-45873",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-45873"
},
{
"name": "CVE-2022-4415",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4415"
},
{
"name": "CVE-2022-3821",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3821"
},
{
"name": "CVE-2023-23915",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23915"
},
{
"name": "CVE-2023-23914",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23914"
},
{
"name": "CVE-2023-23916",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23916"
},
{
"name": "CVE-2022-1304",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1304"
},
{
"name": "CVE-2023-24329",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24329"
},
{
"name": "CVE-2023-23931",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-23931"
},
{
"name": "CVE-2022-41717",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41717"
},
{
"name": "CVE-2023-0464",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0464"
},
{
"name": "CVE-2022-2879",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2879"
},
{
"name": "CVE-2022-41715",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41715"
},
{
"name": "CVE-2022-2880",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2880"
},
{
"name": "CVE-2022-41716",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41716"
},
{
"name": "CVE-2023-0466",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0466"
},
{
"name": "CVE-2023-0465",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0465"
},
{
"name": "CVE-2023-0614",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0614"
},
{
"name": "CVE-2022-32743",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32743"
},
{
"name": "CVE-2023-0922",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0922"
},
{
"name": "CVE-2022-30629",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30629"
},
{
"name": "CVE-2022-41723",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41723"
},
{
"name": "CVE-2022-41722",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41722"
},
{
"name": "CVE-2022-30580",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30580"
},
{
"name": "CVE-2022-41720",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41720"
},
{
"name": "CVE-2022-41725",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41725"
},
{
"name": "CVE-2022-41724",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41724"
},
{
"name": "CVE-2021-46828",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46828"
},
{
"name": "CVE-2021-33621",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33621"
},
{
"name": "CVE-2023-21937",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21937"
},
{
"name": "CVE-2023-21939",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21939"
},
{
"name": "CVE-2023-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21967"
},
{
"name": "CVE-2023-21930",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21930"
},
{
"name": "CVE-2023-21968",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21968"
},
{
"name": "CVE-2023-21938",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21938"
},
{
"name": "CVE-2023-21954",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-21954"
},
{
"name": "CVE-2023-24532",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24532"
},
{
"name": "CVE-2023-24537",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24537"
},
{
"name": "CVE-2023-29469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29469"
},
{
"name": "CVE-2023-28484",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28484"
},
{
"name": "CVE-2023-20873",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-20873"
},
{
"name": "CVE-2023-20883",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-20883"
},
{
"name": "CVE-2023-2650",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2650"
},
{
"name": "CVE-2023-27535",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27535"
},
{
"name": "CVE-2022-25858",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25858"
},
{
"name": "CVE-2022-30634",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30634"
},
{
"name": "CVE-2022-36227",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36227"
},
{
"name": "CVE-2023-27533",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27533"
},
{
"name": "CVE-2023-27538",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27538"
},
{
"name": "CVE-2023-27534",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27534"
},
{
"name": "CVE-2023-27536",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27536"
},
{
"name": "CVE-2022-27780",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-27780"
},
{
"name": "CVE-2022-29804",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29804"
},
{
"name": "CVE-2023-27537",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27537"
},
{
"name": "CVE-2020-1752",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-1752"
},
{
"name": "CVE-2021-35942",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35942"
},
{
"name": "CVE-2021-38604",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38604"
},
{
"name": "CVE-2020-29562",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-29562"
},
{
"name": "CVE-2021-27645",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-27645"
},
{
"name": "CVE-2023-24536",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24536"
},
{
"name": "CVE-2023-24538",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24538"
},
{
"name": "CVE-2023-1255",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1255"
},
{
"name": "CVE-2016-3189",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-3189"
},
{
"name": "CVE-2021-45346",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-45346"
},
{
"name": "CVE-2023-28322",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28322"
},
{
"name": "CVE-2022-46908",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-46908"
},
{
"name": "CVE-2023-28320",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28320"
},
{
"name": "CVE-2023-28321",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28321"
},
{
"name": "CVE-2023-24540",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24540"
},
{
"name": "CVE-2023-29400",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29400"
},
{
"name": "CVE-2023-24539",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24539"
},
{
"name": "CVE-2021-28861",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-28861"
},
{
"name": "CVE-2023-2975",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2975"
},
{
"name": "CVE-2023-22049",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22049"
},
{
"name": "CVE-2023-25193",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-25193"
},
{
"name": "CVE-2023-22045",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22045"
},
{
"name": "CVE-2022-4899",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4899"
},
{
"name": "CVE-2023-0361",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0361"
},
{
"name": "CVE-2023-3446",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3446"
},
{
"name": "CVE-2023-28319",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28319"
},
{
"name": "CVE-2023-34967",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34967"
},
{
"name": "CVE-2023-34968",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34968"
},
{
"name": "CVE-2023-3817",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3817"
},
{
"name": "CVE-2023-29404",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29404"
},
{
"name": "CVE-2023-29402",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29402"
},
{
"name": "CVE-2023-29403",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29403"
},
{
"name": "CVE-2023-29405",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29405"
},
{
"name": "CVE-2023-2283",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2283"
},
{
"name": "CVE-2023-1667",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1667"
},
{
"name": "CVE-2023-2976",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2976"
},
{
"name": "CVE-2021-38297",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38297"
},
{
"name": "CVE-2023-29409",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29409"
},
{
"name": "CVE-2023-29406",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29406"
},
{
"name": "CVE-2023-40403",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40403"
},
{
"name": "CVE-2023-4911",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4911"
},
{
"name": "CVE-2023-44487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-44487"
},
{
"name": "CVE-2023-4091",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4091"
},
{
"name": "CVE-2023-42670",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-42670"
},
{
"name": "CVE-2023-4154",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4154"
},
{
"name": "CVE-2023-42669",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-42669"
},
{
"name": "CVE-2016-1000027",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-1000027"
},
{
"name": "CVE-2023-35116",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35116"
},
{
"name": "CVE-2023-38039",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38039"
},
{
"name": "CVE-2023-22081",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22081"
},
{
"name": "CVE-2023-22025",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22025"
},
{
"name": "CVE-2023-22067",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22067"
},
{
"name": "CVE-2023-38546",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38546"
},
{
"name": "CVE-2023-38545",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38545"
},
{
"name": "CVE-2023-5363",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5363"
},
{
"name": "CVE-2023-4807",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4807"
},
{
"name": "CVE-2023-30774",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30774"
},
{
"name": "CVE-2023-45853",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45853"
},
{
"name": "CVE-2023-5678",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5678"
},
{
"name": "CVE-2023-40217",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40217"
},
{
"name": "CVE-2022-1615",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1615"
},
{
"name": "CVE-2020-22218",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-22218"
},
{
"name": "CVE-2023-2603",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2603"
},
{
"name": "CVE-2023-2602",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2602"
},
{
"name": "CVE-2023-4527",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4527"
},
{
"name": "CVE-2023-4813",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4813"
},
{
"name": "CVE-2023-4806",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4806"
},
{
"name": "CVE-2022-48303",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48303"
},
{
"name": "CVE-2021-3426",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3426"
},
{
"name": "CVE-2023-34055",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34055"
},
{
"name": "CVE-2022-41409",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-41409"
},
{
"name": "CVE-2022-0563",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0563"
},
{
"name": "CVE-2023-32643",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32643"
},
{
"name": "CVE-2023-4039",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4039"
},
{
"name": "CVE-2022-2509",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2509"
},
{
"name": "CVE-2022-3715",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3715"
},
{
"name": "CVE-2023-0687",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0687"
},
{
"name": "CVE-2023-5156",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5156"
},
{
"name": "CVE-2022-48522",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48522"
},
{
"name": "CVE-2023-29491",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29491"
},
{
"name": "CVE-2023-35945",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-35945"
},
{
"name": "CVE-2023-32665",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32665"
},
{
"name": "CVE-2023-39615",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39615"
},
{
"name": "CVE-2021-37600",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-37600"
},
{
"name": "CVE-2021-46848",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46848"
},
{
"name": "CVE-2021-3997",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3997"
},
{
"name": "CVE-2021-33294",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-33294"
},
{
"name": "CVE-2021-43618",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43618"
},
{
"name": "CVE-2023-45322",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45322"
},
{
"name": "CVE-2023-29499",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29499"
},
{
"name": "CVE-2022-28321",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28321"
},
{
"name": "CVE-2021-32292",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32292"
},
{
"name": "CVE-2023-4016",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4016"
},
{
"name": "CVE-2013-4235",
"url": "https://www.cve.org/CVERecord?id=CVE-2013-4235"
},
{
"name": "CVE-2023-34969",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34969"
},
{
"name": "CVE-2023-32611",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32611"
},
{
"name": "CVE-2023-29383",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29383"
},
{
"name": "CVE-2023-5981",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5981"
},
{
"name": "CVE-2023-32636",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32636"
},
{
"name": "CVE-2023-51385",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51385"
},
{
"name": "CVE-2023-51384",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51384"
},
{
"name": "CVE-2023-48795",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48795"
},
{
"name": "CVE-2024-20696",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20696"
},
{
"name": "CVE-2023-6237",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6237"
},
{
"name": "CVE-2024-20918",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20918"
},
{
"name": "CVE-2024-20945",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20945"
},
{
"name": "CVE-2024-20952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20952"
},
{
"name": "CVE-2024-20919",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20919"
},
{
"name": "CVE-2024-20926",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20926"
},
{
"name": "CVE-2024-20921",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-20921"
},
{
"name": "CVE-2023-39323",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39323"
},
{
"name": "CVE-2024-0743",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0743"
},
{
"name": "CVE-2024-0746",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0746"
},
{
"name": "CVE-2023-31484",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31484"
},
{
"name": "CVE-2021-4048",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4048"
},
{
"name": "CVE-2023-36054",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36054"
},
{
"name": "CVE-2023-28487",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28487"
},
{
"name": "CVE-2023-30086",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30086"
},
{
"name": "CVE-2023-26965",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26965"
},
{
"name": "CVE-2022-42919",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42919"
},
{
"name": "CVE-2023-3316",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3316"
},
{
"name": "CVE-2023-28486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28486"
},
{
"name": "CVE-2022-28738",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28738"
},
{
"name": "CVE-2023-50868",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50868"
},
{
"name": "CVE-2023-2804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2804"
},
{
"name": "CVE-2023-7104",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7104"
},
{
"name": "CVE-2023-24534",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24534"
},
{
"name": "CVE-2023-6129",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6129"
},
{
"name": "CVE-2023-46218",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46218"
},
{
"name": "CVE-2023-46219",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46219"
},
{
"name": "CVE-2023-39318",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39318"
},
{
"name": "CVE-2023-39319",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39319"
},
{
"name": "CVE-2024-0727",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0727"
},
{
"name": "CVE-2024-25126",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25126"
},
{
"name": "CVE-2024-26141",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26141"
},
{
"name": "CVE-2024-26146",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26146"
},
{
"name": "CVE-2023-47038",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47038"
},
{
"name": "CVE-2022-48554",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48554"
},
{
"name": "CVE-2023-39325",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39325"
},
{
"name": "CVE-2024-24762",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24762"
},
{
"name": "CVE-2023-52593",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52593"
},
{
"name": "CVE-2023-5388",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5388"
},
{
"name": "CVE-2022-2127",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2127"
},
{
"name": "CVE-2023-27043",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27043"
},
{
"name": "CVE-2023-6481",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6481"
},
{
"name": "CVE-2023-36632",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-36632"
},
{
"name": "CVE-2024-28085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28085"
},
{
"name": "CVE-2024-2511",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2511"
},
{
"name": "CVE-2024-26256",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26256"
},
{
"name": "CVE-2020-22916",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-22916"
},
{
"name": "CVE-2016-2781",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-2781"
},
{
"name": "CVE-2023-3978",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3978"
},
{
"name": "CVE-2023-49083",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-49083"
},
{
"name": "CVE-2017-7501",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7501"
},
{
"name": "CVE-2021-35939",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35939"
},
{
"name": "CVE-2024-0553",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0553"
},
{
"name": "CVE-2021-35938",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35938"
},
{
"name": "CVE-2023-50782",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50782"
},
{
"name": "CVE-2021-35937",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35937"
},
{
"name": "CVE-2023-6597",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6597"
},
{
"name": "CVE-2023-52426",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52426"
},
{
"name": "CVE-2024-21011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21011"
},
{
"name": "CVE-2024-21094",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21094"
},
{
"name": "CVE-2024-21068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21068"
},
{
"name": "CVE-2024-21085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21085"
},
{
"name": "CVE-2024-26775",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26775"
},
{
"name": "CVE-2024-26726",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26726"
},
{
"name": "CVE-2024-26700",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26700"
},
{
"name": "CVE-2023-39326",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39326"
},
{
"name": "CVE-2023-45283",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45283"
},
{
"name": "CVE-2023-45285",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45285"
},
{
"name": "CVE-2023-45284",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45284"
},
{
"name": "CVE-2007-4559",
"url": "https://www.cve.org/CVERecord?id=CVE-2007-4559"
},
{
"name": "CVE-2023-52425",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52425"
},
{
"name": "CVE-2023-47282",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47282"
},
{
"name": "CVE-2023-47169",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47169"
},
{
"name": "CVE-2023-48368",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48368"
},
{
"name": "CVE-2023-22656",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22656"
},
{
"name": "CVE-2024-28182",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28182"
},
{
"name": "CVE-2023-45288",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45288"
},
{
"name": "CVE-2024-4603",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4603"
},
{
"name": "CVE-2023-6378",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6378"
},
{
"name": "CVE-2023-31486",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31486"
},
{
"name": "CVE-2022-48703",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48703"
},
{
"name": "CVE-2024-26896",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26896"
},
{
"name": "CVE-2018-14628",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14628"
},
{
"name": "CVE-2023-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38037"
},
{
"name": "CVE-2023-45289",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45289"
},
{
"name": "CVE-2023-45290",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45290"
},
{
"name": "CVE-2024-24783",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24783"
},
{
"name": "CVE-2024-24784",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24784"
},
{
"name": "CVE-2024-24785",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24785"
},
{
"name": "CVE-2024-4741",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4741"
},
{
"name": "CVE-2025-38727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38727"
},
{
"name": "CVE-2025-38237",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38237"
},
{
"name": "CVE-2025-38514",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38514"
},
{
"name": "CVE-2025-38542",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38542"
},
{
"name": "CVE-2025-38569",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38569"
},
{
"name": "CVE-2023-51074",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51074"
},
{
"name": "CVE-2025-9231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9231"
},
{
"name": "CVE-2025-41244",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41244"
},
{
"name": "CVE-2025-9230",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9230"
},
{
"name": "CVE-2025-9232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9232"
},
{
"name": "CVE-2025-61984",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61984"
},
{
"name": "CVE-2025-8291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8291"
},
{
"name": "CVE-2025-55248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55248"
},
{
"name": "CVE-2024-28757",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28757"
},
{
"name": "CVE-2025-58754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58754"
},
{
"name": "CVE-2025-55315",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55315"
},
{
"name": "CVE-2024-24786",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24786"
},
{
"name": "CVE-2024-29857",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-29857"
},
{
"name": "CVE-2024-30171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30171"
},
{
"name": "CVE-2024-30172",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-30172"
},
{
"name": "CVE-2024-5535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5535"
},
{
"name": "CVE-2025-9640",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9640"
},
{
"name": "CVE-2021-36770",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36770"
},
{
"name": "CVE-2023-5752",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5752"
},
{
"name": "CVE-2024-2004",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2004"
},
{
"name": "CVE-2024-2398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2398"
},
{
"name": "CVE-2024-0397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0397"
},
{
"name": "CVE-2024-4030",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4030"
},
{
"name": "CVE-2024-4032",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-4032"
},
{
"name": "CVE-2024-5642",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5642"
},
{
"name": "CVE-2024-34750",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34750"
},
{
"name": "CVE-2024-3596",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3596"
},
{
"name": "CVE-2025-41254",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41254"
},
{
"name": "CVE-2023-6004",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6004"
},
{
"name": "CVE-2023-6918",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6918"
},
{
"name": "CVE-2024-0450",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0450"
},
{
"name": "CVE-2024-25062",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25062"
},
{
"name": "CVE-2024-26458",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26458"
},
{
"name": "CVE-2024-26461",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26461"
},
{
"name": "CVE-2024-28834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28834"
},
{
"name": "CVE-2024-2961",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2961"
},
{
"name": "CVE-2024-33599",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33599"
},
{
"name": "CVE-2024-33600",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33600"
},
{
"name": "CVE-2024-33601",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33601"
},
{
"name": "CVE-2024-33602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-33602"
},
{
"name": "CVE-2022-1771",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1771"
},
{
"name": "CVE-2023-46246",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46246"
},
{
"name": "CVE-2023-48231",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48231"
},
{
"name": "CVE-2023-48232",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48232"
},
{
"name": "CVE-2023-48233",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48233"
},
{
"name": "CVE-2023-48234",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48234"
},
{
"name": "CVE-2023-48235",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48235"
},
{
"name": "CVE-2023-48236",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48236"
},
{
"name": "CVE-2023-48237",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48237"
},
{
"name": "CVE-2023-48706",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-48706"
},
{
"name": "CVE-2023-4641",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-4641"
},
{
"name": "CVE-2023-50495",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-50495"
},
{
"name": "CVE-2023-5341",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5341"
},
{
"name": "CVE-2024-0567",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-0567"
},
{
"name": "CVE-2024-22365",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-22365"
},
{
"name": "CVE-2023-46045",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-46045"
},
{
"name": "CVE-2024-21131",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21131"
},
{
"name": "CVE-2024-21138",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21138"
},
{
"name": "CVE-2024-21140",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21140"
},
{
"name": "CVE-2024-21144",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21144"
},
{
"name": "CVE-2024-21145",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21145"
},
{
"name": "CVE-2024-21147",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21147"
},
{
"name": "CVE-2018-13440",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-13440"
},
{
"name": "CVE-2019-13147",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-13147"
},
{
"name": "CVE-2022-24599",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-24599"
},
{
"name": "CVE-2024-28835",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-28835"
},
{
"name": "CVE-2021-35452",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-35452"
},
{
"name": "CVE-2021-36408",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36408"
},
{
"name": "CVE-2021-36410",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36410"
},
{
"name": "CVE-2021-36411",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-36411"
},
{
"name": "CVE-2022-43235",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43235"
},
{
"name": "CVE-2022-43236",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43236"
},
{
"name": "CVE-2022-43237",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43237"
},
{
"name": "CVE-2022-43238",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43238"
},
{
"name": "CVE-2022-43239",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43239"
},
{
"name": "CVE-2022-43240",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43240"
},
{
"name": "CVE-2022-43241",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43241"
},
{
"name": "CVE-2022-43242",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43242"
},
{
"name": "CVE-2022-43243",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43243"
},
{
"name": "CVE-2022-43244",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43244"
},
{
"name": "CVE-2022-43245",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43245"
},
{
"name": "CVE-2022-43248",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43248"
},
{
"name": "CVE-2022-43249",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43249"
},
{
"name": "CVE-2022-43250",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43250"
},
{
"name": "CVE-2022-43252",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43252"
},
{
"name": "CVE-2022-43253",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-43253"
},
{
"name": "CVE-2023-24751",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24751"
},
{
"name": "CVE-2023-24752",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24752"
},
{
"name": "CVE-2023-24754",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24754"
},
{
"name": "CVE-2023-24755",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24755"
},
{
"name": "CVE-2023-24756",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24756"
},
{
"name": "CVE-2023-24757",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24757"
},
{
"name": "CVE-2023-24758",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24758"
},
{
"name": "CVE-2023-6228",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6228"
},
{
"name": "CVE-2023-6277",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6277"
},
{
"name": "CVE-2024-6923",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6923"
},
{
"name": "CVE-2024-3219",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3219"
},
{
"name": "CVE-2023-45287",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45287"
},
{
"name": "CVE-2023-51767",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51767"
},
{
"name": "CVE-2024-24787",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24787"
},
{
"name": "CVE-2024-24788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24788"
},
{
"name": "CVE-2025-55551",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55551"
},
{
"name": "CVE-2025-55552",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55552"
},
{
"name": "CVE-2025-55554",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55554"
},
{
"name": "CVE-2025-61985",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61985"
},
{
"name": "CVE-2025-40778",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40778"
},
{
"name": "CVE-2025-40780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40780"
},
{
"name": "CVE-2025-8677",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8677"
},
{
"name": "CVE-2025-55754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55754"
},
{
"name": "CVE-2025-55752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55752"
},
{
"name": "CVE-2024-6345",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6345"
},
{
"name": "CVE-2024-38808",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38808"
},
{
"name": "CVE-2024-38809",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38809"
},
{
"name": "CVE-2025-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58056"
},
{
"name": "CVE-2025-58057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58057"
},
{
"name": "CVE-2025-47910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47910"
},
{
"name": "CVE-2025-8176",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8176"
},
{
"name": "CVE-2025-9900",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9900"
},
{
"name": "CVE-2025-40025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40025"
},
{
"name": "CVE-2025-40026",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40026"
},
{
"name": "CVE-2025-40027",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40027"
},
{
"name": "CVE-2025-53057",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53057"
},
{
"name": "CVE-2025-53066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53066"
},
{
"name": "CVE-2025-61748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61748"
},
{
"name": "CVE-2023-52969",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52969"
},
{
"name": "CVE-2023-52970",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-52970"
},
{
"name": "CVE-2024-21510",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21510"
},
{
"name": "CVE-2024-58266",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58266"
},
{
"name": "CVE-2025-46551",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46551"
},
{
"name": "CVE-2025-58767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58767"
},
{
"name": "CVE-2025-59830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59830"
},
{
"name": "CVE-2025-61770",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61770"
},
{
"name": "CVE-2025-61771",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61771"
},
{
"name": "CVE-2025-61772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61772"
},
{
"name": "CVE-2025-61780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61780"
},
{
"name": "CVE-2025-61919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61919"
},
{
"name": "CVE-2025-61921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61921"
},
{
"name": "CVE-2025-11411",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11411"
},
{
"name": "CVE-2025-62813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62813"
},
{
"name": "CVE-2025-53040",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53040"
},
{
"name": "CVE-2025-53042",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53042"
},
{
"name": "CVE-2025-53044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53044"
},
{
"name": "CVE-2025-53045",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53045"
},
{
"name": "CVE-2025-53053",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53053"
},
{
"name": "CVE-2025-53054",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53054"
},
{
"name": "CVE-2025-53062",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53062"
},
{
"name": "CVE-2025-53069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53069"
},
{
"name": "CVE-2025-5351",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5351"
},
{
"name": "CVE-2025-5987",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5987"
},
{
"name": "CVE-2025-61795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-61795"
},
{
"name": "CVE-2025-12380",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-12380"
},
{
"name": "CVE-2025-11226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11226"
},
{
"name": "CVE-2025-47906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47906"
},
{
"name": "CVE-2025-54388",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54388"
},
{
"name": "CVE-2023-3164",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3164"
},
{
"name": "CVE-2024-1013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-1013"
},
{
"name": "CVE-2024-34397",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34397"
},
{
"name": "CVE-2024-38428",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38428"
},
{
"name": "CVE-2024-38807",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38807"
},
{
"name": "CVE-2023-7008",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-7008"
},
{
"name": "CVE-2024-6232",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6232"
},
{
"name": "CVE-2024-6119",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6119"
},
{
"name": "CVE-2018-3779",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-3779"
},
{
"name": "CVE-2019-8321",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-8321"
},
{
"name": "CVE-2020-15095",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-15095"
},
{
"name": "CVE-2021-43809",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-43809"
},
{
"name": "CVE-2023-22796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-22796"
},
{
"name": "CVE-2023-28120",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28120"
},
{
"name": "CVE-2001-1268",
"url": "https://www.cve.org/CVERecord?id=CVE-2001-1268"
},
{
"name": "CVE-2001-1269",
"url": "https://www.cve.org/CVERecord?id=CVE-2001-1269"
},
{
"name": "CVE-2005-0602",
"url": "https://www.cve.org/CVERecord?id=CVE-2005-0602"
},
{
"name": "CVE-2011-2207",
"url": "https://www.cve.org/CVERecord?id=CVE-2011-2207"
},
{
"name": "CVE-2014-9157",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9157"
},
{
"name": "CVE-2014-9636",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9636"
},
{
"name": "CVE-2014-9748",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9748"
},
{
"name": "CVE-2014-9913",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-9913"
},
{
"name": "CVE-2015-1606",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-1606"
},
{
"name": "CVE-2015-7696",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7696"
},
{
"name": "CVE-2015-7697",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7697"
},
{
"name": "CVE-2015-7747",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-7747"
},
{
"name": "CVE-2015-8863",
"url": "https://www.cve.org/CVERecord?id=CVE-2015-8863"
},
{
"name": "CVE-2016-10062",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-10062"
},
{
"name": "CVE-2016-20012",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-20012"
},
{
"name": "CVE-2016-5118",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-5118"
},
{
"name": "CVE-2016-5841",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-5841"
},
{
"name": "CVE-2016-7514",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-7514"
},
{
"name": "CVE-2016-7531",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-7531"
},
{
"name": "CVE-2016-9844",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-9844"
},
{
"name": "CVE-2017-1000476",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-1000476"
},
{
"name": "CVE-2017-10928",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-10928"
},
{
"name": "CVE-2017-11447",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-11447"
},
{
"name": "CVE-2017-12429",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-12429"
},
{
"name": "CVE-2017-12433",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-12433"
},
{
"name": "CVE-2017-12643",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-12643"
},
{
"name": "CVE-2017-12674",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-12674"
},
{
"name": "CVE-2017-16231",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-16231"
},
{
"name": "CVE-2017-18250",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-18250"
},
{
"name": "CVE-2017-18253",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-18253"
},
{
"name": "CVE-2017-6829",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6829"
},
{
"name": "CVE-2017-6830",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6830"
},
{
"name": "CVE-2017-6831",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6831"
},
{
"name": "CVE-2017-6832",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6832"
},
{
"name": "CVE-2017-6833",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6833"
},
{
"name": "CVE-2017-6834",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6834"
},
{
"name": "CVE-2017-6835",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6835"
},
{
"name": "CVE-2017-6836",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6836"
},
{
"name": "CVE-2017-6837",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6837"
},
{
"name": "CVE-2017-6838",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6838"
},
{
"name": "CVE-2017-6839",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-6839"
},
{
"name": "CVE-2017-7619",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-7619"
},
{
"name": "CVE-2017-9409",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-9409"
},
{
"name": "CVE-2018-1000035",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-1000035"
},
{
"name": "CVE-2018-10804",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-10804"
},
{
"name": "CVE-2018-10805",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-10805"
},
{
"name": "CVE-2018-11655",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11655"
},
{
"name": "CVE-2018-11656",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-11656"
},
{
"name": "CVE-2018-12599",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12599"
},
{
"name": "CVE-2018-12600",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-12600"
},
{
"name": "CVE-2018-13153",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-13153"
},
{
"name": "CVE-2018-13410",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-13410"
},
{
"name": "CVE-2018-14434",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14434"
},
{
"name": "CVE-2018-14437",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-14437"
},
{
"name": "CVE-2018-15120",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-15120"
},
{
"name": "CVE-2018-15607",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-15607"
},
{
"name": "CVE-2018-15798",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-15798"
},
{
"name": "CVE-2018-16328",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16328"
},
{
"name": "CVE-2018-16329",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16329"
},
{
"name": "CVE-2018-16412",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16412"
},
{
"name": "CVE-2018-16645",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-16645"
},
{
"name": "CVE-2018-19876",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-19876"
},
{
"name": "CVE-2018-9133",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-9133"
},
{
"name": "CVE-2018-9135",
"url": "https://www.cve.org/CVERecord?id=CVE-2018-9135"
},
{
"name": "CVE-2019-14844",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-14844"
},
{
"name": "CVE-2019-17547",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-17547"
},
{
"name": "CVE-2019-3792",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-3792"
},
{
"name": "CVE-2019-6293",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-6293"
},
{
"name": "CVE-2019-6461",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-6461"
},
{
"name": "CVE-2019-6462",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-6462"
},
{
"name": "CVE-2019-9904",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-9904"
},
{
"name": "CVE-2020-0499",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-0499"
},
{
"name": "CVE-2020-10251",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-10251"
},
{
"name": "CVE-2020-14152",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14152"
},
{
"name": "CVE-2020-14153",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-14153"
},
{
"name": "CVE-2020-18032",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-18032"
},
{
"name": "CVE-2020-18781",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-18781"
},
{
"name": "CVE-2020-21599",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-21599"
},
{
"name": "CVE-2020-21605",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-21605"
},
{
"name": "CVE-2020-21606",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-21606"
},
{
"name": "CVE-2020-25663",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-25663"
},
{
"name": "CVE-2020-27768",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27768"
},
{
"name": "CVE-2020-27769",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27769"
},
{
"name": "CVE-2020-27776",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27776"
},
{
"name": "CVE-2020-27829",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-27829"
},
{
"name": "CVE-2020-29509",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-29509"
},
{
"name": "CVE-2020-29511",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-29511"
},
{
"name": "CVE-2020-35492",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-35492"
},
{
"name": "CVE-2021-20176",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20176"
},
{
"name": "CVE-2016-4074",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-4074"
},
{
"name": "CVE-2021-20241",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20241"
},
{
"name": "CVE-2021-20243",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20243"
},
{
"name": "CVE-2021-20244",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20244"
},
{
"name": "CVE-2021-20245",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20245"
},
{
"name": "CVE-2021-20246",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20246"
},
{
"name": "CVE-2021-20251",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20251"
},
{
"name": "CVE-2021-20309",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20309"
},
{
"name": "CVE-2021-20310",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20310"
},
{
"name": "CVE-2021-20311",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20311"
},
{
"name": "CVE-2021-20312",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20312"
},
{
"name": "CVE-2021-20313",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-20313"
},
{
"name": "CVE-2021-23215",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-23215"
},
{
"name": "CVE-2021-24031",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-24031"
},
{
"name": "CVE-2021-24032",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-24032"
},
{
"name": "CVE-2021-26260",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-26260"
},
{
"name": "CVE-2021-26720",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-26720"
},
{
"name": "CVE-2021-26945",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-26945"
},
{
"name": "CVE-2021-31879",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-31879"
},
{
"name": "CVE-2021-32490",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32490"
},
{
"name": "CVE-2021-32491",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32491"
},
{
"name": "CVE-2021-32492",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32492"
},
{
"name": "CVE-2021-32493",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32493"
},
{
"name": "CVE-2021-3468",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3468"
},
{
"name": "CVE-2021-3500",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3500"
},
{
"name": "CVE-2021-3502",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3502"
},
{
"name": "CVE-2021-3574",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3574"
},
{
"name": "CVE-2021-3596",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3596"
},
{
"name": "CVE-2021-3598",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3598"
},
{
"name": "CVE-2021-3605",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3605"
},
{
"name": "CVE-2021-3610",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3610"
},
{
"name": "CVE-2021-3670",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3670"
},
{
"name": "CVE-2021-38115",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-38115"
},
{
"name": "CVE-2021-39212",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-39212"
},
{
"name": "CVE-2021-3933",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3933"
},
{
"name": "CVE-2021-3941",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3941"
},
{
"name": "CVE-2021-40211",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-40211"
},
{
"name": "CVE-2021-40812",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-40812"
},
{
"name": "CVE-2021-4214",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4214"
},
{
"name": "CVE-2021-4217",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4217"
},
{
"name": "CVE-2021-4219",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-4219"
},
{
"name": "CVE-2021-44964",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-44964"
},
{
"name": "CVE-2021-45931",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-45931"
},
{
"name": "CVE-2021-45942",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-45942"
},
{
"name": "CVE-2021-46310",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46310"
},
{
"name": "CVE-2021-46312",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-46312"
},
{
"name": "CVE-2022-0284",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0284"
},
{
"name": "CVE-2022-0529",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0529"
},
{
"name": "CVE-2022-0865",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0865"
},
{
"name": "CVE-2022-0907",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0907"
},
{
"name": "CVE-2022-0909",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0909"
},
{
"name": "CVE-2022-0924",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0924"
},
{
"name": "CVE-2022-1056",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1056"
},
{
"name": "CVE-2022-1114",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1114"
},
{
"name": "CVE-2022-1115",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1115"
},
{
"name": "CVE-2022-1210",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1210"
},
{
"name": "CVE-2022-1355",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1355"
},
{
"name": "CVE-2022-1623",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1623"
},
{
"name": "CVE-2022-2231",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2231"
},
{
"name": "CVE-2022-2519",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2519"
},
{
"name": "CVE-2022-2520",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2520"
},
{
"name": "CVE-2022-2521",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2521"
},
{
"name": "CVE-2022-25308",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25308"
},
{
"name": "CVE-2022-25309",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25309"
},
{
"name": "CVE-2022-25310",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-25310"
},
{
"name": "CVE-2022-2598",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2598"
},
{
"name": "CVE-2022-26280",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-26280"
},
{
"name": "CVE-2022-2719",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2719"
},
{
"name": "CVE-2022-28463",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28463"
},
{
"name": "CVE-2022-28805",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-28805"
},
{
"name": "CVE-2022-29217",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-29217"
},
{
"name": "CVE-2022-2928",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2928"
},
{
"name": "CVE-2022-2929",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2929"
},
{
"name": "CVE-2022-2953",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2953"
},
{
"name": "CVE-2022-30698",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30698"
},
{
"name": "CVE-2022-30699",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-30699"
},
{
"name": "CVE-2022-31683",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31683"
},
{
"name": "CVE-2022-31782",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-31782"
},
{
"name": "CVE-2022-3213",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3213"
},
{
"name": "CVE-2022-32545",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32545"
},
{
"name": "CVE-2022-32546",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32546"
},
{
"name": "CVE-2022-32547",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-32547"
},
{
"name": "CVE-2022-33068",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-33068"
},
{
"name": "CVE-2022-33099",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-33099"
},
{
"name": "CVE-2022-36087",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-36087"
},
{
"name": "CVE-2022-44267",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44267"
},
{
"name": "CVE-2022-48281",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-48281"
},
{
"name": "CVE-2023-1289",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1289"
},
{
"name": "CVE-2023-1355",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1355"
},
{
"name": "CVE-2023-1906",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1906"
},
{
"name": "CVE-2023-1981",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1981"
},
{
"name": "CVE-2023-2157",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2157"
},
{
"name": "CVE-2023-2426",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2426"
},
{
"name": "CVE-2023-26785",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-26785"
},
{
"name": "CVE-2023-27102",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-27102"
},
{
"name": "CVE-2023-30571",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-30571"
},
{
"name": "CVE-2023-3195",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3195"
},
{
"name": "CVE-2023-34151",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34151"
},
{
"name": "CVE-2023-34152",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34152"
},
{
"name": "CVE-2023-34153",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34153"
},
{
"name": "CVE-2023-3428",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3428"
},
{
"name": "CVE-2023-34474",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34474"
},
{
"name": "CVE-2023-34475",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-34475"
},
{
"name": "CVE-2023-3618",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3618"
},
{
"name": "CVE-2023-38469",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38469"
},
{
"name": "CVE-2023-38470",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38470"
},
{
"name": "CVE-2023-38471",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38471"
},
{
"name": "CVE-2023-38472",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38472"
},
{
"name": "CVE-2023-38473",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38473"
},
{
"name": "CVE-2023-38633",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-38633"
},
{
"name": "CVE-2023-3896",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3896"
},
{
"name": "CVE-2023-39327",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39327"
},
{
"name": "CVE-2023-39593",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39593"
},
{
"name": "CVE-2023-39978",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39978"
},
{
"name": "CVE-2023-43887",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-43887"
},
{
"name": "CVE-2023-45913",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45913"
},
{
"name": "CVE-2023-45919",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45919"
},
{
"name": "CVE-2023-45922",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45922"
},
{
"name": "CVE-2023-45931",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-45931"
},
{
"name": "CVE-2023-47471",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47471"
},
{
"name": "CVE-2023-5568",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5568"
},
{
"name": "CVE-2024-10524",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10524"
},
{
"name": "CVE-2024-13978",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-13978"
},
{
"name": "CVE-2024-27766",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27766"
},
{
"name": "CVE-2024-37407",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37407"
},
{
"name": "CVE-2024-41817",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41817"
},
{
"name": "CVE-2024-43167",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43167"
},
{
"name": "CVE-2024-43168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43168"
},
{
"name": "CVE-2024-43790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43790"
},
{
"name": "CVE-2024-45720",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45720"
},
{
"name": "CVE-2024-46901",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-46901"
},
{
"name": "CVE-2024-57970",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57970"
},
{
"name": "CVE-2025-0306",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0306"
},
{
"name": "CVE-2025-0838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0838"
},
{
"name": "CVE-2025-10911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10911"
},
{
"name": "CVE-2025-11731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-11731"
},
{
"name": "CVE-2025-1632",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1632"
},
{
"name": "CVE-2025-2099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2099"
},
{
"name": "CVE-2025-2148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2148"
},
{
"name": "CVE-2025-2149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2149"
},
{
"name": "CVE-2025-2953",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2953"
},
{
"name": "CVE-2025-2998",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2998"
},
{
"name": "CVE-2025-2999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2999"
},
{
"name": "CVE-2025-3000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3000"
},
{
"name": "CVE-2025-3001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3001"
},
{
"name": "CVE-2025-3121",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3121"
},
{
"name": "CVE-2025-3136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3136"
},
{
"name": "CVE-2025-31498",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31498"
},
{
"name": "CVE-2025-3262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3262"
},
{
"name": "CVE-2025-3263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3263"
},
{
"name": "CVE-2025-3264",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3264"
},
{
"name": "CVE-2025-3730",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3730"
},
{
"name": "CVE-2025-3777",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3777"
},
{
"name": "CVE-2025-3933",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3933"
},
{
"name": "CVE-2025-40002",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40002"
},
{
"name": "CVE-2025-40004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40004"
},
{
"name": "CVE-2025-40007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40007"
},
{
"name": "CVE-2025-40015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40015"
},
{
"name": "CVE-2025-40017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40017"
},
{
"name": "CVE-2025-4056",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4056"
},
{
"name": "CVE-2025-4287",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4287"
},
{
"name": "CVE-2025-43965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-43965"
},
{
"name": "CVE-2025-46148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46148"
},
{
"name": "CVE-2025-46149",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46149"
},
{
"name": "CVE-2025-46150",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46150"
},
{
"name": "CVE-2025-46152",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46152"
},
{
"name": "CVE-2025-46153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46153"
},
{
"name": "CVE-2025-46393",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46393"
},
{
"name": "CVE-2025-46569",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46569"
},
{
"name": "CVE-2025-47291",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47291"
},
{
"name": "CVE-2025-50950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50950"
},
{
"name": "CVE-2025-5197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5197"
},
{
"name": "CVE-2025-52099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52099"
},
{
"name": "CVE-2025-53014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53014"
},
{
"name": "CVE-2025-53019",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53019"
},
{
"name": "CVE-2025-53101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53101"
},
{
"name": "CVE-2025-53367",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53367"
},
{
"name": "CVE-2025-53643",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53643"
},
{
"name": "CVE-2025-54801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54801"
},
{
"name": "CVE-2025-54874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54874"
},
{
"name": "CVE-2025-55004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55004"
},
{
"name": "CVE-2025-55005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55005"
},
{
"name": "CVE-2025-55154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55154"
},
{
"name": "CVE-2025-55160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55160"
},
{
"name": "CVE-2025-55197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55197"
},
{
"name": "CVE-2025-55212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55212"
},
{
"name": "CVE-2025-55298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55298"
},
{
"name": "CVE-2025-55553",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55553"
},
{
"name": "CVE-2025-55557",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55557"
},
{
"name": "CVE-2025-55558",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55558"
},
{
"name": "CVE-2025-55560",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55560"
},
{
"name": "CVE-2025-5745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5745"
},
{
"name": "CVE-2025-57803",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-57803"
},
{
"name": "CVE-2025-57807",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-57807"
},
{
"name": "CVE-2025-5878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5878"
},
{
"name": "CVE-2025-5918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5918"
},
{
"name": "CVE-2025-59375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59375"
},
{
"name": "CVE-2025-59842",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-59842"
},
{
"name": "CVE-2025-6051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6051"
},
{
"name": "CVE-2025-6052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6052"
},
{
"name": "CVE-2025-6141",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6141"
},
{
"name": "CVE-2025-62171",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-62171"
},
{
"name": "CVE-2025-6638",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6638"
},
{
"name": "CVE-2025-6921",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6921"
},
{
"name": "CVE-2025-7039",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7039"
},
{
"name": "CVE-2025-7709",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7709"
},
{
"name": "CVE-2025-8114",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8114"
},
{
"name": "CVE-2025-8177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8177"
},
{
"name": "CVE-2025-8277",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8277"
},
{
"name": "CVE-2025-8534",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8534"
},
{
"name": "CVE-2025-8556",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8556"
},
{
"name": "CVE-2025-8851",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8851"
},
{
"name": "CVE-2025-8961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8961"
},
{
"name": "CVE-2025-9092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9092"
},
{
"name": "CVE-2025-9165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9165"
},
{
"name": "CVE-2025-9340",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9340"
},
{
"name": "CVE-2025-9341",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9341"
},
{
"name": "CVE-2025-9390",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9390"
},
{
"name": "CVE-2025-9403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9403"
},
{
"name": "CVE-2025-9714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9714"
},
{
"name": "CVE-2024-45491",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45491"
},
{
"name": "CVE-2024-45492",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45492"
},
{
"name": "CVE-2024-38816",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38816"
},
{
"name": "CVE-2024-44939",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-44939"
},
{
"name": "CVE-2024-7264",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7264"
},
{
"name": "CVE-2024-41957",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41957"
},
{
"name": "CVE-2024-34459",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34459"
},
{
"name": "CVE-2024-8096",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8096"
},
{
"name": "CVE-2023-6246",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6246"
},
{
"name": "CVE-2024-27280",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27280"
},
{
"name": "CVE-2024-24789",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24789"
},
{
"name": "CVE-2024-34155",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34155"
},
{
"name": "CVE-2024-34156",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34156"
},
{
"name": "CVE-2024-34158",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34158"
},
{
"name": "CVE-2024-5569",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5569"
},
{
"name": "CVE-2024-24790",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24790"
},
{
"name": "CVE-2019-16775",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-16775"
},
{
"name": "CVE-2019-16776",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-16776"
},
{
"name": "CVE-2019-16777",
"url": "https://www.cve.org/CVERecord?id=CVE-2019-16777"
},
{
"name": "CVE-2024-21208",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21208"
},
{
"name": "CVE-2024-21210",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21210"
},
{
"name": "CVE-2024-21217",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21217"
},
{
"name": "CVE-2024-21235",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21235"
},
{
"name": "CVE-2024-37370",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37370"
},
{
"name": "CVE-2024-37371",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-37371"
},
{
"name": "CVE-2024-7254",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7254"
},
{
"name": "CVE-2024-9143",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9143"
},
{
"name": "CVE-2024-38819",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38819"
},
{
"name": "CVE-2024-38820",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38820"
},
{
"name": "CVE-2023-6349",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6349"
},
{
"name": "CVE-2024-5197",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-5197"
},
{
"name": "CVE-2024-35176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35176"
},
{
"name": "CVE-2024-39908",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-39908"
},
{
"name": "CVE-2024-41123",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41123"
},
{
"name": "CVE-2024-41946",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41946"
},
{
"name": "CVE-2024-43398",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43398"
},
{
"name": "CVE-2024-34447",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-34447"
},
{
"name": "CVE-2024-45490",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45490"
},
{
"name": "CVE-2024-47874",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47874"
},
{
"name": "CVE-2024-7592",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-7592"
},
{
"name": "CVE-2024-8088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8088"
},
{
"name": "CVE-2024-9681",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9681"
},
{
"name": "CVE-2024-11168",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11168"
},
{
"name": "CVE-2024-38828",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38828"
},
{
"name": "CVE-2024-38829",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38829"
},
{
"name": "CVE-2024-52316",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52316"
},
{
"name": "CVE-2024-43788",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43788"
},
{
"name": "CVE-2023-49582",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-49582"
},
{
"name": "CVE-2024-11053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11053"
},
{
"name": "CVE-2024-54534",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54534"
},
{
"name": "CVE-2024-10041",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10041"
},
{
"name": "CVE-2024-10963",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-10963"
},
{
"name": "CVE-2024-47554",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47554"
},
{
"name": "CVE-2024-50379",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50379"
},
{
"name": "CVE-2024-54677",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54677"
},
{
"name": "CVE-2024-27407",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27407"
},
{
"name": "CVE-2024-50157",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50157"
},
{
"name": "CVE-2017-9937",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-9937"
},
{
"name": "CVE-2022-0561",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0561"
},
{
"name": "CVE-2022-0562",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0562"
},
{
"name": "CVE-2022-0908",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-0908"
},
{
"name": "CVE-2022-2056",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2056"
},
{
"name": "CVE-2022-2057",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2057"
},
{
"name": "CVE-2022-2058",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2058"
},
{
"name": "CVE-2022-22844",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-22844"
},
{
"name": "CVE-2022-2867",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2867"
},
{
"name": "CVE-2022-2868",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2868"
},
{
"name": "CVE-2022-2869",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2869"
},
{
"name": "CVE-2022-34526",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-34526"
},
{
"name": "CVE-2022-3570",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3570"
},
{
"name": "CVE-2022-3597",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3597"
},
{
"name": "CVE-2022-3598",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3598"
},
{
"name": "CVE-2022-3599",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3599"
},
{
"name": "CVE-2022-3626",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3626"
},
{
"name": "CVE-2022-3627",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3627"
},
{
"name": "CVE-2022-40090",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-40090"
},
{
"name": "CVE-2022-4645",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4645"
},
{
"name": "CVE-2023-0795",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0795"
},
{
"name": "CVE-2023-0796",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0796"
},
{
"name": "CVE-2023-0797",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0797"
},
{
"name": "CVE-2023-0798",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0798"
},
{
"name": "CVE-2023-0799",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0799"
},
{
"name": "CVE-2023-0800",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0800"
},
{
"name": "CVE-2023-0801",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0801"
},
{
"name": "CVE-2023-0802",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0802"
},
{
"name": "CVE-2023-0803",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0803"
},
{
"name": "CVE-2023-0804",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-0804"
},
{
"name": "CVE-2023-1916",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1916"
},
{
"name": "CVE-2023-2731",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2731"
},
{
"name": "CVE-2023-2908",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2908"
},
{
"name": "CVE-2023-3576",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-3576"
},
{
"name": "CVE-2023-40745",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-40745"
},
{
"name": "CVE-2023-41175",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-41175"
},
{
"name": "CVE-2024-56337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56337"
},
{
"name": "CVE-2024-27281",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-27281"
},
{
"name": "CVE-2024-12085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12085"
},
{
"name": "CVE-2024-12086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12086"
},
{
"name": "CVE-2024-12087",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12087"
},
{
"name": "CVE-2024-12088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12088"
},
{
"name": "CVE-2024-12747",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12747"
},
{
"name": "CVE-2025-21502",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21502"
},
{
"name": "CVE-2025-23083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23083"
},
{
"name": "CVE-2025-23084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23084"
},
{
"name": "CVE-2025-23085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23085"
},
{
"name": "CVE-2024-11187",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11187"
},
{
"name": "CVE-2024-12705",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12705"
},
{
"name": "CVE-2025-0938",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0938"
},
{
"name": "CVE-2025-0167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0167"
},
{
"name": "CVE-2025-0725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0725"
},
{
"name": "CVE-2023-28154",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-28154"
},
{
"name": "CVE-2024-47535",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47535"
},
{
"name": "CVE-2024-50602",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-50602"
},
{
"name": "CVE-2025-21666",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21666"
},
{
"name": "CVE-2025-21669",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21669"
},
{
"name": "CVE-2025-21670",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21670"
},
{
"name": "CVE-2025-21674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21674"
},
{
"name": "CVE-2025-21675",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21675"
},
{
"name": "CVE-2025-21676",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21676"
},
{
"name": "CVE-2025-21678",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21678"
},
{
"name": "CVE-2025-21682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21682"
},
{
"name": "CVE-2024-53124",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53124"
},
{
"name": "CVE-2024-57948",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57948"
},
{
"name": "CVE-2025-21665",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21665"
},
{
"name": "CVE-2025-21667",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21667"
},
{
"name": "CVE-2025-21668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21668"
},
{
"name": "CVE-2025-21680",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21680"
},
{
"name": "CVE-2025-21681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21681"
},
{
"name": "CVE-2025-21683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21683"
},
{
"name": "CVE-2024-12797",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12797"
},
{
"name": "CVE-2024-13176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-13176"
},
{
"name": "CVE-2025-1094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1094"
},
{
"name": "CVE-2025-26465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-26465"
},
{
"name": "CVE-2025-21673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21673"
},
{
"name": "CVE-2024-49887",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49887"
},
{
"name": "CVE-2024-8508",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8508"
},
{
"name": "CVE-2025-1795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1795"
},
{
"name": "CVE-2025-21684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21684"
},
{
"name": "CVE-2025-21689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21689"
},
{
"name": "CVE-2025-21690",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21690"
},
{
"name": "CVE-2025-21692",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21692"
},
{
"name": "CVE-2025-21697",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21697"
},
{
"name": "CVE-2025-21699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21699"
},
{
"name": "CVE-2024-57949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57949"
},
{
"name": "CVE-2024-57951",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57951"
},
{
"name": "CVE-2025-21694",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21694"
},
{
"name": "CVE-2025-24813",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24813"
},
{
"name": "CVE-2024-57979",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57979"
},
{
"name": "CVE-2024-57994",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57994"
},
{
"name": "CVE-2025-21705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21705"
},
{
"name": "CVE-2025-21715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21715"
},
{
"name": "CVE-2025-21716",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21716"
},
{
"name": "CVE-2025-21719",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21719"
},
{
"name": "CVE-2025-21724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21724"
},
{
"name": "CVE-2025-21725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21725"
},
{
"name": "CVE-2025-21728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21728"
},
{
"name": "CVE-2025-21733",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21733"
},
{
"name": "CVE-2025-21753",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21753"
},
{
"name": "CVE-2025-21754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21754"
},
{
"name": "CVE-2025-21767",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21767"
},
{
"name": "CVE-2025-21790",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21790"
},
{
"name": "CVE-2025-21795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21795"
},
{
"name": "CVE-2025-21799",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21799"
},
{
"name": "CVE-2025-21802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21802"
},
{
"name": "CVE-2022-49043",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-49043"
},
{
"name": "CVE-2025-24970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24970"
},
{
"name": "CVE-2025-25193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25193"
},
{
"name": "CVE-2024-24791",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-24791"
},
{
"name": "CVE-2025-22228",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22228"
},
{
"name": "CVE-2023-24531",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-24531"
},
{
"name": "CVE-2024-45336",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45336"
},
{
"name": "CVE-2024-45337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45337"
},
{
"name": "CVE-2024-45341",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45341"
},
{
"name": "CVE-2025-22866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22866"
},
{
"name": "CVE-2025-22870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
},
{
"name": "CVE-2024-57996",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57996"
},
{
"name": "CVE-2024-58014",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58014"
},
{
"name": "CVE-2025-21718",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21718"
},
{
"name": "CVE-2025-21772",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21772"
},
{
"name": "CVE-2025-21780",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21780"
},
{
"name": "CVE-2025-21785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21785"
},
{
"name": "CVE-2024-57883",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57883"
},
{
"name": "CVE-2024-57924",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57924"
},
{
"name": "CVE-2024-56171",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56171"
},
{
"name": "CVE-2025-27113",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27113"
},
{
"name": "CVE-2024-54458",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54458"
},
{
"name": "CVE-2024-57834",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57834"
},
{
"name": "CVE-2024-57973",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57973"
},
{
"name": "CVE-2024-57980",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57980"
},
{
"name": "CVE-2024-57981",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57981"
},
{
"name": "CVE-2024-57986",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57986"
},
{
"name": "CVE-2024-57993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57993"
},
{
"name": "CVE-2024-57997",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57997"
},
{
"name": "CVE-2024-57998",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57998"
},
{
"name": "CVE-2024-58001",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58001"
},
{
"name": "CVE-2024-58007",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58007"
},
{
"name": "CVE-2024-58010",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58010"
},
{
"name": "CVE-2024-58011",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58011"
},
{
"name": "CVE-2024-58013",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58013"
},
{
"name": "CVE-2024-58016",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58016"
},
{
"name": "CVE-2024-58017",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58017"
},
{
"name": "CVE-2024-58020",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58020"
},
{
"name": "CVE-2024-58034",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58034"
},
{
"name": "CVE-2024-58051",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58051"
},
{
"name": "CVE-2024-58052",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58052"
},
{
"name": "CVE-2024-58054",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58054"
},
{
"name": "CVE-2024-58055",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58055"
},
{
"name": "CVE-2024-58056",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58056"
},
{
"name": "CVE-2024-58058",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58058"
},
{
"name": "CVE-2024-58061",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58061"
},
{
"name": "CVE-2024-58063",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58063"
},
{
"name": "CVE-2024-58068",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58068"
},
{
"name": "CVE-2024-58069",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58069"
},
{
"name": "CVE-2024-58071",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58071"
},
{
"name": "CVE-2024-58072",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58072"
},
{
"name": "CVE-2024-58076",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58076"
},
{
"name": "CVE-2024-58077",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58077"
},
{
"name": "CVE-2024-58080",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58080"
},
{
"name": "CVE-2024-58083",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58083"
},
{
"name": "CVE-2024-58085",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58085"
},
{
"name": "CVE-2024-58086",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58086"
},
{
"name": "CVE-2025-21704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21704"
},
{
"name": "CVE-2025-21706",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21706"
},
{
"name": "CVE-2025-21707",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21707"
},
{
"name": "CVE-2025-21708",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21708"
},
{
"name": "CVE-2025-21711",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21711"
},
{
"name": "CVE-2025-21722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21722"
},
{
"name": "CVE-2025-21726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21726"
},
{
"name": "CVE-2025-21727",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21727"
},
{
"name": "CVE-2025-21731",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21731"
},
{
"name": "CVE-2025-21734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21734"
},
{
"name": "CVE-2025-21735",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21735"
},
{
"name": "CVE-2025-21736",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21736"
},
{
"name": "CVE-2025-21738",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21738"
},
{
"name": "CVE-2025-21744",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21744"
},
{
"name": "CVE-2025-21745",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21745"
},
{
"name": "CVE-2025-21748",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21748"
},
{
"name": "CVE-2025-21749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21749"
},
{
"name": "CVE-2025-21750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21750"
},
{
"name": "CVE-2025-21758",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21758"
},
{
"name": "CVE-2025-21760",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21760"
},
{
"name": "CVE-2025-21761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21761"
},
{
"name": "CVE-2025-21762",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21762"
},
{
"name": "CVE-2025-21763",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21763"
},
{
"name": "CVE-2025-21764",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21764"
},
{
"name": "CVE-2025-21765",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21765"
},
{
"name": "CVE-2025-21766",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21766"
},
{
"name": "CVE-2025-21775",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21775"
},
{
"name": "CVE-2025-21776",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21776"
},
{
"name": "CVE-2025-21779",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21779"
},
{
"name": "CVE-2025-21781",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21781"
},
{
"name": "CVE-2025-21782",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21782"
},
{
"name": "CVE-2025-21787",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21787"
},
{
"name": "CVE-2025-21791",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21791"
},
{
"name": "CVE-2025-21792",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21792"
},
{
"name": "CVE-2025-21796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21796"
},
{
"name": "CVE-2025-21804",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21804"
},
{
"name": "CVE-2025-21806",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21806"
},
{
"name": "CVE-2025-21811",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21811"
},
{
"name": "CVE-2025-21812",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21812"
},
{
"name": "CVE-2025-21814",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21814"
},
{
"name": "CVE-2025-21820",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21820"
},
{
"name": "CVE-2025-21821",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21821"
},
{
"name": "CVE-2025-21823",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21823"
},
{
"name": "CVE-2025-21826",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21826"
},
{
"name": "CVE-2025-21829",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21829"
},
{
"name": "CVE-2025-21830",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21830"
},
{
"name": "CVE-2025-21832",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21832"
},
{
"name": "CVE-2025-21835",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21835"
},
{
"name": "CVE-2024-49761",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-49761"
},
{
"name": "CVE-2025-21574",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21574"
},
{
"name": "CVE-2025-21575",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21575"
},
{
"name": "CVE-2025-21577",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21577"
},
{
"name": "CVE-2025-21579",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21579"
},
{
"name": "CVE-2025-21580",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21580"
},
{
"name": "CVE-2025-21581",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21581"
},
{
"name": "CVE-2025-21584",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21584"
},
{
"name": "CVE-2025-21585",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21585"
},
{
"name": "CVE-2025-30681",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30681"
},
{
"name": "CVE-2025-30682",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30682"
},
{
"name": "CVE-2025-30683",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30683"
},
{
"name": "CVE-2025-30684",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30684"
},
{
"name": "CVE-2025-30685",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30685"
},
{
"name": "CVE-2025-30687",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30687"
},
{
"name": "CVE-2025-30688",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30688"
},
{
"name": "CVE-2025-30689",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30689"
},
{
"name": "CVE-2025-30693",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30693"
},
{
"name": "CVE-2025-30695",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30695"
},
{
"name": "CVE-2025-30696",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30696"
},
{
"name": "CVE-2025-30699",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30699"
},
{
"name": "CVE-2025-30703",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30703"
},
{
"name": "CVE-2025-30704",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30704"
},
{
"name": "CVE-2025-30705",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30705"
},
{
"name": "CVE-2025-30715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30715"
},
{
"name": "CVE-2025-30721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30721"
},
{
"name": "CVE-2025-30722",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30722"
},
{
"name": "CVE-2024-52559",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52559"
},
{
"name": "CVE-2024-57974",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57974"
},
{
"name": "CVE-2024-57990",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57990"
},
{
"name": "CVE-2024-57999",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57999"
},
{
"name": "CVE-2024-58002",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58002"
},
{
"name": "CVE-2024-58005",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58005"
},
{
"name": "CVE-2024-58006",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58006"
},
{
"name": "CVE-2024-58019",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58019"
},
{
"name": "CVE-2024-58057",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58057"
},
{
"name": "CVE-2024-58078",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58078"
},
{
"name": "CVE-2024-58079",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58079"
},
{
"name": "CVE-2025-21714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21714"
},
{
"name": "CVE-2025-21723",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21723"
},
{
"name": "CVE-2025-21732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21732"
},
{
"name": "CVE-2025-21739",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21739"
},
{
"name": "CVE-2025-21741",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21741"
},
{
"name": "CVE-2025-21742",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21742"
},
{
"name": "CVE-2025-21743",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21743"
},
{
"name": "CVE-2025-21759",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21759"
},
{
"name": "CVE-2025-21773",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21773"
},
{
"name": "CVE-2025-21784",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21784"
},
{
"name": "CVE-2025-21793",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21793"
},
{
"name": "CVE-2025-21810",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21810"
},
{
"name": "CVE-2025-21815",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21815"
},
{
"name": "CVE-2025-21825",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21825"
},
{
"name": "CVE-2025-21828",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21828"
},
{
"name": "CVE-2025-21838",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21838"
},
{
"name": "CVE-2025-21839",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21839"
},
{
"name": "CVE-2025-21844",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21844"
},
{
"name": "CVE-2025-21846",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21846"
},
{
"name": "CVE-2025-21847",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21847"
},
{
"name": "CVE-2025-21848",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21848"
},
{
"name": "CVE-2025-21855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21855"
},
{
"name": "CVE-2025-21856",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21856"
},
{
"name": "CVE-2025-21857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21857"
},
{
"name": "CVE-2025-21858",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21858"
},
{
"name": "CVE-2025-21859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21859"
},
{
"name": "CVE-2025-21861",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21861"
},
{
"name": "CVE-2025-21862",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21862"
},
{
"name": "CVE-2025-21864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21864"
},
{
"name": "CVE-2025-21866",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21866"
},
{
"name": "CVE-2025-21869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21869"
},
{
"name": "CVE-2025-21870",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21870"
},
{
"name": "CVE-2025-21871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21871"
},
{
"name": "CVE-2025-21877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21877"
},
{
"name": "CVE-2025-21878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21878"
},
{
"name": "CVE-2025-21883",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21883"
},
{
"name": "CVE-2025-21885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21885"
},
{
"name": "CVE-2025-21888",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21888"
},
{
"name": "CVE-2025-21890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21890"
},
{
"name": "CVE-2025-21891",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21891"
},
{
"name": "CVE-2025-21892",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21892"
},
{
"name": "CVE-2025-21587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21587"
},
{
"name": "CVE-2025-30698",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30698"
},
{
"name": "CVE-2024-8176",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-8176"
},
{
"name": "CVE-2025-24928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24928"
},
{
"name": "CVE-2024-57977",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57977"
},
{
"name": "CVE-2024-58090",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58090"
},
{
"name": "CVE-2025-21712",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21712"
},
{
"name": "CVE-2025-21721",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21721"
},
{
"name": "CVE-2025-21867",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21867"
},
{
"name": "CVE-2025-21875",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21875"
},
{
"name": "CVE-2025-21881",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21881"
},
{
"name": "CVE-2025-21887",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21887"
},
{
"name": "CVE-2025-21898",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21898"
},
{
"name": "CVE-2025-21899",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21899"
},
{
"name": "CVE-2025-21904",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21904"
},
{
"name": "CVE-2025-21905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21905"
},
{
"name": "CVE-2025-21909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21909"
},
{
"name": "CVE-2025-21910",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21910"
},
{
"name": "CVE-2025-21912",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21912"
},
{
"name": "CVE-2025-21913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21913"
},
{
"name": "CVE-2025-21914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21914"
},
{
"name": "CVE-2025-21916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21916"
},
{
"name": "CVE-2025-21917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21917"
},
{
"name": "CVE-2025-21918",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21918"
},
{
"name": "CVE-2025-21919",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21919"
},
{
"name": "CVE-2025-21920",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21920"
},
{
"name": "CVE-2025-21922",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21922"
},
{
"name": "CVE-2025-21924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21924"
},
{
"name": "CVE-2025-21925",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21925"
},
{
"name": "CVE-2025-21926",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21926"
},
{
"name": "CVE-2025-21928",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21928"
},
{
"name": "CVE-2025-21934",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21934"
},
{
"name": "CVE-2025-21935",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21935"
},
{
"name": "CVE-2025-21936",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21936"
},
{
"name": "CVE-2025-21937",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21937"
},
{
"name": "CVE-2025-21941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21941"
},
{
"name": "CVE-2025-21943",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21943"
},
{
"name": "CVE-2025-21944",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21944"
},
{
"name": "CVE-2025-21945",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21945"
},
{
"name": "CVE-2025-21947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21947"
},
{
"name": "CVE-2025-21948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21948"
},
{
"name": "CVE-2025-21950",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21950"
},
{
"name": "CVE-2025-21951",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21951"
},
{
"name": "CVE-2025-21956",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21956"
},
{
"name": "CVE-2025-21957",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21957"
},
{
"name": "CVE-2025-21959",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21959"
},
{
"name": "CVE-2025-21960",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21960"
},
{
"name": "CVE-2025-21962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21962"
},
{
"name": "CVE-2025-21963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21963"
},
{
"name": "CVE-2025-21964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21964"
},
{
"name": "CVE-2025-21968",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21968"
},
{
"name": "CVE-2025-21970",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21970"
},
{
"name": "CVE-2025-21975",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21975"
},
{
"name": "CVE-2025-21978",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21978"
},
{
"name": "CVE-2025-21979",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21979"
},
{
"name": "CVE-2025-21980",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21980"
},
{
"name": "CVE-2025-21981",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21981"
},
{
"name": "CVE-2025-21986",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21986"
},
{
"name": "CVE-2025-21991",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21991"
},
{
"name": "CVE-2025-21992",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21992"
},
{
"name": "CVE-2025-21994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21994"
},
{
"name": "CVE-2025-21996",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21996"
},
{
"name": "CVE-2025-21997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21997"
},
{
"name": "CVE-2025-21999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21999"
},
{
"name": "CVE-2025-22004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22004"
},
{
"name": "CVE-2025-22005",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22005"
},
{
"name": "CVE-2025-22007",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22007"
},
{
"name": "CVE-2025-22008",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22008"
},
{
"name": "CVE-2025-22010",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22010"
},
{
"name": "CVE-2025-22014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22014"
},
{
"name": "CVE-2025-22015",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22015"
},
{
"name": "CVE-2025-21969",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21969"
},
{
"name": "CVE-2024-12798",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12798"
},
{
"name": "CVE-2024-12801",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12801"
},
{
"name": "CVE-2025-27789",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27789"
},
{
"name": "CVE-2025-22868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22868"
},
{
"name": "CVE-2025-22871",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22871"
},
{
"name": "CVE-2025-22235",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22235"
},
{
"name": "CVE-2024-57952",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57952"
},
{
"name": "CVE-2025-21672",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21672"
},
{
"name": "CVE-2025-21691",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21691"
},
{
"name": "CVE-2025-2312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-2312"
},
{
"name": "CVE-2025-21927",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21927"
},
{
"name": "CVE-2025-21853",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21853"
},
{
"name": "CVE-2025-22088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22088"
},
{
"name": "CVE-2025-37785",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37785"
},
{
"name": "CVE-2025-27363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27363"
},
{
"name": "CVE-2025-27516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27516"
},
{
"name": "CVE-2024-58081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58081"
},
{
"name": "CVE-2025-4207",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4207"
},
{
"name": "CVE-2025-4516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4516"
},
{
"name": "CVE-2025-22233",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22233"
},
{
"name": "CVE-2024-55549",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-55549"
},
{
"name": "CVE-2024-9287",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-9287"
},
{
"name": "CVE-2025-24855",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24855"
},
{
"name": "CVE-2025-41232",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41232"
},
{
"name": "CVE-2025-23165",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23165"
},
{
"name": "CVE-2025-23166",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23166"
},
{
"name": "CVE-2025-23167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-23167"
},
{
"name": "CVE-2025-32414",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32414"
},
{
"name": "CVE-2025-32415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32415"
},
{
"name": "CVE-2024-58018",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58018"
},
{
"name": "CVE-2024-58070",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58070"
},
{
"name": "CVE-2024-58088",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58088"
},
{
"name": "CVE-2024-58093",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58093"
},
{
"name": "CVE-2025-21768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21768"
},
{
"name": "CVE-2025-21808",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21808"
},
{
"name": "CVE-2025-21836",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21836"
},
{
"name": "CVE-2025-21854",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21854"
},
{
"name": "CVE-2025-21863",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21863"
},
{
"name": "CVE-2025-21873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21873"
},
{
"name": "CVE-2025-21889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21889"
},
{
"name": "CVE-2025-21894",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21894"
},
{
"name": "CVE-2025-21895",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21895"
},
{
"name": "CVE-2025-21908",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21908"
},
{
"name": "CVE-2025-21915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21915"
},
{
"name": "CVE-2025-21930",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21930"
},
{
"name": "CVE-2025-21961",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21961"
},
{
"name": "CVE-2025-21966",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21966"
},
{
"name": "CVE-2025-21972",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21972"
},
{
"name": "CVE-2025-21976",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21976"
},
{
"name": "CVE-2025-21995",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21995"
},
{
"name": "CVE-2025-22001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22001"
},
{
"name": "CVE-2025-22003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22003"
},
{
"name": "CVE-2025-22009",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22009"
},
{
"name": "CVE-2025-22013",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22013"
},
{
"name": "CVE-2025-22016",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22016"
},
{
"name": "CVE-2025-22017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22017"
},
{
"name": "CVE-2025-37798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37798"
},
{
"name": "CVE-2025-22869",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22869"
},
{
"name": "CVE-2025-5283",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5283"
},
{
"name": "CVE-2025-4947",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4947"
},
{
"name": "CVE-2025-5025",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5025"
},
{
"name": "CVE-2025-46701",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-46701"
},
{
"name": "CVE-2025-21872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21872"
},
{
"name": "CVE-2025-37752",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37752"
},
{
"name": "CVE-2025-37756",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37756"
},
{
"name": "CVE-2025-37797",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37797"
},
{
"name": "CVE-2025-37889",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37889"
},
{
"name": "CVE-2025-37890",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37890"
},
{
"name": "CVE-2025-37932",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37932"
},
{
"name": "CVE-2025-37948",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37948"
},
{
"name": "CVE-2025-37963",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37963"
},
{
"name": "CVE-2025-4517",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4517"
},
{
"name": "CVE-2025-4330",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4330"
},
{
"name": "CVE-2025-4138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4138"
},
{
"name": "CVE-2024-12718",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12718"
},
{
"name": "CVE-2025-4435",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4435"
},
{
"name": "CVE-2022-1354",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-1354"
},
{
"name": "CVE-2025-27144",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27144"
},
{
"name": "CVE-2023-6779",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6779"
},
{
"name": "CVE-2023-6780",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-6780"
},
{
"name": "CVE-2024-12133",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12133"
},
{
"name": "CVE-2024-12243",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12243"
},
{
"name": "CVE-2024-2236",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-2236"
},
{
"name": "CVE-2024-52533",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52533"
},
{
"name": "CVE-2024-56433",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56433"
},
{
"name": "CVE-2025-0395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0395"
},
{
"name": "CVE-2025-1390",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1390"
},
{
"name": "CVE-2025-31115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31115"
},
{
"name": "CVE-2025-32728",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32728"
},
{
"name": "CVE-2025-4373",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4373"
},
{
"name": "CVE-2025-4598",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4598"
},
{
"name": "CVE-2025-32434",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32434"
},
{
"name": "CVE-2025-37750",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37750"
},
{
"name": "CVE-2025-37958",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37958"
},
{
"name": "CVE-2025-37974",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37974"
},
{
"name": "CVE-2025-49146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49146"
},
{
"name": "CVE-2025-27219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27219"
},
{
"name": "CVE-2025-27220",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27220"
},
{
"name": "CVE-2025-43859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-43859"
},
{
"name": "CVE-2025-48988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48988"
},
{
"name": "CVE-2025-49124",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49124"
},
{
"name": "CVE-2025-49125",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49125"
},
{
"name": "CVE-2023-32570",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-32570"
},
{
"name": "CVE-2023-39328",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-39328"
},
{
"name": "CVE-2023-51792",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-51792"
},
{
"name": "CVE-2024-38949",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38949"
},
{
"name": "CVE-2024-38950",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-38950"
},
{
"name": "CVE-2024-45993",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-45993"
},
{
"name": "CVE-2024-52616",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52616"
},
{
"name": "CVE-2024-53427",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-53427"
},
{
"name": "CVE-2024-56406",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56406"
},
{
"name": "CVE-2024-56826",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56826"
},
{
"name": "CVE-2024-56827",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-56827"
},
{
"name": "CVE-2025-22872",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22872"
},
{
"name": "CVE-2025-4802",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4802"
},
{
"name": "CVE-2025-21868",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21868"
},
{
"name": "CVE-2025-21929",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21929"
},
{
"name": "CVE-2025-40364",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40364"
},
{
"name": "CVE-2025-6020",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6020"
},
{
"name": "CVE-2025-6021",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6021"
},
{
"name": "CVE-2025-37997",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-37997"
},
{
"name": "CVE-2025-38000",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38000"
},
{
"name": "CVE-2025-38001",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38001"
},
{
"name": "CVE-2025-21903",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21903"
},
{
"name": "CVE-2025-21911",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21911"
},
{
"name": "CVE-2025-21946",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21946"
},
{
"name": "CVE-2025-21955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21955"
},
{
"name": "CVE-2025-21967",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21967"
},
{
"name": "CVE-2025-21977",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21977"
},
{
"name": "CVE-2025-21982",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21982"
},
{
"name": "CVE-2025-22011",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22011"
},
{
"name": "CVE-2025-32462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32462"
},
{
"name": "CVE-2025-32463",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32463"
},
{
"name": "CVE-2025-52434",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52434"
},
{
"name": "CVE-2025-52520",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52520"
},
{
"name": "CVE-2025-53506",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53506"
},
{
"name": "CVE-2022-2208",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2208"
},
{
"name": "CVE-2022-2874",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2874"
},
{
"name": "CVE-2022-2923",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2923"
},
{
"name": "CVE-2022-2980",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-2980"
},
{
"name": "CVE-2022-3153",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3153"
},
{
"name": "CVE-2022-3278",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3278"
},
{
"name": "CVE-2022-4293",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-4293"
},
{
"name": "CVE-2023-1170",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1170"
},
{
"name": "CVE-2023-1175",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1175"
},
{
"name": "CVE-2023-1264",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1264"
},
{
"name": "CVE-2023-2609",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-2609"
},
{
"name": "CVE-2023-5441",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-5441"
},
{
"name": "CVE-2024-41965",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-41965"
},
{
"name": "CVE-2024-43374",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43374"
},
{
"name": "CVE-2024-43802",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-43802"
},
{
"name": "CVE-2024-47081",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47081"
},
{
"name": "CVE-2024-47814",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47814"
},
{
"name": "CVE-2024-52615",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-52615"
},
{
"name": "CVE-2025-1215",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1215"
},
{
"name": "CVE-2025-22134",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22134"
},
{
"name": "CVE-2025-24014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24014"
},
{
"name": "CVE-2025-25724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25724"
},
{
"name": "CVE-2025-26603",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-26603"
},
{
"name": "CVE-2025-29768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29768"
},
{
"name": "CVE-2025-31344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31344"
},
{
"name": "CVE-2025-3576",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-3576"
},
{
"name": "CVE-2025-4565",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4565"
},
{
"name": "CVE-2025-47268",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47268"
},
{
"name": "CVE-2025-5702",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5702"
},
{
"name": "CVE-2024-57982",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57982"
},
{
"name": "CVE-2024-58053",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58053"
},
{
"name": "CVE-2025-21720",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21720"
},
{
"name": "CVE-2025-21880",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21880"
},
{
"name": "CVE-2025-38003",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38003"
},
{
"name": "CVE-2025-38004",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38004"
},
{
"name": "CVE-2025-38031",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38031"
},
{
"name": "CVE-2025-38043",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38043"
},
{
"name": "CVE-2025-38044",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38044"
},
{
"name": "CVE-2025-38065",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38065"
},
{
"name": "CVE-2025-38068",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38068"
},
{
"name": "CVE-2025-38072",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38072"
},
{
"name": "CVE-2025-38077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38077"
},
{
"name": "CVE-2025-38078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38078"
},
{
"name": "CVE-2025-38079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38079"
},
{
"name": "CVE-2025-38083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38083"
},
{
"name": "CVE-2025-22227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22227"
},
{
"name": "CVE-2025-30749",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30749"
},
{
"name": "CVE-2025-30754",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30754"
},
{
"name": "CVE-2025-30761",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30761"
},
{
"name": "CVE-2025-50059",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50059"
},
{
"name": "CVE-2025-50106",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50106"
},
{
"name": "CVE-2025-50077",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50077"
},
{
"name": "CVE-2025-50078",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50078"
},
{
"name": "CVE-2025-50079",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50079"
},
{
"name": "CVE-2025-50080",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50080"
},
{
"name": "CVE-2025-50082",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50082"
},
{
"name": "CVE-2025-50083",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50083"
},
{
"name": "CVE-2025-50084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50084"
},
{
"name": "CVE-2025-50085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50085"
},
{
"name": "CVE-2025-50086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50086"
},
{
"name": "CVE-2025-50087",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50087"
},
{
"name": "CVE-2025-50088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50088"
},
{
"name": "CVE-2025-50091",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50091"
},
{
"name": "CVE-2025-50092",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50092"
},
{
"name": "CVE-2025-50093",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50093"
},
{
"name": "CVE-2025-50094",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50094"
},
{
"name": "CVE-2025-50096",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50096"
},
{
"name": "CVE-2025-50097",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50097"
},
{
"name": "CVE-2025-50098",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50098"
},
{
"name": "CVE-2025-50099",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50099"
},
{
"name": "CVE-2025-50100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50100"
},
{
"name": "CVE-2025-50101",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50101"
},
{
"name": "CVE-2025-50102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50102"
},
{
"name": "CVE-2025-50104",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50104"
},
{
"name": "CVE-2025-53023",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53023"
},
{
"name": "CVE-2025-48734",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48734"
},
{
"name": "CVE-2025-38061",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38061"
},
{
"name": "CVE-2021-3995",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3995"
},
{
"name": "CVE-2021-3996",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-3996"
},
{
"name": "CVE-2024-23337",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-23337"
},
{
"name": "CVE-2024-47611",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-47611"
},
{
"name": "CVE-2025-0913",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-0913"
},
{
"name": "CVE-2025-22874",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-22874"
},
{
"name": "CVE-2025-25186",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-25186"
},
{
"name": "CVE-2025-27221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27221"
},
{
"name": "CVE-2025-29786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-29786"
},
{
"name": "CVE-2025-32955",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32955"
},
{
"name": "CVE-2025-32988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32988"
},
{
"name": "CVE-2025-32989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32989"
},
{
"name": "CVE-2025-32990",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32990"
},
{
"name": "CVE-2025-38177",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38177"
},
{
"name": "CVE-2025-4673",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4673"
},
{
"name": "CVE-2025-48060",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48060"
},
{
"name": "CVE-2025-4877",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4877"
},
{
"name": "CVE-2025-4878",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4878"
},
{
"name": "CVE-2025-48924",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48924"
},
{
"name": "CVE-2025-49014",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49014"
},
{
"name": "CVE-2025-50181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50181"
},
{
"name": "CVE-2025-5318",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5318"
},
{
"name": "CVE-2025-5372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5372"
},
{
"name": "CVE-2025-5914",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5914"
},
{
"name": "CVE-2025-5915",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5915"
},
{
"name": "CVE-2025-5916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5916"
},
{
"name": "CVE-2025-5917",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5917"
},
{
"name": "CVE-2025-6069",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6069"
},
{
"name": "CVE-2025-6395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6395"
},
{
"name": "CVE-2024-57953",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57953"
},
{
"name": "CVE-2024-57975",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-57975"
},
{
"name": "CVE-2024-58003",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58003"
},
{
"name": "CVE-2024-58082",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-58082"
},
{
"name": "CVE-2025-21710",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21710"
},
{
"name": "CVE-2025-21798",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21798"
},
{
"name": "CVE-2025-21801",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21801"
},
{
"name": "CVE-2025-21809",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21809"
},
{
"name": "CVE-2025-21816",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21816"
},
{
"name": "CVE-2025-38086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38086"
},
{
"name": "CVE-2025-8194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8194"
},
{
"name": "CVE-2025-7424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7424"
},
{
"name": "CVE-2025-7425",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7425"
},
{
"name": "CVE-2024-12254",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-12254"
},
{
"name": "CVE-2025-50182",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-50182"
},
{
"name": "CVE-2025-38052",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38052"
},
{
"name": "CVE-2025-38088",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38088"
},
{
"name": "CVE-2025-27210",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27210"
},
{
"name": "CVE-2025-38181",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38181"
},
{
"name": "CVE-2025-38200",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38200"
},
{
"name": "CVE-2025-38206",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38206"
},
{
"name": "CVE-2025-38212",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38212"
},
{
"name": "CVE-2025-38257",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38257"
},
{
"name": "CVE-2025-27817",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27817"
},
{
"name": "CVE-2025-27818",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27818"
},
{
"name": "CVE-2025-48989",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48989"
},
{
"name": "CVE-2025-7783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7783"
},
{
"name": "CVE-2025-53859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53859"
},
{
"name": "CVE-2025-24293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24293"
},
{
"name": "CVE-2025-55193",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55193"
},
{
"name": "CVE-2021-32256",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-32256"
},
{
"name": "CVE-2024-25260",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-25260"
},
{
"name": "CVE-2025-1371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1371"
},
{
"name": "CVE-2025-1376",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1376"
},
{
"name": "CVE-2025-1377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1377"
},
{
"name": "CVE-2025-47273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47273"
},
{
"name": "CVE-2025-48964",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-48964"
},
{
"name": "CVE-2025-49794",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49794"
},
{
"name": "CVE-2025-49796",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49796"
},
{
"name": "CVE-2025-53905",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53905"
},
{
"name": "CVE-2025-53906",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53906"
},
{
"name": "CVE-2025-41242",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41242"
},
{
"name": "CVE-2025-38034",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38034"
},
{
"name": "CVE-2025-38035",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38035"
},
{
"name": "CVE-2025-38037",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38037"
},
{
"name": "CVE-2025-38048",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38048"
},
{
"name": "CVE-2025-38051",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38051"
},
{
"name": "CVE-2025-38058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38058"
},
{
"name": "CVE-2025-38066",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38066"
},
{
"name": "CVE-2025-38067",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38067"
},
{
"name": "CVE-2025-38074",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38074"
},
{
"name": "CVE-2025-38075",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38075"
},
{
"name": "CVE-2025-38084",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38084"
},
{
"name": "CVE-2025-38085",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38085"
},
{
"name": "CVE-2025-38090",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38090"
},
{
"name": "CVE-2025-38100",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38100"
},
{
"name": "CVE-2025-38102",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38102"
},
{
"name": "CVE-2025-38103",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38103"
},
{
"name": "CVE-2025-38107",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38107"
},
{
"name": "CVE-2025-38108",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38108"
},
{
"name": "CVE-2025-38111",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38111"
},
{
"name": "CVE-2025-38112",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38112"
},
{
"name": "CVE-2025-38115",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38115"
},
{
"name": "CVE-2025-38119",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38119"
},
{
"name": "CVE-2025-38120",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38120"
},
{
"name": "CVE-2025-38122",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38122"
},
{
"name": "CVE-2025-38135",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38135"
},
{
"name": "CVE-2025-38136",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38136"
},
{
"name": "CVE-2025-38138",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38138"
},
{
"name": "CVE-2025-38143",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38143"
},
{
"name": "CVE-2025-38145",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38145"
},
{
"name": "CVE-2025-38146",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38146"
},
{
"name": "CVE-2025-38147",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38147"
},
{
"name": "CVE-2025-38153",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38153"
},
{
"name": "CVE-2025-38154",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38154"
},
{
"name": "CVE-2025-38157",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38157"
},
{
"name": "CVE-2025-38159",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38159"
},
{
"name": "CVE-2025-38160",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38160"
},
{
"name": "CVE-2025-38161",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38161"
},
{
"name": "CVE-2025-38163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38163"
},
{
"name": "CVE-2025-38167",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38167"
},
{
"name": "CVE-2025-38173",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38173"
},
{
"name": "CVE-2025-38174",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38174"
},
{
"name": "CVE-2025-38184",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38184"
},
{
"name": "CVE-2025-38194",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38194"
},
{
"name": "CVE-2025-38197",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38197"
},
{
"name": "CVE-2025-38211",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38211"
},
{
"name": "CVE-2025-38218",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38218"
},
{
"name": "CVE-2025-38219",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38219"
},
{
"name": "CVE-2025-38222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38222"
},
{
"name": "CVE-2025-38226",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38226"
},
{
"name": "CVE-2025-38227",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38227"
},
{
"name": "CVE-2025-38229",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38229"
},
{
"name": "CVE-2025-38231",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38231"
},
{
"name": "CVE-2025-38245",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38245"
},
{
"name": "CVE-2025-38249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38249"
},
{
"name": "CVE-2025-38251",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38251"
},
{
"name": "CVE-2025-38262",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38262"
},
{
"name": "CVE-2025-38263",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38263"
},
{
"name": "CVE-2025-38273",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38273"
},
{
"name": "CVE-2025-38280",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38280"
},
{
"name": "CVE-2025-38285",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38285"
},
{
"name": "CVE-2025-38286",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38286"
},
{
"name": "CVE-2025-38293",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38293"
},
{
"name": "CVE-2025-38298",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38298"
},
{
"name": "CVE-2025-38305",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38305"
},
{
"name": "CVE-2025-38310",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38310"
},
{
"name": "CVE-2025-38312",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38312"
},
{
"name": "CVE-2025-38313",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38313"
},
{
"name": "CVE-2025-38319",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38319"
},
{
"name": "CVE-2025-38320",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38320"
},
{
"name": "CVE-2025-38324",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38324"
},
{
"name": "CVE-2025-38326",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38326"
},
{
"name": "CVE-2025-38328",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38328"
},
{
"name": "CVE-2025-38332",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38332"
},
{
"name": "CVE-2025-38336",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38336"
},
{
"name": "CVE-2025-38337",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38337"
},
{
"name": "CVE-2025-38342",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38342"
},
{
"name": "CVE-2025-38344",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38344"
},
{
"name": "CVE-2025-38345",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38345"
},
{
"name": "CVE-2025-38346",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38346"
},
{
"name": "CVE-2025-38348",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38348"
},
{
"name": "CVE-2025-38350",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38350"
},
{
"name": "CVE-2025-38352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38352"
},
{
"name": "CVE-2025-38362",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38362"
},
{
"name": "CVE-2025-38363",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38363"
},
{
"name": "CVE-2025-38371",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38371"
},
{
"name": "CVE-2025-38375",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38375"
},
{
"name": "CVE-2025-38377",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38377"
},
{
"name": "CVE-2025-38384",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38384"
},
{
"name": "CVE-2025-38386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38386"
},
{
"name": "CVE-2025-38387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38387"
},
{
"name": "CVE-2025-38389",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38389"
},
{
"name": "CVE-2025-38391",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38391"
},
{
"name": "CVE-2025-38393",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38393"
},
{
"name": "CVE-2025-38395",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38395"
},
{
"name": "CVE-2025-38399",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38399"
},
{
"name": "CVE-2025-38400",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38400"
},
{
"name": "CVE-2025-38401",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38401"
},
{
"name": "CVE-2025-38403",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38403"
},
{
"name": "CVE-2025-38406",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38406"
},
{
"name": "CVE-2025-38410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38410"
},
{
"name": "CVE-2025-38412",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38412"
},
{
"name": "CVE-2025-38415",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38415"
},
{
"name": "CVE-2025-38416",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38416"
},
{
"name": "CVE-2025-38418",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38418"
},
{
"name": "CVE-2025-38419",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38419"
},
{
"name": "CVE-2025-38420",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38420"
},
{
"name": "CVE-2025-38424",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38424"
},
{
"name": "CVE-2025-38428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38428"
},
{
"name": "CVE-2025-38430",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38430"
},
{
"name": "CVE-2025-38439",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38439"
},
{
"name": "CVE-2025-38441",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38441"
},
{
"name": "CVE-2025-38443",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38443"
},
{
"name": "CVE-2025-38444",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38444"
},
{
"name": "CVE-2025-38445",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38445"
},
{
"name": "CVE-2025-38448",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38448"
},
{
"name": "CVE-2025-38457",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38457"
},
{
"name": "CVE-2025-38458",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38458"
},
{
"name": "CVE-2025-38459",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38459"
},
{
"name": "CVE-2025-38460",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38460"
},
{
"name": "CVE-2025-38461",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38461"
},
{
"name": "CVE-2025-38462",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38462"
},
{
"name": "CVE-2025-38464",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38464"
},
{
"name": "CVE-2025-38465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38465"
},
{
"name": "CVE-2025-38466",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38466"
},
{
"name": "CVE-2025-38467",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38467"
},
{
"name": "CVE-2025-38477",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38477"
},
{
"name": "CVE-2025-38498",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38498"
},
{
"name": "CVE-2025-38500",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38500"
},
{
"name": "CVE-2025-8713",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8713"
},
{
"name": "CVE-2025-8714",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8714"
},
{
"name": "CVE-2025-8715",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8715"
},
{
"name": "CVE-2024-54456",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-54456"
},
{
"name": "CVE-2025-21746",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21746"
},
{
"name": "CVE-2025-21783",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21783"
},
{
"name": "CVE-2025-21786",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-21786"
},
{
"name": "CVE-2025-38203",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38203"
},
{
"name": "CVE-2025-38204",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38204"
},
{
"name": "CVE-2025-54988",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54988"
},
{
"name": "CVE-2025-6965",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6965"
},
{
"name": "CVE-2025-55668",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55668"
},
{
"name": "CVE-2025-4674",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-4674"
},
{
"name": "CVE-2025-47907",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-47907"
},
{
"name": "CVE-2025-52999",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-52999"
},
{
"name": "CVE-2025-54410",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-54410"
},
{
"name": "CVE-2025-55163",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55163"
},
{
"name": "CVE-2025-8941",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8941"
},
{
"name": "CVE-2025-9288",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9288"
},
{
"name": "CVE-2011-3374",
"url": "https://www.cve.org/CVERecord?id=CVE-2011-3374"
},
{
"name": "CVE-2014-4715",
"url": "https://www.cve.org/CVERecord?id=CVE-2014-4715"
},
{
"name": "CVE-2016-0682",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0682"
},
{
"name": "CVE-2016-0689",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0689"
},
{
"name": "CVE-2016-0692",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0692"
},
{
"name": "CVE-2016-0694",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-0694"
},
{
"name": "CVE-2016-3418",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-3418"
},
{
"name": "CVE-2017-10140",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-10140"
},
{
"name": "CVE-2017-3604",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3604"
},
{
"name": "CVE-2017-3605",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3605"
},
{
"name": "CVE-2017-3606",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3606"
},
{
"name": "CVE-2017-3607",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3607"
},
{
"name": "CVE-2017-3608",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3608"
},
{
"name": "CVE-2017-3609",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3609"
},
{
"name": "CVE-2017-3610",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3610"
},
{
"name": "CVE-2017-3611",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3611"
},
{
"name": "CVE-2017-3612",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3612"
},
{
"name": "CVE-2017-3613",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3613"
},
{
"name": "CVE-2017-3614",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3614"
},
{
"name": "CVE-2017-3615",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3615"
},
{
"name": "CVE-2017-3616",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3616"
},
{
"name": "CVE-2017-3617",
"url": "https://www.cve.org/CVERecord?id=CVE-2017-3617"
},
{
"name": "CVE-2020-2981",
"url": "https://www.cve.org/CVERecord?id=CVE-2020-2981"
},
{
"name": "CVE-2022-3219",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-3219"
},
{
"name": "CVE-2022-39046",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-39046"
},
{
"name": "CVE-2022-42010",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42010"
},
{
"name": "CVE-2022-42011",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42011"
},
{
"name": "CVE-2022-42012",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-42012"
},
{
"name": "CVE-2022-44638",
"url": "https://www.cve.org/CVERecord?id=CVE-2022-44638"
},
{
"name": "CVE-2023-31437",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31437"
},
{
"name": "CVE-2023-31438",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31438"
},
{
"name": "CVE-2023-31439",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-31439"
},
{
"name": "CVE-2023-37769",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-37769"
},
{
"name": "CVE-2023-47039",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-47039"
},
{
"name": "CVE-2024-11584",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-11584"
},
{
"name": "CVE-2024-21742",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-21742"
},
{
"name": "CVE-2024-26462",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-26462"
},
{
"name": "CVE-2024-3220",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-3220"
},
{
"name": "CVE-2024-6174",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-6174"
},
{
"name": "CVE-2025-1352",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1352"
},
{
"name": "CVE-2025-1365",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1365"
},
{
"name": "CVE-2025-1372",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-1372"
},
{
"name": "CVE-2025-24294",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-24294"
},
{
"name": "CVE-2025-27587",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-27587"
},
{
"name": "CVE-2025-30258",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-30258"
},
{
"name": "CVE-2025-31672",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-31672"
},
{
"name": "CVE-2025-40909",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-40909"
},
{
"name": "CVE-2025-43857",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-43857"
},
{
"name": "CVE-2025-45582",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-45582"
},
{
"name": "CVE-2025-45768",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-45768"
},
{
"name": "CVE-2025-49795",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-49795"
},
{
"name": "CVE-2025-5222",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5222"
},
{
"name": "CVE-2025-5278",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5278"
},
{
"name": "CVE-2025-53864",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53864"
},
{
"name": "CVE-2025-6170",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6170"
},
{
"name": "CVE-2025-6297",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6297"
},
{
"name": "CVE-2025-7962",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-7962"
},
{
"name": "CVE-2025-8058",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8058"
},
{
"name": "CVE-2025-8732",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8732"
},
{
"name": "CVE-2025-8885",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8885"
},
{
"name": "CVE-2025-8916",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-8916"
},
{
"name": "CVE-2025-32386",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32386"
},
{
"name": "CVE-2025-32387",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-32387"
},
{
"name": "CVE-2025-53547",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53547"
},
{
"name": "CVE-2025-10148",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-10148"
},
{
"name": "CVE-2025-9086",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-9086"
},
{
"name": "CVE-2025-38513",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38513"
},
{
"name": "CVE-2025-38515",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38515"
},
{
"name": "CVE-2025-38516",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38516"
},
{
"name": "CVE-2025-38540",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38540"
},
{
"name": "CVE-2025-38617",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38617"
},
{
"name": "CVE-2025-38618",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-38618"
},
{
"name": "CVE-2025-5994",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-5994"
},
{
"name": "CVE-2025-41248",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41248"
},
{
"name": "CVE-2025-41249",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-41249"
}
],
"initial_release_date": "2025-11-06T00:00:00",
"last_revision_date": "2025-11-06T00:00:00",
"links": [],
"reference": "CERTFR-2025-AVI-0969",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2025-11-06T00:00:00.000000"
}
],
"risks": [
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits VMware. Elles permettent \u00e0 un attaquant de provoquer un probl\u00e8me de s\u00e9curit\u00e9 non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits VMware",
"vendor_advisories": [
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36320",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36320"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36423",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36423"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2022-19",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36364"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-53",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36351"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36424",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36424"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36412",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36412"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36388",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36388"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36426",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36426"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36411",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36411"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36357",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36357"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36408",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36408"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36349",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36349"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36414",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36414"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36397",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36397"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36389",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36389"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36398",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36398"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36380",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36380"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-41",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36407"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36362",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36362"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36413",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36413"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36384",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36384"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36379",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36379"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36400",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36400"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36377",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36377"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36368",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36368"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36418",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36418"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36420",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36420"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36391",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36391"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36392",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36392"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36353",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36353"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-14",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36356"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36422",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36422"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36381",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36381"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36421",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36421"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36416",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36416"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-86",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36415"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36403",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36403"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36347",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36347"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36383",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36383"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36410",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36410"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36352",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36352"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36394",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36394"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36354",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36354"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36399",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36399"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-53",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36350"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36419",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36419"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-85",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36401"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2022-19",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36365"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36405",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36405"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2018-27",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36367"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36395",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36395"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36387",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36387"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36363",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36363"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36385",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36385"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36409",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36409"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-53",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36359"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36348",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36348"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36386",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36386"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36417",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36417"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36425",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36425"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2018-27",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36366"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2024-44",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36360"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36355",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36355"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2025-53",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36358"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36396",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36396"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36378",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36378"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36382",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36382"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36404",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36404"
},
{
"published_at": "2025-11-05",
"title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2024-44",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36361"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36402",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36402"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36393",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36393"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36406",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36406"
},
{
"published_at": "2025-11-06",
"title": "Bulletin de s\u00e9curit\u00e9 VMware 36390",
"url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36390"
}
]
}
FKIE_CVE-2024-58069
Vulnerability from fkie_nvd - Published: 2025-03-06 16:15 - Updated: 2026-06-17 08:147.8 (High) - CVSS:3.1/
| URL | Tags | ||
|---|---|---|---|
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/517aedb365f2c94e2d7e0b908ac7127df76203a1 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/9adefa7b9559d0f21034a5d5ec1b55840c9348b9 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/e5536677da803ed54a29a446515c28dce7d3d574 | Patch | |
| 416baaa9-dc9f-4396-8d5f-8c081fb06d67 | https://git.kernel.org/stable/c/e5e06455760f2995b16a176033909347929d1128 | Patch | |
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html | ||
| af854a3a-2127-422b-91ae-364da2661108 | https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html |
| Vendor | Product | Version | |
|---|---|---|---|
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * | |
| linux | linux_kernel | * |
{
"affected": [
{
"affectedData": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"drivers/rtc/rtc-pcf85063.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "e5536677da803ed54a29a446515c28dce7d3d574",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "9adefa7b9559d0f21034a5d5ec1b55840c9348b9",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "e5e06455760f2995b16a176033909347929d1128",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "517aedb365f2c94e2d7e0b908ac7127df76203a1",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
},
{
"lessThan": "3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c",
"status": "affected",
"version": "fadfd092ee9138825d8c2a4f95719d2e2e3202b9",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"drivers/rtc/rtc-pcf85063.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.2"
},
{
"lessThan": "5.2",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.4.*",
"status": "unaffected",
"version": "5.4.291",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.235",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.179",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.129",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.76",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.13",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.13.*",
"status": "unaffected",
"version": "6.13.2",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.14",
"versionType": "original_commit_for_fix"
}
]
}
],
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "18F68456-FFB3-4E0E-A802-F3E41C67B10E",
"versionEndExcluding": "5.4.291",
"versionStartIncluding": "5.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "545121FA-DE31-4154-9446-C2000FB4104D",
"versionEndExcluding": "5.10.235",
"versionStartIncluding": "5.5",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "C708062C-4E1B-465F-AE6D-C09C46400875",
"versionEndExcluding": "5.15.179",
"versionStartIncluding": "5.11",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2DA5009C-C9B9-4A1D-9B96-78427E8F232C",
"versionEndExcluding": "6.1.129",
"versionStartIncluding": "5.16",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "A6D70701-9CB6-4222-A957-00A419878993",
"versionEndExcluding": "6.6.76",
"versionStartIncluding": "6.2",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "2897389C-A8C3-4D69-90F2-E701B3D66373",
"versionEndExcluding": "6.12.13",
"versionStartIncluding": "6.7",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"matchCriteriaId": "6D4116B1-1BFD-4F23-BA84-169CC05FC5A3",
"versionEndExcluding": "6.13.2",
"versionStartIncluding": "6.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value."
},
{
"lang": "es",
"value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: rtc: pcf85063: se corrige una posible escritura OOB en la lectura NVMEM PCF85063 La interfaz nvmem admite tama\u00f1os de b\u00fafer variables, mientras que la interfaz regmap opera con almacenamiento de tama\u00f1o fijo. Si un cliente nvmem usa un tama\u00f1o de b\u00fafer menor a 4 bytes, regmap_read escribir\u00e1 fuera de los l\u00edmites ya que espera que el b\u00fafer apunte a una int sin signo. Corrija esto usando una int sin signo intermedia para contener el valor."
}
],
"id": "CVE-2024-58069",
"lastModified": "2026-06-17T08:14:33.710",
"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"
},
{
"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": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2024-58069",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-10-01T19:27:38.670709Z",
"version": "2.0.3"
}
}
]
},
"published": "2025-03-06T16:15:53.373",
"references": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/517aedb365f2c94e2d7e0b908ac7127df76203a1"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/9adefa7b9559d0f21034a5d5ec1b55840c9348b9"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e5536677da803ed54a29a446515c28dce7d3d574"
},
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"tags": [
"Patch"
],
"url": "https://git.kernel.org/stable/c/e5e06455760f2995b16a176033909347929d1128"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
},
{
"source": "af854a3a-2127-422b-91ae-364da2661108",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"vulnStatus": "Modified",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-787"
}
],
"source": "nvd@nist.gov",
"type": "Primary"
},
{
"description": [
{
"lang": "en",
"value": "CWE-787"
}
],
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"type": "Secondary"
}
]
}
GHSA-P7J9-4392-6R7P
Vulnerability from github – Published: 2025-03-06 18:31 – Updated: 2025-11-03 21:33In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int.
Fix this by using an intermediary unsigned int to hold the value.
{
"affected": [],
"aliases": [
"CVE-2024-58069"
],
"database_specific": {
"cwe_ids": [
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-06T16:15:53Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value.",
"id": "GHSA-p7j9-4392-6r7p",
"modified": "2025-11-03T21:33:08Z",
"published": "2025-03-06T18:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58069"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/517aedb365f2c94e2d7e0b908ac7127df76203a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9adefa7b9559d0f21034a5d5ec1b55840c9348b9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5536677da803ed54a29a446515c28dce7d3d574"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e5e06455760f2995b16a176033909347929d1128"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.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"
}
]
}
MSRC_CVE-2024-58069
Vulnerability from csaf_microsoft - Published: 2025-03-02 00:00 - Updated: 2026-02-18 01:20OESA-2025-1320 (CVE-2024-36476)
Vulnerability from osv_openeuler – Published: 2025-03-21 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs: Ensure 'ib_sge list' is accessible
Move the declaration of the 'ib_sge list' variable outside the 'always_invalidate' block to ensure it remains accessible for use throughout the function.
Previously, 'ib_sge list' was declared within the 'always_invalidate' block, limiting its accessibility, then caused a 'BUG: kernel NULL pointer dereference'[1]. ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2d0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? memcpy_orig+0xd5/0x140 rxe_mr_copy+0x1c3/0x200 [rdma_rxe] ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe] copy_data+0xa5/0x230 [rdma_rxe] rxe_requester+0xd9b/0xf70 [rdma_rxe] ? finish_task_switch.isra.0+0x99/0x2e0 rxe_sender+0x13/0x40 [rdma_rxe] do_task+0x68/0x1e0 [rdma_rxe] process_one_work+0x177/0x330 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10
This change ensures the variable is available for subsequent operations that require it.
[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/(CVE-2024-36476)
In the Linux kernel, the following vulnerability has been resolved:
drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check
The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure.(CVE-2024-56778)
In the Linux kernel, the following vulnerability has been resolved:
netrom: check buffer length before accessing it
Syzkaller reports an uninit value read from ax25cmp when sending raw message through ieee802154 implementation.
===================================================== BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601 nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774 nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2584 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [inline] raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2584 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 =====================================================
This issue occurs because the skb buffer is too small, and it's actual allocation is aligned. This hides an actual issue, which is that nr_route_frame does not validate the buffer size before using it.
Fix this issue by checking skb->len before accessing any fields in skb->data.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-57802)
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread
syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]
If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread().
Adjust the timing of streaming initialization and check it before stopping it.
[1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-57834)
In the Linux kernel, the following vulnerability has been resolved:
mm: hugetlb: independent PMD page table shared count
The folio refcount may be increased unexpectly through try_get_folio() by caller such as split_huge_pages. In huge_pmd_unshare(), we use refcount to check whether a pmd page table is shared. The check is incorrect if the refcount is increased by the above caller, and this can cause the page table leaked:
BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198
The issue may be triggered by damon, offline_page, page_idle, etc, which will increase the refcount of page table.
-
The page table itself will be discarded after reporting the "nonzero mapcount".
-
The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped.
Fix it by introducing independent PMD page table shared count. As described by comment, pt_index/pt_mm/pt_frag_refcount are used for s390 gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv pmds, so we can reuse the field as pt_share_count.(CVE-2024-57883)
In the Linux kernel, the following vulnerability has been resolved:
mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()
The task sometimes continues looping in throttle_direct_reclaim() because allow_direct_reclaim(pgdat) keeps returning false.
#0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4
At this point, the pgdat contains the following two zones:
NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32"
SIZE: 20480 MIN/LOW/HIGH: 11/28/45
VM_STAT:
NR_FREE_PAGES: 359
NR_ZONE_INACTIVE_ANON: 18813
NR_ZONE_ACTIVE_ANON: 0
NR_ZONE_INACTIVE_FILE: 50
NR_ZONE_ACTIVE_FILE: 0
NR_ZONE_UNEVICTABLE: 0
NR_ZONE_WRITE_PENDING: 0
NR_MLOCK: 0
NR_BOUNCE: 0
NR_ZSPAGES: 0
NR_FREE_CMA_PAGES: 0
NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal"
SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264
VM_STAT:
NR_FREE_PAGES: 146
NR_ZONE_INACTIVE_ANON: 94668
NR_ZONE_ACTIVE_ANON: 3
NR_ZONE_INACTIVE_FILE: 735
NR_ZONE_ACTIVE_FILE: 78
NR_ZONE_UNEVICTABLE: 0
NR_ZONE_WRITE_PENDING: 0
NR_MLOCK: 0
NR_BOUNCE: 0
NR_ZSPAGES: 0
NR_FREE_CMA_PAGES: 0
In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of inactive/active file-backed pages calculated in zone_reclaimable_pages() based on the result of zone_page_state_snapshot() is zero.
Additionally, since this system lacks swap, the calculation of inactive/ active anonymous pages is skipped.
crash> p nr_swap_pages
nr_swap_pages = $1937 = {
counter = 0
}
As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having free pages significantly exceeding the high watermark.
The problem is that the pgdat->kswapd_failures hasn't been incremented.
crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures
$1935 = 0x0
This is because the node deemed balanced. The node balancing logic in balance_pgdat() evaluates all zones collectively. If one or more zones (e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the entire node is deemed balanced. This causes balance_pgdat() to exit early before incrementing the kswapd_failures, as it considers the overall memory state acceptable, even though some zones (like ZONE_NORMAL) remain under significant pressure.
The patch ensures that zone_reclaimable_pages() includes free pages (NR_FREE_PAGES) in its calculation when no other reclaimable pages are available (e.g., file-backed or anonymous pages). This change prevents zones like ZONE_DMA32, which have sufficient free pages, from being mistakenly deemed unreclaimable. By doing so, the patch ensures proper node balancing, avoids masking pressure on other zones like ZONE_NORMAL, and prevents infinite loops in throttle_direct_reclaim() caused by allow_direct_reclaim(pgdat) repeatedly returning false.
The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused by a node being incorrectly deemed balanced despite pressure in certain zones, such as ZONE_NORMAL. This issue arises from zone_reclaimable_pages ---truncated---(CVE-2024-57884)
In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: fix sleeping function called from invalid context at print message
Address a bug in the kernel that triggers a "sleeping function called from invalid context" warning when /sys/kernel/debug/kmemleak is printed under specific conditions: - CONFIG_PREEMPT_RT=y - Set SELinux as the LSM for the system - Set kptr_restrict to 1 - kmemleak buffer contains at least one item
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 136, name: cat preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 2 6 locks held by cat/136: #0: ffff32e64bcbf950 (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0xb8/0xe30 #1: ffffafe6aaa9dea0 (scan_mutex){+.+.}-{3:3}, at: kmemleak_seq_start+0x34/0x128 #3: ffff32e6546b1cd0 (&object->lock){....}-{2:2}, at: kmemleak_seq_show+0x3c/0x1e0 #4: ffffafe6aa8d8560 (rcu_read_lock){....}-{1:2}, at: has_ns_capability_noaudit+0x8/0x1b0 #5: ffffafe6aabbc0f8 (notif_lock){+.+.}-{2:2}, at: avc_compute_av+0xc4/0x3d0 irq event stamp: 136660 hardirqs last enabled at (136659): [<ffffafe6a80fd7a0>] _raw_spin_unlock_irqrestore+0xa8/0xd8 hardirqs last disabled at (136660): [<ffffafe6a80fd85c>] _raw_spin_lock_irqsave+0x8c/0xb0 softirqs last enabled at (0): [<ffffafe6a5d50b28>] copy_process+0x11d8/0x3df8 softirqs last disabled at (0): [<0000000000000000>] 0x0 Preemption disabled at: [<ffffafe6a6598a4c>] kmemleak_seq_show+0x3c/0x1e0 CPU: 1 UID: 0 PID: 136 Comm: cat Tainted: G E 6.11.0-rt7+ #34 Tainted: [E]=UNSIGNED_MODULE Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0xa0/0x128 show_stack+0x1c/0x30 dump_stack_lvl+0xe8/0x198 dump_stack+0x18/0x20 rt_spin_lock+0x8c/0x1a8 avc_perm_nonode+0xa0/0x150 cred_has_capability.isra.0+0x118/0x218 selinux_capable+0x50/0x80 security_capable+0x7c/0xd0 has_ns_capability_noaudit+0x94/0x1b0 has_capability_noaudit+0x20/0x30 restricted_pointer+0x21c/0x4b0 pointer+0x298/0x760 vsnprintf+0x330/0xf70 seq_printf+0x178/0x218 print_unreferenced+0x1a4/0x2d0 kmemleak_seq_show+0xd0/0x1e0 seq_read_iter+0x354/0xe30 seq_read+0x250/0x378 full_proxy_read+0xd8/0x148 vfs_read+0x190/0x918 ksys_read+0xf0/0x1e0 __arm64_sys_read+0x70/0xa8 invoke_syscall.constprop.0+0xd4/0x1d8 el0_svc+0x50/0x158 el0t_64_sync+0x17c/0x180
%pS and %pK, in the same back trace line, are redundant, and %pS can void %pK service in certain contexts.
%pS alone already provides the necessary information, and if it cannot resolve the symbol, it falls back to printing the raw address voiding the original intent behind the %pK.
Additionally, %pK requires a privilege check CAP_SYSLOG enforced through the LSM, which can trigger a "sleeping function called from invalid context" warning under RT_PREEMPT kernels when the check occurs in an atomic context. This issue may also affect other LSMs.
This change avoids the unnecessary privilege check and resolves the sleeping function warning without any loss of information.(CVE-2024-57885)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/uverbs: Prevent integer overflow issue
In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32 values that come from the user so the multiplication can lead to integer wrapping. Then we pass the result to uverbs_request_next_ptr() which also could potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)" multiplication can also overflow on 32bit systems although it's fine on 64bit systems.
This patch does two things. First, I've re-arranged the condition in uverbs_request_next_ptr() so that the use controlled variable "len" is on one side of the comparison by itself without any math. Then I've modified all the callers to use size_mul() for the multiplications.(CVE-2024-57890)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix sleeping function called from invalid context
This reworks hci_cb_list to not use mutex hci_cb_list_lock to avoid bugs like the bellow:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5070, name: kworker/u9:2 preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 4 locks held by kworker/u9:2/5070: #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline] #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x1770 kernel/workqueue.c:3335 #1: ffffc90003b6fd00 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline] #1: ffffc90003b6fd00 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x1770 kernel/workqueue.c:3335 #2: ffff8880665d0078 (&hdev->lock){+.+.}-{3:3}, at: hci_le_create_big_complete_evt+0xcf/0xae0 net/bluetooth/hci_event.c:6914 #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline] #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline] #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: hci_le_create_big_complete_evt+0xdb/0xae0 net/bluetooth/hci_event.c:6915 CPU: 0 PID: 5070 Comm: kworker/u9:2 Not tainted 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 __might_resched+0x5d4/0x780 kernel/sched/core.c:10187 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0xc1/0xd70 kernel/locking/mutex.c:752 hci_connect_cfm include/net/bluetooth/hci_core.h:2004 [inline] hci_le_create_big_complete_evt+0x3d9/0xae0 net/bluetooth/hci_event.c:6939 hci_event_func net/bluetooth/hci_event.c:7514 [inline] hci_event_packet+0xa53/0x1540 net/bluetooth/hci_event.c:7569 hci_rx_work+0x3e8/0xca0 net/bluetooth/hci_core.c:4171 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa00/0x1770 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f0/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK>(CVE-2024-57894)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Correct the migration DMA map direction
The SVM DMA device map direction should be set the same as the DMA unmap setting, otherwise the DMA core will report the following warning.
Before finialize this solution, there're some discussion on the DMA mapping type(stream-based or coherent) in this KFD migration case, followed by https://lore.kernel.org/all/04d4ab32 -45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/.
As there's no dma_sync_single_for_*() in the DMA buffer accessed that because this migration operation should be sync properly and automatically. Give that there's might not be a performance problem in various cache sync policy of DMA sync. Therefore, in order to simplify the DMA direction setting alignment, let's set the DMA map direction as BIDIRECTIONAL.
[ 150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930 [ 150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds [ 150.834310] wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G OE 6.10.0-custom #492 [ 150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 150.834360] RIP: 0010:check_unmap+0x1cc/0x930 [ 150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff <0f> 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50 [ 150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086 [ 150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027 [ 150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680 [ 150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850 [ 150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40 [ 150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b [ 150.834377] FS: 00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000 [ 150.834379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0 [ 150.834383] Call Trace: [ 150.834385] <TASK> [ 150.834387] ? show_regs+0x6d/0x80 [ 150.834393] ? __warn+0x8c/0x140 [ 150.834397] ? check_unmap+0x1cc/0x930 [ 150.834400] ? report_bug+0x193/0x1a0 [ 150.834406] ? handle_bug+0x46/0x80 [ 150.834410] ? exc_invalid_op+0x1d/0x80 [ 150.834413] ? asm_exc_invalid_op+0x1f/0x30 [ 150.834420] ? check_unmap+0x1cc/0x930 [ 150.834425] debug_dma_unmap_page+0x86/0x90 [ 150.834431] ? srso_return_thunk+0x5/0x5f [ 150.834435] ---truncated---(CVE-2024-57897)
In the Linux kernel, the following vulnerability has been resolved:
af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK
Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot.
Rework vlan_get_protocol_dgram() to not touch skb at all, so that it can be used from many cpus on the same skb.
Add a const qualifier to skb argument.
[1] skbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900038d7638 EFLAGS: 00010282 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60 R10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140 R13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011 FS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585 packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1055 _sysrecvmsg+0x1c6/0x480 net/socket.c:2803 _sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2940 __sys_recvmmsg net/socket.c:3014 [inline] __do_sys_recvmmsg net/socket.c:3037 [inline] __se_sys_recvmmsg net/socket.c:3030 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030 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(CVE-2024-57901)
In the Linux kernel, the following vulnerability has been resolved:
af_packet: fix vlan_get_tci() vs MSG_PEEK
Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot.
Rework vlan_get_tci() to not touch skb at all, so that it can be used from many cpus on the same skb.
Add a const qualifier to skb argument.
[1] skbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 9e 6c 26 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 3a 5a 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50 R10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140 R13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014 FS: 00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565 packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1066 _sysrecvmsg+0x1c6/0x480 net/socket.c:2814 _sys_recvmsg net/socket.c:2856 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2951 __sys_recvmmsg net/socket.c:3025 [inline] __do_sys_recvmmsg net/socket.c:3048 [inline] __se_sys_recvmmsg net/socket.c:3041 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83(CVE-2024-57902)
In the Linux kernel, the following vulnerability has been resolved:
net: restrict SO_REUSEPORT to inet sockets
After blamed commit, crypto sockets could accidentally be destroyed from RCU call back, as spotted by zyzbot [1].
Trying to acquire a mutex in RCU callback is not allowed.
Restrict SO_REUSEPORT socket option to inet sockets.
v1 of this patch supported TCP, UDP and SCTP sockets, but fcnal-test.sh test needed RAW and ICMP support.
[1] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1 preempt_count: 100, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823 Preemption disabled at: [<ffffffff8161c8c8>] softirq_handle_begin kernel/softirq.c:402 [inline] [<ffffffff8161c8c8>] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537 CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>(CVE-2024-57903)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Remove WARN_ON in functionfs_bind
This commit addresses an issue related to below kernel panic where panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON in functionsfs_bind, which easily leads to the following scenarios.
1.adb_write in adbd 2. UDC write via configfs ================= =====================
->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register() ->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() <times-out without BIND event> ->configfs_composite_bind() ->usb_add_function() ->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() <ffs->state !=FFS_ACTIVE>
The adb_open, adb_read, and adb_write operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARN_ON from functionfs_bind when panic_on_warn is enabled. This commit fixes the kernel panic by removing the unnecessary WARN_ON.
Kernel panic - not syncing: kernel: panic_on_warn set ... [ 14.542395] Call trace: [ 14.542464] ffs_func_bind+0x1c8/0x14a8 [ 14.542468] usb_add_function+0xcc/0x1f0 [ 14.542473] configfs_composite_bind+0x468/0x588 [ 14.542478] gadget_bind_driver+0x108/0x27c [ 14.542483] really_probe+0x190/0x374 [ 14.542488] __driver_probe_device+0xa0/0x12c [ 14.542492] driver_probe_device+0x3c/0x220 [ 14.542498] __driver_attach+0x11c/0x1fc [ 14.542502] bus_for_each_dev+0x104/0x160 [ 14.542506] driver_attach+0x24/0x34 [ 14.542510] bus_add_driver+0x154/0x270 [ 14.542514] driver_register+0x68/0x104 [ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4 [ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144 [ 14.542526] configfs_write_iter+0xf0/0x138(CVE-2024-57913)
In the Linux kernel, the following vulnerability has been resolved:
net/sctp: Prevent autoclose integer overflow in sctp_association_init()
While by default max_autoclose equals to INT_MAX / HZ, one may set net.sctp.max_autoclose to UINT_MAX. There is code in sctp_association_init() that can consequently trigger overflow.(CVE-2024-57938)
In the Linux kernel, the following vulnerability has been resolved:
riscv: mm: Fix the out of bound issue of vmemmap address
In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)).
However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page.
For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END.
This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base.(CVE-2024-57945)
In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int.
Fix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: dispcc-sm6350: Add missing parent_map for a clock
If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following:
[ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c
Add the parent_map property for the clock where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together.(CVE-2024-58080)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix racy issue from session lookup and expire
Increment the session reference count within the lock for lookup to avoid racy issue with session expire.(CVE-2024-58087)
In the Linux kernel, the following vulnerability has been resolved:
net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets
The blamed commit disabled hardware offoad of IPv6 packets with extension headers on devices that advertise NETIF_F_IPV6_CSUM, based on the definition of that feature in skbuff.h:
-
-
- %NETIF_F_IPV6_CSUM
-
-
- Driver (device) is only able to checksum plain
- TCP or UDP packets over IPv6. These are specifically
- unencapsulated packets of the form IPv6|TCP or
- IPv6|UDP where the Next Header field in the IPv6
- header is either TCP or UDP. IPv6 extension headers
- are not supported with this feature. This feature
- cannot be set in features for a device with
- NETIF_F_HW_CSUM also set. This feature is being
- DEPRECATED (see below).
The change causes skb_warn_bad_offload to fire for BIG TCP packets.
[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skb_warn_bad_offload+0xc4/0xe0
[ 496.310297] ? skb_warn_bad_offload+0xc4/0xe0 [ 496.310300] skb_checksum_help+0x129/0x1f0 [ 496.310303] skb_csum_hwoffload_help+0x150/0x1b0 [ 496.310306] validate_xmit_skb+0x159/0x270 [ 496.310309] validate_xmit_skb_list+0x41/0x70 [ 496.310312] sch_direct_xmit+0x5c/0x250 [ 496.310317] __qdisc_run+0x388/0x620
BIG TCP introduced an IPV6_TLV_JUMBO IPv6 extension header to communicate packet length, as this is an IPv6 jumbogram. But, the feature is only enabled on devices that support BIG TCP TSO. The header is only present for PF_PACKET taps like tcpdump, and not transmitted by physical devices.
For this specific case of extension headers that are not transmitted, return to the situation before the blamed commit and support hardware offload.
ipv6_has_hopopt_jumbo() tests not only whether this header is present, but also that it is the only extension header before a terminal (L4) header.(CVE-2025-21629)
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: rto_min/max: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:
-
Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.
-
current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using container_of().
Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.(CVE-2025-21639)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: sysctl: sched: avoid using current->nsproxy
Using the 'net' structure via 'current' is not recommended for different reasons.
First, if the goal is to use it to read or write per-netns data, this is inconsistent with how the "generic" sysctl entries are doing: directly by only using pointers set to the table entry, e.g. table->data. Linked to that, the per-netns data should always be obtained from the table linked to the netns it had been created for, which may not coincide with the reader's or writer's netns.
Another reason is that access to current->nsproxy->netns can oops if attempted when current->nsproxy had been dropped when the current task is exiting. This is what syzbot found, when using acct(2):
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00 RSP: 0018:ffffc900034774e8 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620 RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028 RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040 R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000 R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601 __kernel_write_iter+0x318/0xa80 fs/read_write.c:612 __kernel_write+0xf6/0x140 fs/read_write.c:632 do_acct_process+0xcb0/0x14a0 kernel/acct.c:539 acct_pin_kill+0x2d/0x100 kernel/acct.c:192 pin_kill+0x194/0x7c0 fs/fs_pin.c:44 mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81 cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366 task_work_run+0x14e/0x250 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 get_signal+0x2576/0x2610 kernel/signal.c:3017 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fee3cb87a6a Code: Unable to access opcode bytes at 0x7fee3cb87a40. RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037 RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7 R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500 R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ---truncated---(CVE-2025-21642)
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix the maximum cell name length
The kafs filesystem limits the maximum length of a cell to 256 bytes, but a problem occurs if someone actually does that: kafs tries to create a directory under /proc/net/afs/ with the name of the cell, but that fails with a warning:
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405
because procfs limits the maximum filename length to 255.
However, the DNS limits the maximum lookup length and, by extension, the maximum cell name, to 255 less two (length count and trailing NUL).
Fix this by limiting the maximum acceptable cellname length to 253. This also allows us to be sure we can create the "/afs/.<cell>/" mountpoint too.
Further, split the YFS VL record cell name maximum to be the 256 allowed by the protocol and ignore the record retrieved by YFSVL.GetCellName if it exceeds 253.(CVE-2025-21646)
In the Linux kernel, the following vulnerability has been resolved:
ovl: support encoding fid from inode with no alias
Dmitry Safonov reported that a WARN_ON() assertion can be trigered by userspace when calling inotify_show_fdinfo() for an overlayfs watched inode, whose dentry aliases were discarded with drop_caches.
The WARN_ON() assertion in inotify_show_fdinfo() was removed, because it is possible for encoding file handle to fail for other reason, but the impact of failing to encode an overlayfs file handle goes beyond this assertion.
As shown in the LTP test case mentioned in the link below, failure to encode an overlayfs file handle from a non-aliased inode also leads to failure to report an fid with FAN_DELETE_SELF fanotify events.
As Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails if it cannot find an alias for the inode, but this failure can be fixed. ovl_encode_fh() seldom uses the alias and in the case of non-decodable file handles, as is often the case with fanotify fid info, ovl_encode_fh() never needs to use the alias to encode a file handle.
Defer finding an alias until it is actually needed so ovl_encode_fh() will not fail in the common case of FAN_DELETE_SELF fanotify events.(CVE-2025-21654)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period
io_eventfd_do_signal() is invoked from an RCU callback, but when dropping the reference to the io_ev_fd, it calls io_eventfd_free() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the io_ev_fd should be deferred another RCU grace period.
Just call io_eventfd_put() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.(CVE-2025-21655)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked
When ksmbd_vfs_kern_path_locked met an error and it is not the last
entry, it will exit without restoring changed path buffer. But later this
buffer may be used as the filename for creation.(CVE-2025-21660)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix variable not being completed when function returns
When cmd_alloc_index(), fails cmd_work_handler() needs to complete ent->slotted before returning early. Otherwise the task which issued the command may hang:
mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry INFO: task kworker/13:2:4055883 blocked for more than 120 seconds. Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/13:2 D 0 4055883 2 0x00000228 Workqueue: events mlx5e_tx_dim_work [mlx5_core] Call trace: __switch_to+0xe8/0x150 __schedule+0x2a8/0x9b8 schedule+0x2c/0x88 schedule_timeout+0x204/0x478 wait_for_common+0x154/0x250 wait_for_completion+0x28/0x38 cmd_exec+0x7a0/0xa00 [mlx5_core] mlx5_cmd_exec+0x54/0x80 [mlx5_core] mlx5_core_modify_cq+0x6c/0x80 [mlx5_core] mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core] mlx5e_tx_dim_work+0x54/0x68 [mlx5_core] process_one_work+0x1b0/0x448 worker_thread+0x54/0x468 kthread+0x134/0x138 ret_from_fork+0x10/0x18(CVE-2025-21662)
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: dwmac-tegra: Read iommu stream id from device tree
Nvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be written to the MGBE_WRAP_AXI_ASID0_CTRL register.
The current driver is hard coded to use MGBE0's SID for all controllers. This causes softirq time outs and kernel panics when using controllers other than MGBE0.
Example dmesg errors when an ethernet cable is connected to MGBE1:
[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter. [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171) [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported [ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337 [ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8) [ 181.921878] Sending NMI from CPU 4 to CPUs 7: [ 181.921886] NMI backtrace for cpu 7 [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6 [ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024 [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 181.922847] pc : handle_softirqs+0x98/0x368 [ 181.922978] lr : __do_softirq+0x18/0x20 [ 181.923095] sp : ffff80008003bf50 [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000 [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0 [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70 [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000 [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000 [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160 [ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74 [ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1 [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000 [ 181.967591] Call trace: [ 181.970043] handle_softirqs+0x98/0x368 (P) [ 181.974240] __do_softirq+0x18/0x20 [ 181.977743] _dosoftirq+0x14/0x28 [ 181.981415] call_on_irq_stack+0x24/0x30 [ 181.985180] do_softirq_own_stack+0x20/0x30 [ 181.989379] irq_exit_rcu+0x114/0x140 [ 181.993142] irq_exit_rcu+0x14/0x28 [ 181.996816] el1_interrupt+0x44/0xb8 [ 182.000316] el1h_64_irq_handler+0x14/0x20 [ 182.004343] el1h_64_irq+0x80/0x88 [ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P) [ 182.012305] cpuidle_enter+0x3c/0x58 [ 182.015980] cpuidle_idle_call+0x128/0x1c0 [ 182.020005] do_idle+0xe0/0xf0 [ 182.023155] cpu_startup_entry+0x3c/0x48 [ 182.026917] secondary_start_kernel+0xdc/0x120 [ 182.031379] __secondary_switched+0x74/0x78 [ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/. [ 212.985935] rcu: blocking rcu_node structures (internal RCU debug): [ 212.992758] Sending NMI from CPU 0 to CPUs 7: [ 212.998539] NMI backtrace for cpu 7 [ 213.004304] CPU: 7 UID: 0 PI ---truncated---(CVE-2025-21663)
In the Linux kernel, the following vulnerability has been resolved:
dm thin: make get_first_thin use rcu-safe list first function
The documentation in rculist.h explains the absence of list_empty_rcu() and cautions programmers against relying on a list_empty() -> list_first() sequence in RCU safe code. This is because each of these functions performs its own READ_ONCE() of the list head. This can lead to a situation where the list_empty() sees a valid list entry, but the subsequent list_first() sees a different view of list head state after a modification.
In the case of dm-thin, this author had a production box crash from a GP fault in the process_deferred_bios path. This function saw a valid list head in get_first_thin() but when it subsequently dereferenced that and turned it into a thin_c, it got the inside of the struct pool, since the list was now empty and referring to itself. The kernel on which this occurred printed both a warning about a refcount_t being saturated, and a UBSAN error for an out-of-bounds cpuid access in the queued spinlock, prior to the fault itself. When the resulting kdump was examined, it was possible to see another thread patiently waiting in thin_dtr's synchronize_rcu.
The thin_dtr call managed to pull the thin_c out of the active thins list (and have it be the last entry in the active_thins list) at just the wrong moment which lead to this crash.
Fortunately, the fix here is straight forward. Switch get_first_thin() function to use list_first_or_null_rcu() which performs just a single READ_ONCE() and returns NULL if the list is already empty.
This was run against the devicemapper test suite's thin-provisioning suites for delete and suspend and no regressions were observed.(CVE-2025-21664)
In the Linux kernel, the following vulnerability has been resolved:
ipmr: do not call mr_mfc_uses_dev() for unres entries
syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to "struct sk_buff_head unresolved", which contain two pointers.
This code never worked, lets remove it.
[1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708(CVE-2025-21719)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Check the return value of of_property_read_string_index()
Somewhen between 6.10 and 6.11 the driver started to crash on my MacBookPro14,3. The property doesn't exist and 'tmp' remains uninitialized, so we pass a random pointer to devm_kstrdup().
The crash I am getting looks like this:
BUG: unable to handle page fault for address: 00007f033c669379 PF: supervisor read access in kernel mode PF: error_code(0x0001) - permissions violation PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 Oops: Oops: 0001 [#1] SMP PTI CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1 Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024 RIP: 0010:strlen+0x4/0x30 Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 brcmfmac
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"bpftool-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"kernel-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"kernel-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"kernel-debugsource-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"kernel-devel-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"kernel-headers-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"kernel-source-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"kernel-tools-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"kernel-tools-devel-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"perf-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"perf-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"python3-perf-6.6.0-83.0.0.77.oe2403.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-83.0.0.77.oe2403.aarch64.rpm"
],
"src": [
"kernel-6.6.0-83.0.0.77.oe2403.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"bpftool-debuginfo-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"kernel-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"kernel-debuginfo-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"kernel-debugsource-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"kernel-devel-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"kernel-headers-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"kernel-source-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"kernel-tools-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"kernel-tools-devel-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"perf-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"perf-debuginfo-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"python3-perf-6.6.0-83.0.0.77.oe2403.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-83.0.0.77.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-83.0.0.77.oe2403"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\n\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rtrs: Ensure \u0026apos;ib_sge list\u0026apos; is accessible\n\nMove the declaration of the \u0026apos;ib_sge list\u0026apos; variable outside the\n\u0026apos;always_invalidate\u0026apos; block to ensure it remains accessible for use\nthroughout the function.\n\nPreviously, \u0026apos;ib_sge list\u0026apos; was declared within the \u0026apos;always_invalidate\u0026apos;\nblock, limiting its accessibility, then caused a\n\u0026apos;BUG: kernel NULL pointer dereference\u0026apos;[1].\n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2d0\n ? search_module_extables+0x19/0x60\n ? search_bpf_extables+0x5f/0x80\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? memcpy_orig+0xd5/0x140\n rxe_mr_copy+0x1c3/0x200 [rdma_rxe]\n ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe]\n copy_data+0xa5/0x230 [rdma_rxe]\n rxe_requester+0xd9b/0xf70 [rdma_rxe]\n ? finish_task_switch.isra.0+0x99/0x2e0\n rxe_sender+0x13/0x40 [rdma_rxe]\n do_task+0x68/0x1e0 [rdma_rxe]\n process_one_work+0x177/0x330\n worker_thread+0x252/0x390\n ? __pfx_worker_thread+0x10/0x10\n\nThis change ensures the variable is available for subsequent operations\nthat require it.\n\n[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/(CVE-2024-36476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check\n\nThe return value of drm_atomic_get_crtc_state() needs to be\nchecked. To avoid use of error pointer \u0026apos;crtc_state\u0026apos; in case\nof the failure.(CVE-2024-56778)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: check buffer length before accessing it\n\nSyzkaller reports an uninit value read from ax25cmp when sending raw message\nthrough ieee802154 implementation.\n\n=====================================================\nBUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119\n ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119\n nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601\n nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774\n nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299\n ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780\n sock_alloc_send_skb include/net/sock.h:1884 [inline]\n raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282\n ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nCPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\n=====================================================\n\nThis issue occurs because the skb buffer is too small, and it\u0026apos;s actual\nallocation is aligned. This hides an actual issue, which is that nr_route_frame\ndoes not validate the buffer size before using it.\n\nFix this issue by checking skb-\u0026gt;len before accessing any fields in skb-\u0026gt;data.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-57802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread\n\nsyzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]\n\nIf dvb-\u0026gt;mux is not initialized successfully by vidtv_mux_init() in the\nvidtv_start_streaming(), it will trigger null pointer dereference about mux\nin vidtv_mux_stop_thread().\n\nAdjust the timing of streaming initialization and check it before\nstopping it.\n\n[1]\nKASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]\nCPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nRIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471\nCode: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;0f\u0026gt; b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8\nRSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125\nRDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128\nRBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188\nR13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710\nFS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline]\n vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252\n dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000\n dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486\n dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559\n dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]\n dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246\n __fput+0x3f8/0xb60 fs/file_table.c:450\n task_work_run+0x14e/0x250 kernel/task_work.c:239\n get_signal+0x1d3/0x2610 kernel/signal.c:2790\n arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218\n do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-57834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: hugetlb: independent PMD page table shared count\n\nThe folio refcount may be increased unexpectly through try_get_folio() by\ncaller such as split_huge_pages. In huge_pmd_unshare(), we use refcount\nto check whether a pmd page table is shared. The check is incorrect if\nthe refcount is increased by the above caller, and this can cause the page\ntable leaked:\n\n BUG: Bad page state in process sh pfn:109324\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324\n flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff)\n page_type: f2(table)\n raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000\n raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000\n page dumped because: nonzero mapcount\n ...\n CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7\n Tainted: [B]=BAD_PAGE\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n Call trace:\n show_stack+0x20/0x38 (C)\n dump_stack_lvl+0x80/0xf8\n dump_stack+0x18/0x28\n bad_page+0x8c/0x130\n free_page_is_bad_report+0xa4/0xb0\n free_unref_page+0x3cc/0x620\n __folio_put+0xf4/0x158\n split_huge_pages_all+0x1e0/0x3e8\n split_huge_pages_write+0x25c/0x2d8\n full_proxy_write+0x64/0xd8\n vfs_write+0xcc/0x280\n ksys_write+0x70/0x110\n __arm64_sys_write+0x24/0x38\n invoke_syscall+0x50/0x120\n el0_svc_common.constprop.0+0xc8/0xf0\n do_el0_svc+0x24/0x38\n el0_svc+0x34/0x128\n el0t_64_sync_handler+0xc8/0xd0\n el0t_64_sync+0x190/0x198\n\nThe issue may be triggered by damon, offline_page, page_idle, etc, which\nwill increase the refcount of page table.\n\n1. The page table itself will be discarded after reporting the\n \u0026quot;nonzero mapcount\u0026quot;.\n\n2. The HugeTLB page mapped by the page table miss freeing since we\n treat the page table as shared and a shared page table will not be\n unmapped.\n\nFix it by introducing independent PMD page table shared count. As\ndescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390\ngmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv\npmds, so we can reuse the field as pt_share_count.(CVE-2024-57883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()\n\nThe task sometimes continues looping in throttle_direct_reclaim() because\nallow_direct_reclaim(pgdat) keeps returning false. \n\n #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac\n #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c\n #2 [ffff80002cb6f990] schedule at ffff800008abc50c\n #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550\n #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68\n #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660\n #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98\n #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8\n #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974\n #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4\n\nAt this point, the pgdat contains the following two zones:\n\n NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: \u0026quot;DMA32\u0026quot;\n SIZE: 20480 MIN/LOW/HIGH: 11/28/45\n VM_STAT:\n NR_FREE_PAGES: 359\n NR_ZONE_INACTIVE_ANON: 18813\n NR_ZONE_ACTIVE_ANON: 0\n NR_ZONE_INACTIVE_FILE: 50\n NR_ZONE_ACTIVE_FILE: 0\n NR_ZONE_UNEVICTABLE: 0\n NR_ZONE_WRITE_PENDING: 0\n NR_MLOCK: 0\n NR_BOUNCE: 0\n NR_ZSPAGES: 0\n NR_FREE_CMA_PAGES: 0\n\n NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: \u0026quot;Normal\u0026quot;\n SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264\n VM_STAT:\n NR_FREE_PAGES: 146\n NR_ZONE_INACTIVE_ANON: 94668\n NR_ZONE_ACTIVE_ANON: 3\n NR_ZONE_INACTIVE_FILE: 735\n NR_ZONE_ACTIVE_FILE: 78\n NR_ZONE_UNEVICTABLE: 0\n NR_ZONE_WRITE_PENDING: 0\n NR_MLOCK: 0\n NR_BOUNCE: 0\n NR_ZSPAGES: 0\n NR_FREE_CMA_PAGES: 0\n\nIn allow_direct_reclaim(), while processing ZONE_DMA32, the sum of\ninactive/active file-backed pages calculated in zone_reclaimable_pages()\nbased on the result of zone_page_state_snapshot() is zero. \n\nAdditionally, since this system lacks swap, the calculation of inactive/\nactive anonymous pages is skipped.\n\n crash\u0026gt; p nr_swap_pages\n nr_swap_pages = $1937 = {\n counter = 0\n }\n\nAs a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to\nthe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having\nfree pages significantly exceeding the high watermark.\n\nThe problem is that the pgdat-\u0026gt;kswapd_failures hasn\u0026apos;t been incremented.\n\n crash\u0026gt; px ((struct pglist_data *) 0xffff00817fffe540)-\u0026gt;kswapd_failures\n $1935 = 0x0\n\nThis is because the node deemed balanced. The node balancing logic in\nbalance_pgdat() evaluates all zones collectively. If one or more zones\n(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the\nentire node is deemed balanced. This causes balance_pgdat() to exit early\nbefore incrementing the kswapd_failures, as it considers the overall\nmemory state acceptable, even though some zones (like ZONE_NORMAL) remain\nunder significant pressure.\n\n\nThe patch ensures that zone_reclaimable_pages() includes free pages\n(NR_FREE_PAGES) in its calculation when no other reclaimable pages are\navailable (e.g., file-backed or anonymous pages). This change prevents\nzones like ZONE_DMA32, which have sufficient free pages, from being\nmistakenly deemed unreclaimable. By doing so, the patch ensures proper\nnode balancing, avoids masking pressure on other zones like ZONE_NORMAL,\nand prevents infinite loops in throttle_direct_reclaim() caused by\nallow_direct_reclaim(pgdat) repeatedly returning false.\n\n\nThe kernel hangs due to a task stuck in throttle_direct_reclaim(), caused\nby a node being incorrectly deemed balanced despite pressure in certain\nzones, such as ZONE_NORMAL. This issue arises from\nzone_reclaimable_pages\n---truncated---(CVE-2024-57884)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: fix sleeping function called from invalid context at print message\n\nAddress a bug in the kernel that triggers a \u0026quot;sleeping function called from\ninvalid context\u0026quot; warning when /sys/kernel/debug/kmemleak is printed under\nspecific conditions:\n- CONFIG_PREEMPT_RT=y\n- Set SELinux as the LSM for the system\n- Set kptr_restrict to 1\n- kmemleak buffer contains at least one item\n\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 136, name: cat\npreempt_count: 1, expected: 0\nRCU nest depth: 2, expected: 2\n6 locks held by cat/136:\n #0: ffff32e64bcbf950 (\u0026amp;p-\u0026gt;lock){+.+.}-{3:3}, at: seq_read_iter+0xb8/0xe30\n #1: ffffafe6aaa9dea0 (scan_mutex){+.+.}-{3:3}, at: kmemleak_seq_start+0x34/0x128\n #3: ffff32e6546b1cd0 (\u0026amp;object-\u0026gt;lock){....}-{2:2}, at: kmemleak_seq_show+0x3c/0x1e0\n #4: ffffafe6aa8d8560 (rcu_read_lock){....}-{1:2}, at: has_ns_capability_noaudit+0x8/0x1b0\n #5: ffffafe6aabbc0f8 (notif_lock){+.+.}-{2:2}, at: avc_compute_av+0xc4/0x3d0\nirq event stamp: 136660\nhardirqs last enabled at (136659): [\u0026lt;ffffafe6a80fd7a0\u0026gt;] _raw_spin_unlock_irqrestore+0xa8/0xd8\nhardirqs last disabled at (136660): [\u0026lt;ffffafe6a80fd85c\u0026gt;] _raw_spin_lock_irqsave+0x8c/0xb0\nsoftirqs last enabled at (0): [\u0026lt;ffffafe6a5d50b28\u0026gt;] copy_process+0x11d8/0x3df8\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\nPreemption disabled at:\n[\u0026lt;ffffafe6a6598a4c\u0026gt;] kmemleak_seq_show+0x3c/0x1e0\nCPU: 1 UID: 0 PID: 136 Comm: cat Tainted: G E 6.11.0-rt7+ #34\nTainted: [E]=UNSIGNED_MODULE\nHardware name: linux,dummy-virt (DT)\nCall trace:\n dump_backtrace+0xa0/0x128\n show_stack+0x1c/0x30\n dump_stack_lvl+0xe8/0x198\n dump_stack+0x18/0x20\n rt_spin_lock+0x8c/0x1a8\n avc_perm_nonode+0xa0/0x150\n cred_has_capability.isra.0+0x118/0x218\n selinux_capable+0x50/0x80\n security_capable+0x7c/0xd0\n has_ns_capability_noaudit+0x94/0x1b0\n has_capability_noaudit+0x20/0x30\n restricted_pointer+0x21c/0x4b0\n pointer+0x298/0x760\n vsnprintf+0x330/0xf70\n seq_printf+0x178/0x218\n print_unreferenced+0x1a4/0x2d0\n kmemleak_seq_show+0xd0/0x1e0\n seq_read_iter+0x354/0xe30\n seq_read+0x250/0x378\n full_proxy_read+0xd8/0x148\n vfs_read+0x190/0x918\n ksys_read+0xf0/0x1e0\n __arm64_sys_read+0x70/0xa8\n invoke_syscall.constprop.0+0xd4/0x1d8\n el0_svc+0x50/0x158\n el0t_64_sync+0x17c/0x180\n\n%pS and %pK, in the same back trace line, are redundant, and %pS can void\n%pK service in certain contexts.\n\n%pS alone already provides the necessary information, and if it cannot\nresolve the symbol, it falls back to printing the raw address voiding\nthe original intent behind the %pK.\n\nAdditionally, %pK requires a privilege check CAP_SYSLOG enforced through\nthe LSM, which can trigger a \u0026quot;sleeping function called from invalid\ncontext\u0026quot; warning under RT_PREEMPT kernels when the check occurs in an\natomic context. This issue may also affect other LSMs.\n\nThis change avoids the unnecessary privilege check and resolves the\nsleeping function warning without any loss of information.(CVE-2024-57885)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/uverbs: Prevent integer overflow issue\n\nIn the expression \u0026quot;cmd.wqe_size * cmd.wr_count\u0026quot;, both variables are u32\nvalues that come from the user so the multiplication can lead to integer\nwrapping. Then we pass the result to uverbs_request_next_ptr() which also\ncould potentially wrap. The \u0026quot;cmd.sge_count * sizeof(struct ib_uverbs_sge)\u0026quot;\nmultiplication can also overflow on 32bit systems although it\u0026apos;s fine on\n64bit systems.\n\nThis patch does two things. First, I\u0026apos;ve re-arranged the condition in\nuverbs_request_next_ptr() so that the use controlled variable \u0026quot;len\u0026quot; is on\none side of the comparison by itself without any math. Then I\u0026apos;ve modified\nall the callers to use size_mul() for the multiplications.(CVE-2024-57890)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix sleeping function called from invalid context\n\nThis reworks hci_cb_list to not use mutex hci_cb_list_lock to avoid bugs\nlike the bellow:\n\nBUG: sleeping function called from invalid context at kernel/locking/mutex.c:585\nin_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5070, name: kworker/u9:2\npreempt_count: 0, expected: 0\nRCU nest depth: 1, expected: 0\n4 locks held by kworker/u9:2/5070:\n #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline]\n #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x1770 kernel/workqueue.c:3335\n #1: ffffc90003b6fd00 ((work_completion)(\u0026amp;hdev-\u0026gt;rx_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline]\n #1: ffffc90003b6fd00 ((work_completion)(\u0026amp;hdev-\u0026gt;rx_work)){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x1770 kernel/workqueue.c:3335\n #2: ffff8880665d0078 (\u0026amp;hdev-\u0026gt;lock){+.+.}-{3:3}, at: hci_le_create_big_complete_evt+0xcf/0xae0 net/bluetooth/hci_event.c:6914\n #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline]\n #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline]\n #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: hci_le_create_big_complete_evt+0xdb/0xae0 net/bluetooth/hci_event.c:6915\nCPU: 0 PID: 5070 Comm: kworker/u9:2 Not tainted 6.8.0-syzkaller-08073-g480e035fc4c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: hci0 hci_rx_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n __might_resched+0x5d4/0x780 kernel/sched/core.c:10187\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0xc1/0xd70 kernel/locking/mutex.c:752\n hci_connect_cfm include/net/bluetooth/hci_core.h:2004 [inline]\n hci_le_create_big_complete_evt+0x3d9/0xae0 net/bluetooth/hci_event.c:6939\n hci_event_func net/bluetooth/hci_event.c:7514 [inline]\n hci_event_packet+0xa53/0x1540 net/bluetooth/hci_event.c:7569\n hci_rx_work+0x3e8/0xca0 net/bluetooth/hci_core.c:4171\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0xa00/0x1770 kernel/workqueue.c:3335\n worker_thread+0x86d/0xd70 kernel/workqueue.c:3416\n kthread+0x2f0/0x390 kernel/kthread.c:388\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\n \u0026lt;/TASK\u0026gt;(CVE-2024-57894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Correct the migration DMA map direction\n\nThe SVM DMA device map direction should be set the same as\nthe DMA unmap setting, otherwise the DMA core will report\nthe following warning.\n\nBefore finialize this solution, there\u0026apos;re some discussion on\nthe DMA mapping type(stream-based or coherent) in this KFD\nmigration case, followed by https://lore.kernel.org/all/04d4ab32\n-45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/.\n\nAs there\u0026apos;s no dma_sync_single_for_*() in the DMA buffer accessed\nthat because this migration operation should be sync properly and\nautomatically. Give that there\u0026apos;s might not be a performance problem\nin various cache sync policy of DMA sync. Therefore, in order to\nsimplify the DMA direction setting alignment, let\u0026apos;s set the DMA map\ndirection as BIDIRECTIONAL.\n\n[ 150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930\n[ 150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds\n[ 150.834310] wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii\n[ 150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G OE 6.10.0-custom #492\n[ 150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021\n[ 150.834360] RIP: 0010:check_unmap+0x1cc/0x930\n[ 150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff \u0026lt;0f\u0026gt; 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50\n[ 150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086\n[ 150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027\n[ 150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680\n[ 150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850\n[ 150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40\n[ 150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b\n[ 150.834377] FS: 00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000\n[ 150.834379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0\n[ 150.834383] Call Trace:\n[ 150.834385] \u0026lt;TASK\u0026gt;\n[ 150.834387] ? show_regs+0x6d/0x80\n[ 150.834393] ? __warn+0x8c/0x140\n[ 150.834397] ? check_unmap+0x1cc/0x930\n[ 150.834400] ? report_bug+0x193/0x1a0\n[ 150.834406] ? handle_bug+0x46/0x80\n[ 150.834410] ? exc_invalid_op+0x1d/0x80\n[ 150.834413] ? asm_exc_invalid_op+0x1f/0x30\n[ 150.834420] ? check_unmap+0x1cc/0x930\n[ 150.834425] debug_dma_unmap_page+0x86/0x90\n[ 150.834431] ? srso_return_thunk+0x5/0x5f\n[ 150.834435] \n---truncated---(CVE-2024-57897)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK\n\nBlamed commit forgot MSG_PEEK case, allowing a crash [1] as found\nby syzbot.\n\nRework vlan_get_protocol_dgram() to not touch skb at all,\nso that it can be used from many cpus on the same skb.\n\nAdd a const qualifier to skb argument.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:\u0026lt;NULL\u0026gt;\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 \u0026lt;0f\u0026gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc900038d7638 EFLAGS: 00010282\nRAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600\nRDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\nRBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60\nR10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140\nR13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011\nFS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_push+0xe5/0x100 net/core/skbuff.c:2636\n vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585\n packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552\n sock_recvmsg_nosec net/socket.c:1033 [inline]\n sock_recvmsg+0x22f/0x280 net/socket.c:1055\n ____sys_recvmsg+0x1c6/0x480 net/socket.c:2803\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x426/0xab0 net/socket.c:2940\n __sys_recvmmsg net/socket.c:3014 [inline]\n __do_sys_recvmmsg net/socket.c:3037 [inline]\n __se_sys_recvmmsg net/socket.c:3030 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030\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(CVE-2024-57901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: fix vlan_get_tci() vs MSG_PEEK\n\nBlamed commit forgot MSG_PEEK case, allowing a crash [1] as found\nby syzbot.\n\nRework vlan_get_tci() to not touch skb at all,\nso that it can be used from many cpus on the same skb.\n\nAdd a const qualifier to skb argument.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:\u0026lt;NULL\u0026gt;\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 0b 8d 48 c7 c6 9e 6c 26 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 3a 5a 79 f7 48 83 c4 20 90 \u0026lt;0f\u0026gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286\nRAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000\nRDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\nRBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50\nR10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140\nR13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014\nFS: 00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_push+0xe5/0x100 net/core/skbuff.c:2636\n vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565\n packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616\n sock_recvmsg_nosec net/socket.c:1044 [inline]\n sock_recvmsg+0x22f/0x280 net/socket.c:1066\n ____sys_recvmsg+0x1c6/0x480 net/socket.c:2814\n ___sys_recvmsg net/socket.c:2856 [inline]\n do_recvmmsg+0x426/0xab0 net/socket.c:2951\n __sys_recvmmsg net/socket.c:3025 [inline]\n __do_sys_recvmmsg net/socket.c:3048 [inline]\n __se_sys_recvmmsg net/socket.c:3041 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83(CVE-2024-57902)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: restrict SO_REUSEPORT to inet sockets\n\nAfter blamed commit, crypto sockets could accidentally be destroyed\nfrom RCU call back, as spotted by zyzbot [1].\n\nTrying to acquire a mutex in RCU callback is not allowed.\n\nRestrict SO_REUSEPORT socket option to inet sockets.\n\nv1 of this patch supported TCP, UDP and SCTP sockets,\nbut fcnal-test.sh test needed RAW and ICMP support.\n\n[1]\nBUG: sleeping function called from invalid context at kernel/locking/mutex.c:562\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1\npreempt_count: 100, expected: 0\nRCU nest depth: 0, expected: 0\n1 lock held by ksoftirqd/1/24:\n #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline]\n #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline]\n #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823\nPreemption disabled at:\n [\u0026lt;ffffffff8161c8c8\u0026gt;] softirq_handle_begin kernel/softirq.c:402 [inline]\n [\u0026lt;ffffffff8161c8c8\u0026gt;] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537\nCPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n __might_resched+0x5d4/0x780 kernel/sched/core.c:8758\n __mutex_lock_common kernel/locking/mutex.c:562 [inline]\n __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735\n crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179\n aead_release+0x3d/0x50 crypto/algif_aead.c:489\n alg_do_release crypto/af_alg.c:118 [inline]\n alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502\n __sk_destruct+0x58/0x5f0 net/core/sock.c:2260\n rcu_do_batch kernel/rcu/tree.c:2567 [inline]\n rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823\n handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n run_ksoftirqd+0xca/0x130 kernel/softirq.c:950\n smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;(CVE-2024-57903)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Remove WARN_ON in functionfs_bind\n\nThis commit addresses an issue related to below kernel panic where\npanic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON\nin functionsfs_bind, which easily leads to the following scenarios.\n\n1.adb_write in adbd 2. UDC write via configfs\n =================\t =====================\n\n-\u0026gt;usb_ffs_open_thread() -\u0026gt;UDC write\n -\u0026gt;open_functionfs() -\u0026gt;configfs_write_iter()\n -\u0026gt;adb_open() -\u0026gt;gadget_dev_desc_UDC_store()\n -\u0026gt;adb_write() -\u0026gt;usb_gadget_register_driver_owner\n -\u0026gt;driver_register()\n-\u0026gt;StartMonitor() -\u0026gt;bus_add_driver()\n -\u0026gt;adb_read() -\u0026gt;gadget_bind_driver()\n\u0026lt;times-out without BIND event\u0026gt; -\u0026gt;configfs_composite_bind()\n -\u0026gt;usb_add_function()\n-\u0026gt;open_functionfs() -\u0026gt;ffs_func_bind()\n -\u0026gt;adb_open() -\u0026gt;functionfs_bind()\n \u0026lt;ffs-\u0026gt;state !=FFS_ACTIVE\u0026gt;\n\nThe adb_open, adb_read, and adb_write operations are invoked from the\ndaemon, but trying to bind the function is a process that is invoked by\nUDC write through configfs, which opens up the possibility of a race\ncondition between the two paths. In this race scenario, the kernel panic\noccurs due to the WARN_ON from functionfs_bind when panic_on_warn is\nenabled. This commit fixes the kernel panic by removing the unnecessary\nWARN_ON.\n\nKernel panic - not syncing: kernel: panic_on_warn set ...\n[ 14.542395] Call trace:\n[ 14.542464] ffs_func_bind+0x1c8/0x14a8\n[ 14.542468] usb_add_function+0xcc/0x1f0\n[ 14.542473] configfs_composite_bind+0x468/0x588\n[ 14.542478] gadget_bind_driver+0x108/0x27c\n[ 14.542483] really_probe+0x190/0x374\n[ 14.542488] __driver_probe_device+0xa0/0x12c\n[ 14.542492] driver_probe_device+0x3c/0x220\n[ 14.542498] __driver_attach+0x11c/0x1fc\n[ 14.542502] bus_for_each_dev+0x104/0x160\n[ 14.542506] driver_attach+0x24/0x34\n[ 14.542510] bus_add_driver+0x154/0x270\n[ 14.542514] driver_register+0x68/0x104\n[ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4\n[ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144\n[ 14.542526] configfs_write_iter+0xf0/0x138(CVE-2024-57913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sctp: Prevent autoclose integer overflow in sctp_association_init()\n\nWhile by default max_autoclose equals to INT_MAX / HZ, one may set\nnet.sctp.max_autoclose to UINT_MAX. There is code in\nsctp_association_init() that can consequently trigger overflow.(CVE-2024-57938)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: mm: Fix the out of bound issue of vmemmap address\n\nIn sparse vmemmap model, the virtual address of vmemmap is calculated as:\n((struct page *)VMEMMAP_START - (phys_ram_base \u0026gt;\u0026gt; PAGE_SHIFT)).\nAnd the struct page\u0026apos;s va can be calculated with an offset:\n(vmemmap + (pfn)).\n\nHowever, when initializing struct pages, kernel actually starts from the\nfirst page from the same section that phys_ram_base belongs to. If the\nfirst page\u0026apos;s physical address is not (phys_ram_base \u0026gt;\u0026gt; PAGE_SHIFT), then\nwe get an va below VMEMMAP_START when calculating va for it\u0026apos;s struct page.\n\nFor example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the\nfirst page in the same section is actually pfn 0x80000. During\ninit_unavailable_range(), we will initialize struct page for pfn 0x80000\nwith virtual address ((struct page *)VMEMMAP_START - 0x2000), which is\nbelow VMEMMAP_START as well as PCI_IO_END.\n\nThis commit fixes this bug by introducing a new variable\n\u0026apos;vmemmap_start_pfn\u0026apos; which is aligned with memory section size and using\nit to calculate vmemmap address instead of phys_ram_base.(CVE-2024-57945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: dispcc-sm6350: Add missing parent_map for a clock\n\nIf a clk_rcg2 has a parent, it should also have parent_map defined,\notherwise we\u0026apos;ll get a NULL pointer dereference when calling clk_set_rate\nlike the following:\n\n [ 3.388105] Call trace:\n [ 3.390664] qcom_find_src_index+0x3c/0x70 (P)\n [ 3.395301] qcom_find_src_index+0x1c/0x70 (L)\n [ 3.399934] _freq_tbl_determine_rate+0x48/0x100\n [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28\n [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4\n [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc\n [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc\n [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300\n [ 3.455886] clk_set_rate+0x38/0x14c\n\nAdd the parent_map property for the clock where it\u0026apos;s missing and also\nun-inline the parent_data as well to keep the matching parent_map and\nparent_data together.(CVE-2024-58080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix racy issue from session lookup and expire\n\nIncrement the session reference count within the lock for lookup to avoid\nracy issue with session expire.(CVE-2024-58087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets\n\nThe blamed commit disabled hardware offoad of IPv6 packets with\nextension headers on devices that advertise NETIF_F_IPV6_CSUM,\nbased on the definition of that feature in skbuff.h:\n\n * * - %NETIF_F_IPV6_CSUM\n * - Driver (device) is only able to checksum plain\n * TCP or UDP packets over IPv6. These are specifically\n * unencapsulated packets of the form IPv6|TCP or\n * IPv6|UDP where the Next Header field in the IPv6\n * header is either TCP or UDP. IPv6 extension headers\n * are not supported with this feature. This feature\n * cannot be set in features for a device with\n * NETIF_F_HW_CSUM also set. This feature is being\n * DEPRECATED (see below).\n\nThe change causes skb_warn_bad_offload to fire for BIG TCP\npackets.\n\n[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skb_warn_bad_offload+0xc4/0xe0\n\n[ 496.310297] ? skb_warn_bad_offload+0xc4/0xe0\n[ 496.310300] skb_checksum_help+0x129/0x1f0\n[ 496.310303] skb_csum_hwoffload_help+0x150/0x1b0\n[ 496.310306] validate_xmit_skb+0x159/0x270\n[ 496.310309] validate_xmit_skb_list+0x41/0x70\n[ 496.310312] sch_direct_xmit+0x5c/0x250\n[ 496.310317] __qdisc_run+0x388/0x620\n\nBIG TCP introduced an IPV6_TLV_JUMBO IPv6 extension header to\ncommunicate packet length, as this is an IPv6 jumbogram. But, the\nfeature is only enabled on devices that support BIG TCP TSO. The\nheader is only present for PF_PACKET taps like tcpdump, and not\ntransmitted by physical devices.\n\nFor this specific case of extension headers that are not\ntransmitted, return to the situation before the blamed commit\nand support hardware offload.\n\nipv6_has_hopopt_jumbo() tests not only whether this header is present,\nbut also that it is the only extension header before a terminal (L4)\nheader.(CVE-2025-21629)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: sysctl: rto_min/max: avoid using current-\u0026gt;nsproxy\n\nAs mentioned in a previous commit of this series, using the \u0026apos;net\u0026apos;\nstructure via \u0026apos;current\u0026apos; is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader\u0026apos;s/writer\u0026apos;s netns vs only\n from the opener\u0026apos;s netns.\n\n- current-\u0026gt;nsproxy can be NULL in some cases, resulting in an \u0026apos;Oops\u0026apos;\n (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n syzbot [1] using acct(2).\n\nThe \u0026apos;net\u0026apos; structure can be obtained from the table-\u0026gt;data using\ncontainer_of().\n\nNote that table-\u0026gt;data could also be used directly, as this is the only\nmember needed from the \u0026apos;net\u0026apos; structure, but that would increase the size\nof this fix, to use \u0026apos;*data\u0026apos; everywhere \u0026apos;net-\u0026gt;sctp.rto_min/max\u0026apos; is used.(CVE-2025-21639)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: sysctl: sched: avoid using current-\u0026gt;nsproxy\n\nUsing the \u0026apos;net\u0026apos; structure via \u0026apos;current\u0026apos; is not recommended for different\nreasons.\n\nFirst, if the goal is to use it to read or write per-netns data, this is\ninconsistent with how the \u0026quot;generic\u0026quot; sysctl entries are doing: directly\nby only using pointers set to the table entry, e.g. table-\u0026gt;data. Linked\nto that, the per-netns data should always be obtained from the table\nlinked to the netns it had been created for, which may not coincide with\nthe reader\u0026apos;s or writer\u0026apos;s netns.\n\nAnother reason is that access to current-\u0026gt;nsproxy-\u0026gt;netns can oops if\nattempted when current-\u0026gt;nsproxy had been dropped when the current task\nis exiting. This is what syzbot found, when using acct(2):\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125\n Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00\n RSP: 0018:ffffc900034774e8 EFLAGS: 00010206\n\n RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620\n RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028\n RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040\n R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000\n R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000\n FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601\n __kernel_write_iter+0x318/0xa80 fs/read_write.c:612\n __kernel_write+0xf6/0x140 fs/read_write.c:632\n do_acct_process+0xcb0/0x14a0 kernel/acct.c:539\n acct_pin_kill+0x2d/0x100 kernel/acct.c:192\n pin_kill+0x194/0x7c0 fs/fs_pin.c:44\n mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81\n cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366\n task_work_run+0x14e/0x250 kernel/task_work.c:239\n exit_task_work include/linux/task_work.h:43 [inline]\n do_exit+0xad8/0x2d70 kernel/exit.c:938\n do_group_exit+0xd3/0x2a0 kernel/exit.c:1087\n get_signal+0x2576/0x2610 kernel/signal.c:3017\n arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218\n do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7fee3cb87a6a\n Code: Unable to access opcode bytes at 0x7fee3cb87a40.\n RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037\n RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a\n RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003\n RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7\n R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500\n R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000\n \u0026lt;/TASK\u0026gt;\n Modules linked in:\n ---[ end trace 0000000000000000 ]---\n RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125\n Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc\n---truncated---(CVE-2025-21642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix the maximum cell name length\n\nThe kafs filesystem limits the maximum length of a cell to 256 bytes, but a\nproblem occurs if someone actually does that: kafs tries to create a\ndirectory under /proc/net/afs/ with the name of the cell, but that fails\nwith a warning:\n\n WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405\n\nbecause procfs limits the maximum filename length to 255.\n\nHowever, the DNS limits the maximum lookup length and, by extension, the\nmaximum cell name, to 255 less two (length count and trailing NUL).\n\nFix this by limiting the maximum acceptable cellname length to 253. This\nalso allows us to be sure we can create the \u0026quot;/afs/.\u0026lt;cell\u0026gt;/\u0026quot; mountpoint too.\n\nFurther, split the YFS VL record cell name maximum to be the 256 allowed by\nthe protocol and ignore the record retrieved by YFSVL.GetCellName if it\nexceeds 253.(CVE-2025-21646)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: support encoding fid from inode with no alias\n\nDmitry Safonov reported that a WARN_ON() assertion can be trigered by\nuserspace when calling inotify_show_fdinfo() for an overlayfs watched\ninode, whose dentry aliases were discarded with drop_caches.\n\nThe WARN_ON() assertion in inotify_show_fdinfo() was removed, because\nit is possible for encoding file handle to fail for other reason, but\nthe impact of failing to encode an overlayfs file handle goes beyond\nthis assertion.\n\nAs shown in the LTP test case mentioned in the link below, failure to\nencode an overlayfs file handle from a non-aliased inode also leads to\nfailure to report an fid with FAN_DELETE_SELF fanotify events.\n\nAs Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails\nif it cannot find an alias for the inode, but this failure can be fixed.\novl_encode_fh() seldom uses the alias and in the case of non-decodable\nfile handles, as is often the case with fanotify fid info,\novl_encode_fh() never needs to use the alias to encode a file handle.\n\nDefer finding an alias until it is actually needed so ovl_encode_fh()\nwill not fail in the common case of FAN_DELETE_SELF fanotify events.(CVE-2025-21654)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/eventfd: ensure io_eventfd_signal() defers another RCU period\n\nio_eventfd_do_signal() is invoked from an RCU callback, but when\ndropping the reference to the io_ev_fd, it calls io_eventfd_free()\ndirectly if the refcount drops to zero. This isn\u0026apos;t correct, as any\npotential freeing of the io_ev_fd should be deferred another RCU grace\nperiod.\n\nJust call io_eventfd_put() rather than open-code the dec-and-test and\nfree, which will correctly defer it another RCU grace period.(CVE-2025-21655)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked\n\nWhen `ksmbd_vfs_kern_path_locked` met an error and it is not the last\nentry, it will exit without restoring changed path buffer. But later this\nbuffer may be used as the filename for creation.(CVE-2025-21660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix variable not being completed when function returns\n\nWhen cmd_alloc_index(), fails cmd_work_handler() needs\nto complete ent-\u0026gt;slotted before returning early.\nOtherwise the task which issued the command may hang:\n\n mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry\n INFO: task kworker/13:2:4055883 blocked for more than 120 seconds.\n Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n kworker/13:2 D 0 4055883 2 0x00000228\n Workqueue: events mlx5e_tx_dim_work [mlx5_core]\n Call trace:\n __switch_to+0xe8/0x150\n __schedule+0x2a8/0x9b8\n schedule+0x2c/0x88\n schedule_timeout+0x204/0x478\n wait_for_common+0x154/0x250\n wait_for_completion+0x28/0x38\n cmd_exec+0x7a0/0xa00 [mlx5_core]\n mlx5_cmd_exec+0x54/0x80 [mlx5_core]\n mlx5_core_modify_cq+0x6c/0x80 [mlx5_core]\n mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core]\n mlx5e_tx_dim_work+0x54/0x68 [mlx5_core]\n process_one_work+0x1b0/0x448\n worker_thread+0x54/0x468\n kthread+0x134/0x138\n ret_from_fork+0x10/0x18(CVE-2025-21662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: dwmac-tegra: Read iommu stream id from device tree\n\nNvidia\u0026apos;s Tegra MGBE controllers require the IOMMU \u0026quot;Stream ID\u0026quot; (SID) to be\nwritten to the MGBE_WRAP_AXI_ASID0_CTRL register.\n\nThe current driver is hard coded to use MGBE0\u0026apos;s SID for all controllers.\nThis causes softirq time outs and kernel panics when using controllers\nother than MGBE0.\n\nExample dmesg errors when an ethernet cable is connected to MGBE1:\n\n[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms\n[ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.\n[ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0\n[ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)\n[ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features\n[ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported\n[ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock\n[ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode\n[ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n[ 181.921404] rcu: \t7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337\n[ 181.921684] rcu: \t(detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)\n[ 181.921878] Sending NMI from CPU 4 to CPUs 7:\n[ 181.921886] NMI backtrace for cpu 7\n[ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6\n[ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024\n[ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 181.922847] pc : handle_softirqs+0x98/0x368\n[ 181.922978] lr : __do_softirq+0x18/0x20\n[ 181.923095] sp : ffff80008003bf50\n[ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000\n[ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0\n[ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70\n[ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000\n[ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000\n[ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d\n[ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160\n[ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74\n[ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1\n[ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000\n[ 181.967591] Call trace:\n[ 181.970043] handle_softirqs+0x98/0x368 (P)\n[ 181.974240] __do_softirq+0x18/0x20\n[ 181.977743] ____do_softirq+0x14/0x28\n[ 181.981415] call_on_irq_stack+0x24/0x30\n[ 181.985180] do_softirq_own_stack+0x20/0x30\n[ 181.989379] __irq_exit_rcu+0x114/0x140\n[ 181.993142] irq_exit_rcu+0x14/0x28\n[ 181.996816] el1_interrupt+0x44/0xb8\n[ 182.000316] el1h_64_irq_handler+0x14/0x20\n[ 182.004343] el1h_64_irq+0x80/0x88\n[ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P)\n[ 182.012305] cpuidle_enter+0x3c/0x58\n[ 182.015980] cpuidle_idle_call+0x128/0x1c0\n[ 182.020005] do_idle+0xe0/0xf0\n[ 182.023155] cpu_startup_entry+0x3c/0x48\n[ 182.026917] secondary_start_kernel+0xdc/0x120\n[ 182.031379] __secondary_switched+0x74/0x78\n[ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.\n[ 212.985935] rcu: blocking rcu_node structures (internal RCU debug):\n[ 212.992758] Sending NMI from CPU 0 to CPUs 7:\n[ 212.998539] NMI backtrace for cpu 7\n[ 213.004304] CPU: 7 UID: 0 PI\n---truncated---(CVE-2025-21663)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: make get_first_thin use rcu-safe list first function\n\nThe documentation in rculist.h explains the absence of list_empty_rcu()\nand cautions programmers against relying on a list_empty() -\u0026gt;\nlist_first() sequence in RCU safe code. This is because each of these\nfunctions performs its own READ_ONCE() of the list head. This can lead\nto a situation where the list_empty() sees a valid list entry, but the\nsubsequent list_first() sees a different view of list head state after a\nmodification.\n\nIn the case of dm-thin, this author had a production box crash from a GP\nfault in the process_deferred_bios path. This function saw a valid list\nhead in get_first_thin() but when it subsequently dereferenced that and\nturned it into a thin_c, it got the inside of the struct pool, since the\nlist was now empty and referring to itself. The kernel on which this\noccurred printed both a warning about a refcount_t being saturated, and\na UBSAN error for an out-of-bounds cpuid access in the queued spinlock,\nprior to the fault itself. When the resulting kdump was examined, it\nwas possible to see another thread patiently waiting in thin_dtr\u0026apos;s\nsynchronize_rcu.\n\nThe thin_dtr call managed to pull the thin_c out of the active thins\nlist (and have it be the last entry in the active_thins list) at just\nthe wrong moment which lead to this crash.\n\nFortunately, the fix here is straight forward. Switch get_first_thin()\nfunction to use list_first_or_null_rcu() which performs just a single\nREAD_ONCE() and returns NULL if the list is already empty.\n\nThis was run against the devicemapper test suite\u0026apos;s thin-provisioning\nsuites for delete and suspend and no regressions were observed.(CVE-2025-21664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipmr: do not call mr_mfc_uses_dev() for unres entries\n\nsyzbot found that calling mr_mfc_uses_dev() for unres entries\nwould crash [1], because c-\u0026gt;mfc_un.res.minvif / c-\u0026gt;mfc_un.res.maxvif\nalias to \u0026quot;struct sk_buff_head unresolved\u0026quot;, which contain two pointers.\n\nThis code never worked, lets remove it.\n\n[1]\nUnable to handle kernel paging request at virtual address ffff5fff2d536613\nKASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]\nModules linked in:\nCPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline]\n pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334\n lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline]\n lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334\nCall trace:\n mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P)\n mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P)\n mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382\n ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648\n rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327\n rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791\n netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317\n netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973\n sock_recvmsg_nosec net/socket.c:1033 [inline]\n sock_recvmsg net/socket.c:1055 [inline]\n sock_read_iter+0x2d8/0x40c net/socket.c:1125\n new_sync_read fs/read_write.c:484 [inline]\n vfs_read+0x740/0x970 fs/read_write.c:565\n ksys_read+0x15c/0x26c fs/read_write.c:708(CVE-2025-21719)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Check the return value of of_property_read_string_index()\n\nSomewhen between 6.10 and 6.11 the driver started to crash on my\nMacBookPro14,3. The property doesn\u0026apos;t exist and \u0026apos;tmp\u0026apos; remains\nuninitialized, so we pass a random pointer to devm_kstrdup().\n\nThe crash I am getting looks like this:\n\nBUG: unable to handle page fault for address: 00007f033c669379\nPF: supervisor read access in kernel mode\nPF: error_code(0x0001) - permissions violation\nPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025\nOops: Oops: 0001 [#1] SMP PTI\nCPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1\nHardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024\nRIP: 0010:strlen+0x4/0x30\nCode: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa \u0026lt;80\u0026gt; 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc\nRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202\nRAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001\nRDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379\nRBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a\nR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8\nR13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30\nFS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x149/0x4c0\n ? raw_spin_rq_lock_nested+0xe/0x20\n ? sched_balance_newidle+0x22b/0x3c0\n ? update_load_avg+0x78/0x770\n ? exc_page_fault+0x6f/0x150\n ? asm_exc_page_fault+0x26/0x30\n ? __pfx_pci_conf1_write+0x10/0x10\n ? strlen+0x4/0x30\n devm_kstrdup+0x25/0x70\n brcmf_of_probe+0x273/0x350 [brcmfmac](CVE-2025-21750)",
"id": "OESA-2025-1320",
"modified": "2026-08-06T11:08:25Z",
"published": "2025-03-21T11:08:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1320"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36476"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56778"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57884"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57885"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57890"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57897"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57903"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58069"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58080"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21629"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21639"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21646"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21654"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21655"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21660"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21662"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21663"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21719"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21750"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-36476",
"CVE-2024-56778",
"CVE-2024-57802",
"CVE-2024-57834",
"CVE-2024-57883",
"CVE-2024-57884",
"CVE-2024-57885",
"CVE-2024-57890",
"CVE-2024-57894",
"CVE-2024-57897",
"CVE-2024-57901",
"CVE-2024-57902",
"CVE-2024-57903",
"CVE-2024-57913",
"CVE-2024-57938",
"CVE-2024-57945",
"CVE-2024-58069",
"CVE-2024-58080",
"CVE-2024-58087",
"CVE-2025-21629",
"CVE-2025-21639",
"CVE-2025-21642",
"CVE-2025-21646",
"CVE-2025-21654",
"CVE-2025-21655",
"CVE-2025-21660",
"CVE-2025-21662",
"CVE-2025-21663",
"CVE-2025-21664",
"CVE-2025-21719",
"CVE-2025-21750"
]
}
OESA-2025-1321 (CVE-2024-36476)
Vulnerability from osv_openeuler – Published: 2025-03-21 11:08 – Updated: 2026-08-06 11:08 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
RDMA/rtrs: Ensure 'ib_sge list' is accessible
Move the declaration of the 'ib_sge list' variable outside the 'always_invalidate' block to ensure it remains accessible for use throughout the function.
Previously, 'ib_sge list' was declared within the 'always_invalidate' block, limiting its accessibility, then caused a 'BUG: kernel NULL pointer dereference'[1]. ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2d0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? memcpy_orig+0xd5/0x140 rxe_mr_copy+0x1c3/0x200 [rdma_rxe] ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe] copy_data+0xa5/0x230 [rdma_rxe] rxe_requester+0xd9b/0xf70 [rdma_rxe] ? finish_task_switch.isra.0+0x99/0x2e0 rxe_sender+0x13/0x40 [rdma_rxe] do_task+0x68/0x1e0 [rdma_rxe] process_one_work+0x177/0x330 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10
This change ensures the variable is available for subsequent operations that require it.
[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/(CVE-2024-36476)
In the Linux kernel, the following vulnerability has been resolved:
drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check
The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure.(CVE-2024-56778)
In the Linux kernel, the following vulnerability has been resolved:
netrom: check buffer length before accessing it
Syzkaller reports an uninit value read from ax25cmp when sending raw message through ieee802154 implementation.
===================================================== BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601 nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774 nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2584 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [inline] raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] _syssendmsg+0x9c2/0xd60 net/socket.c:2584 _sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 =====================================================
This issue occurs because the skb buffer is too small, and it's actual allocation is aligned. This hides an actual issue, which is that nr_route_frame does not validate the buffer size before using it.
Fix this issue by checking skb->len before accessing any fields in skb->data.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-57802)
In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread
syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]
If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread().
Adjust the timing of streaming initialization and check it before stopping it.
[1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-57834)
In the Linux kernel, the following vulnerability has been resolved:
mm: hugetlb: independent PMD page table shared count
The folio refcount may be increased unexpectly through try_get_folio() by caller such as split_huge_pages. In huge_pmd_unshare(), we use refcount to check whether a pmd page table is shared. The check is incorrect if the refcount is increased by the above caller, and this can cause the page table leaked:
BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198
The issue may be triggered by damon, offline_page, page_idle, etc, which will increase the refcount of page table.
-
The page table itself will be discarded after reporting the "nonzero mapcount".
-
The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped.
Fix it by introducing independent PMD page table shared count. As described by comment, pt_index/pt_mm/pt_frag_refcount are used for s390 gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv pmds, so we can reuse the field as pt_share_count.(CVE-2024-57883)
In the Linux kernel, the following vulnerability has been resolved:
mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()
The task sometimes continues looping in throttle_direct_reclaim() because allow_direct_reclaim(pgdat) keeps returning false.
#0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4
At this point, the pgdat contains the following two zones:
NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32"
SIZE: 20480 MIN/LOW/HIGH: 11/28/45
VM_STAT:
NR_FREE_PAGES: 359
NR_ZONE_INACTIVE_ANON: 18813
NR_ZONE_ACTIVE_ANON: 0
NR_ZONE_INACTIVE_FILE: 50
NR_ZONE_ACTIVE_FILE: 0
NR_ZONE_UNEVICTABLE: 0
NR_ZONE_WRITE_PENDING: 0
NR_MLOCK: 0
NR_BOUNCE: 0
NR_ZSPAGES: 0
NR_FREE_CMA_PAGES: 0
NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal"
SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264
VM_STAT:
NR_FREE_PAGES: 146
NR_ZONE_INACTIVE_ANON: 94668
NR_ZONE_ACTIVE_ANON: 3
NR_ZONE_INACTIVE_FILE: 735
NR_ZONE_ACTIVE_FILE: 78
NR_ZONE_UNEVICTABLE: 0
NR_ZONE_WRITE_PENDING: 0
NR_MLOCK: 0
NR_BOUNCE: 0
NR_ZSPAGES: 0
NR_FREE_CMA_PAGES: 0
In allow_direct_reclaim(), while processing ZONE_DMA32, the sum of inactive/active file-backed pages calculated in zone_reclaimable_pages() based on the result of zone_page_state_snapshot() is zero.
Additionally, since this system lacks swap, the calculation of inactive/ active anonymous pages is skipped.
crash> p nr_swap_pages
nr_swap_pages = $1937 = {
counter = 0
}
As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to the processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having free pages significantly exceeding the high watermark.
The problem is that the pgdat->kswapd_failures hasn't been incremented.
crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures
$1935 = 0x0
This is because the node deemed balanced. The node balancing logic in balance_pgdat() evaluates all zones collectively. If one or more zones (e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the entire node is deemed balanced. This causes balance_pgdat() to exit early before incrementing the kswapd_failures, as it considers the overall memory state acceptable, even though some zones (like ZONE_NORMAL) remain under significant pressure.
The patch ensures that zone_reclaimable_pages() includes free pages (NR_FREE_PAGES) in its calculation when no other reclaimable pages are available (e.g., file-backed or anonymous pages). This change prevents zones like ZONE_DMA32, which have sufficient free pages, from being mistakenly deemed unreclaimable. By doing so, the patch ensures proper node balancing, avoids masking pressure on other zones like ZONE_NORMAL, and prevents infinite loops in throttle_direct_reclaim() caused by allow_direct_reclaim(pgdat) repeatedly returning false.
The kernel hangs due to a task stuck in throttle_direct_reclaim(), caused by a node being incorrectly deemed balanced despite pressure in certain zones, such as ZONE_NORMAL. This issue arises from zone_reclaimable_pages ---truncated---(CVE-2024-57884)
In the Linux kernel, the following vulnerability has been resolved:
mm/kmemleak: fix sleeping function called from invalid context at print message
Address a bug in the kernel that triggers a "sleeping function called from invalid context" warning when /sys/kernel/debug/kmemleak is printed under specific conditions: - CONFIG_PREEMPT_RT=y - Set SELinux as the LSM for the system - Set kptr_restrict to 1 - kmemleak buffer contains at least one item
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 136, name: cat preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 2 6 locks held by cat/136: #0: ffff32e64bcbf950 (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0xb8/0xe30 #1: ffffafe6aaa9dea0 (scan_mutex){+.+.}-{3:3}, at: kmemleak_seq_start+0x34/0x128 #3: ffff32e6546b1cd0 (&object->lock){....}-{2:2}, at: kmemleak_seq_show+0x3c/0x1e0 #4: ffffafe6aa8d8560 (rcu_read_lock){....}-{1:2}, at: has_ns_capability_noaudit+0x8/0x1b0 #5: ffffafe6aabbc0f8 (notif_lock){+.+.}-{2:2}, at: avc_compute_av+0xc4/0x3d0 irq event stamp: 136660 hardirqs last enabled at (136659): [<ffffafe6a80fd7a0>] _raw_spin_unlock_irqrestore+0xa8/0xd8 hardirqs last disabled at (136660): [<ffffafe6a80fd85c>] _raw_spin_lock_irqsave+0x8c/0xb0 softirqs last enabled at (0): [<ffffafe6a5d50b28>] copy_process+0x11d8/0x3df8 softirqs last disabled at (0): [<0000000000000000>] 0x0 Preemption disabled at: [<ffffafe6a6598a4c>] kmemleak_seq_show+0x3c/0x1e0 CPU: 1 UID: 0 PID: 136 Comm: cat Tainted: G E 6.11.0-rt7+ #34 Tainted: [E]=UNSIGNED_MODULE Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0xa0/0x128 show_stack+0x1c/0x30 dump_stack_lvl+0xe8/0x198 dump_stack+0x18/0x20 rt_spin_lock+0x8c/0x1a8 avc_perm_nonode+0xa0/0x150 cred_has_capability.isra.0+0x118/0x218 selinux_capable+0x50/0x80 security_capable+0x7c/0xd0 has_ns_capability_noaudit+0x94/0x1b0 has_capability_noaudit+0x20/0x30 restricted_pointer+0x21c/0x4b0 pointer+0x298/0x760 vsnprintf+0x330/0xf70 seq_printf+0x178/0x218 print_unreferenced+0x1a4/0x2d0 kmemleak_seq_show+0xd0/0x1e0 seq_read_iter+0x354/0xe30 seq_read+0x250/0x378 full_proxy_read+0xd8/0x148 vfs_read+0x190/0x918 ksys_read+0xf0/0x1e0 __arm64_sys_read+0x70/0xa8 invoke_syscall.constprop.0+0xd4/0x1d8 el0_svc+0x50/0x158 el0t_64_sync+0x17c/0x180
%pS and %pK, in the same back trace line, are redundant, and %pS can void %pK service in certain contexts.
%pS alone already provides the necessary information, and if it cannot resolve the symbol, it falls back to printing the raw address voiding the original intent behind the %pK.
Additionally, %pK requires a privilege check CAP_SYSLOG enforced through the LSM, which can trigger a "sleeping function called from invalid context" warning under RT_PREEMPT kernels when the check occurs in an atomic context. This issue may also affect other LSMs.
This change avoids the unnecessary privilege check and resolves the sleeping function warning without any loss of information.(CVE-2024-57885)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/uverbs: Prevent integer overflow issue
In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32 values that come from the user so the multiplication can lead to integer wrapping. Then we pass the result to uverbs_request_next_ptr() which also could potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)" multiplication can also overflow on 32bit systems although it's fine on 64bit systems.
This patch does two things. First, I've re-arranged the condition in uverbs_request_next_ptr() so that the use controlled variable "len" is on one side of the comparison by itself without any math. Then I've modified all the callers to use size_mul() for the multiplications.(CVE-2024-57890)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix sleeping function called from invalid context
This reworks hci_cb_list to not use mutex hci_cb_list_lock to avoid bugs like the bellow:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5070, name: kworker/u9:2 preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 4 locks held by kworker/u9:2/5070: #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline] #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x1770 kernel/workqueue.c:3335 #1: ffffc90003b6fd00 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline] #1: ffffc90003b6fd00 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x1770 kernel/workqueue.c:3335 #2: ffff8880665d0078 (&hdev->lock){+.+.}-{3:3}, at: hci_le_create_big_complete_evt+0xcf/0xae0 net/bluetooth/hci_event.c:6914 #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline] #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline] #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: hci_le_create_big_complete_evt+0xdb/0xae0 net/bluetooth/hci_event.c:6915 CPU: 0 PID: 5070 Comm: kworker/u9:2 Not tainted 6.8.0-syzkaller-08073-g480e035fc4c7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: hci0 hci_rx_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 __might_resched+0x5d4/0x780 kernel/sched/core.c:10187 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0xc1/0xd70 kernel/locking/mutex.c:752 hci_connect_cfm include/net/bluetooth/hci_core.h:2004 [inline] hci_le_create_big_complete_evt+0x3d9/0xae0 net/bluetooth/hci_event.c:6939 hci_event_func net/bluetooth/hci_event.c:7514 [inline] hci_event_packet+0xa53/0x1540 net/bluetooth/hci_event.c:7569 hci_rx_work+0x3e8/0xca0 net/bluetooth/hci_core.c:4171 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa00/0x1770 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f0/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243 </TASK>(CVE-2024-57894)
In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Correct the migration DMA map direction
The SVM DMA device map direction should be set the same as the DMA unmap setting, otherwise the DMA core will report the following warning.
Before finialize this solution, there're some discussion on the DMA mapping type(stream-based or coherent) in this KFD migration case, followed by https://lore.kernel.org/all/04d4ab32 -45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/.
As there's no dma_sync_single_for_*() in the DMA buffer accessed that because this migration operation should be sync properly and automatically. Give that there's might not be a performance problem in various cache sync policy of DMA sync. Therefore, in order to simplify the DMA direction setting alignment, let's set the DMA map direction as BIDIRECTIONAL.
[ 150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930 [ 150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds [ 150.834310] wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii [ 150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G OE 6.10.0-custom #492 [ 150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021 [ 150.834360] RIP: 0010:check_unmap+0x1cc/0x930 [ 150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff <0f> 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50 [ 150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086 [ 150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027 [ 150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680 [ 150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850 [ 150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40 [ 150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b [ 150.834377] FS: 00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000 [ 150.834379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0 [ 150.834383] Call Trace: [ 150.834385] <TASK> [ 150.834387] ? show_regs+0x6d/0x80 [ 150.834393] ? __warn+0x8c/0x140 [ 150.834397] ? check_unmap+0x1cc/0x930 [ 150.834400] ? report_bug+0x193/0x1a0 [ 150.834406] ? handle_bug+0x46/0x80 [ 150.834410] ? exc_invalid_op+0x1d/0x80 [ 150.834413] ? asm_exc_invalid_op+0x1f/0x30 [ 150.834420] ? check_unmap+0x1cc/0x930 [ 150.834425] debug_dma_unmap_page+0x86/0x90 [ 150.834431] ? srso_return_thunk+0x5/0x5f [ 150.834435] ---truncated---(CVE-2024-57897)
In the Linux kernel, the following vulnerability has been resolved:
af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK
Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot.
Rework vlan_get_protocol_dgram() to not touch skb at all, so that it can be used from many cpus on the same skb.
Add a const qualifier to skb argument.
[1] skbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900038d7638 EFLAGS: 00010282 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60 R10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140 R13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011 FS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585 packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1055 _sysrecvmsg+0x1c6/0x480 net/socket.c:2803 _sys_recvmsg net/socket.c:2845 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2940 __sys_recvmmsg net/socket.c:3014 [inline] __do_sys_recvmmsg net/socket.c:3037 [inline] __se_sys_recvmmsg net/socket.c:3030 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030 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(CVE-2024-57901)
In the Linux kernel, the following vulnerability has been resolved:
af_packet: fix vlan_get_tci() vs MSG_PEEK
Blamed commit forgot MSG_PEEK case, allowing a crash [1] as found by syzbot.
Rework vlan_get_tci() to not touch skb at all, so that it can be used from many cpus on the same skb.
Add a const qualifier to skb argument.
[1] skbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:<NULL> ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0b 8d 48 c7 c6 9e 6c 26 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 3a 5a 79 f7 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286 RAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50 R10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140 R13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014 FS: 00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565 packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1066 _sysrecvmsg+0x1c6/0x480 net/socket.c:2814 _sys_recvmsg net/socket.c:2856 [inline] do_recvmmsg+0x426/0xab0 net/socket.c:2951 __sys_recvmmsg net/socket.c:3025 [inline] __do_sys_recvmmsg net/socket.c:3048 [inline] __se_sys_recvmmsg net/socket.c:3041 [inline] __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83(CVE-2024-57902)
In the Linux kernel, the following vulnerability has been resolved:
net: restrict SO_REUSEPORT to inet sockets
After blamed commit, crypto sockets could accidentally be destroyed from RCU call back, as spotted by zyzbot [1].
Trying to acquire a mutex in RCU callback is not allowed.
Restrict SO_REUSEPORT socket option to inet sockets.
v1 of this patch supported TCP, UDP and SCTP sockets, but fcnal-test.sh test needed RAW and ICMP support.
[1] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1 preempt_count: 100, expected: 0 RCU nest depth: 0, expected: 0 1 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823 Preemption disabled at: [<ffffffff8161c8c8>] softirq_handle_begin kernel/softirq.c:402 [inline] [<ffffffff8161c8c8>] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537 CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>(CVE-2024-57903)
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_fs: Remove WARN_ON in functionfs_bind
This commit addresses an issue related to below kernel panic where panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON in functionsfs_bind, which easily leads to the following scenarios.
1.adb_write in adbd 2. UDC write via configfs ================= =====================
->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register() ->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() <times-out without BIND event> ->configfs_composite_bind() ->usb_add_function() ->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() <ffs->state !=FFS_ACTIVE>
The adb_open, adb_read, and adb_write operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARN_ON from functionfs_bind when panic_on_warn is enabled. This commit fixes the kernel panic by removing the unnecessary WARN_ON.
Kernel panic - not syncing: kernel: panic_on_warn set ... [ 14.542395] Call trace: [ 14.542464] ffs_func_bind+0x1c8/0x14a8 [ 14.542468] usb_add_function+0xcc/0x1f0 [ 14.542473] configfs_composite_bind+0x468/0x588 [ 14.542478] gadget_bind_driver+0x108/0x27c [ 14.542483] really_probe+0x190/0x374 [ 14.542488] __driver_probe_device+0xa0/0x12c [ 14.542492] driver_probe_device+0x3c/0x220 [ 14.542498] __driver_attach+0x11c/0x1fc [ 14.542502] bus_for_each_dev+0x104/0x160 [ 14.542506] driver_attach+0x24/0x34 [ 14.542510] bus_add_driver+0x154/0x270 [ 14.542514] driver_register+0x68/0x104 [ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4 [ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144 [ 14.542526] configfs_write_iter+0xf0/0x138(CVE-2024-57913)
In the Linux kernel, the following vulnerability has been resolved:
net/sctp: Prevent autoclose integer overflow in sctp_association_init()
While by default max_autoclose equals to INT_MAX / HZ, one may set net.sctp.max_autoclose to UINT_MAX. There is code in sctp_association_init() that can consequently trigger overflow.(CVE-2024-57938)
In the Linux kernel, the following vulnerability has been resolved:
riscv: mm: Fix the out of bound issue of vmemmap address
In sparse vmemmap model, the virtual address of vmemmap is calculated as: ((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)). And the struct page's va can be calculated with an offset: (vmemmap + (pfn)).
However, when initializing struct pages, kernel actually starts from the first page from the same section that phys_ram_base belongs to. If the first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then we get an va below VMEMMAP_START when calculating va for it's struct page.
For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the first page in the same section is actually pfn 0x80000. During init_unavailable_range(), we will initialize struct page for pfn 0x80000 with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is below VMEMMAP_START as well as PCI_IO_END.
This commit fixes this bug by introducing a new variable 'vmemmap_start_pfn' which is aligned with memory section size and using it to calculate vmemmap address instead of phys_ram_base.(CVE-2024-57945)
In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int.
Fix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)
In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: dispcc-sm6350: Add missing parent_map for a clock
If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following:
[ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c
Add the parent_map property for the clock where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together.(CVE-2024-58080)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix racy issue from session lookup and expire
Increment the session reference count within the lock for lookup to avoid racy issue with session expire.(CVE-2024-58087)
In the Linux kernel, the following vulnerability has been resolved:
net: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets
The blamed commit disabled hardware offoad of IPv6 packets with extension headers on devices that advertise NETIF_F_IPV6_CSUM, based on the definition of that feature in skbuff.h:
-
-
- %NETIF_F_IPV6_CSUM
-
-
- Driver (device) is only able to checksum plain
- TCP or UDP packets over IPv6. These are specifically
- unencapsulated packets of the form IPv6|TCP or
- IPv6|UDP where the Next Header field in the IPv6
- header is either TCP or UDP. IPv6 extension headers
- are not supported with this feature. This feature
- cannot be set in features for a device with
- NETIF_F_HW_CSUM also set. This feature is being
- DEPRECATED (see below).
The change causes skb_warn_bad_offload to fire for BIG TCP packets.
[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skb_warn_bad_offload+0xc4/0xe0
[ 496.310297] ? skb_warn_bad_offload+0xc4/0xe0 [ 496.310300] skb_checksum_help+0x129/0x1f0 [ 496.310303] skb_csum_hwoffload_help+0x150/0x1b0 [ 496.310306] validate_xmit_skb+0x159/0x270 [ 496.310309] validate_xmit_skb_list+0x41/0x70 [ 496.310312] sch_direct_xmit+0x5c/0x250 [ 496.310317] __qdisc_run+0x388/0x620
BIG TCP introduced an IPV6_TLV_JUMBO IPv6 extension header to communicate packet length, as this is an IPv6 jumbogram. But, the feature is only enabled on devices that support BIG TCP TSO. The header is only present for PF_PACKET taps like tcpdump, and not transmitted by physical devices.
For this specific case of extension headers that are not transmitted, return to the situation before the blamed commit and support hardware offload.
ipv6_has_hopopt_jumbo() tests not only whether this header is present, but also that it is the only extension header before a terminal (L4) header.(CVE-2025-21629)
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: rto_min/max: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:
-
Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.
-
current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using container_of().
Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.(CVE-2025-21639)
In the Linux kernel, the following vulnerability has been resolved:
mptcp: sysctl: sched: avoid using current->nsproxy
Using the 'net' structure via 'current' is not recommended for different reasons.
First, if the goal is to use it to read or write per-netns data, this is inconsistent with how the "generic" sysctl entries are doing: directly by only using pointers set to the table entry, e.g. table->data. Linked to that, the per-netns data should always be obtained from the table linked to the netns it had been created for, which may not coincide with the reader's or writer's netns.
Another reason is that access to current->nsproxy->netns can oops if attempted when current->nsproxy had been dropped when the current task is exiting. This is what syzbot found, when using acct(2):
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00 RSP: 0018:ffffc900034774e8 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620 RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028 RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040 R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000 R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601 __kernel_write_iter+0x318/0xa80 fs/read_write.c:612 __kernel_write+0xf6/0x140 fs/read_write.c:632 do_acct_process+0xcb0/0x14a0 kernel/acct.c:539 acct_pin_kill+0x2d/0x100 kernel/acct.c:192 pin_kill+0x194/0x7c0 fs/fs_pin.c:44 mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81 cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366 task_work_run+0x14e/0x250 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xad8/0x2d70 kernel/exit.c:938 do_group_exit+0xd3/0x2a0 kernel/exit.c:1087 get_signal+0x2576/0x2610 kernel/signal.c:3017 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fee3cb87a6a Code: Unable to access opcode bytes at 0x7fee3cb87a40. RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037 RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7 R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500 R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125 Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ---truncated---(CVE-2025-21642)
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix the maximum cell name length
The kafs filesystem limits the maximum length of a cell to 256 bytes, but a problem occurs if someone actually does that: kafs tries to create a directory under /proc/net/afs/ with the name of the cell, but that fails with a warning:
WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405
because procfs limits the maximum filename length to 255.
However, the DNS limits the maximum lookup length and, by extension, the maximum cell name, to 255 less two (length count and trailing NUL).
Fix this by limiting the maximum acceptable cellname length to 253. This also allows us to be sure we can create the "/afs/.<cell>/" mountpoint too.
Further, split the YFS VL record cell name maximum to be the 256 allowed by the protocol and ignore the record retrieved by YFSVL.GetCellName if it exceeds 253.(CVE-2025-21646)
In the Linux kernel, the following vulnerability has been resolved:
ovl: support encoding fid from inode with no alias
Dmitry Safonov reported that a WARN_ON() assertion can be trigered by userspace when calling inotify_show_fdinfo() for an overlayfs watched inode, whose dentry aliases were discarded with drop_caches.
The WARN_ON() assertion in inotify_show_fdinfo() was removed, because it is possible for encoding file handle to fail for other reason, but the impact of failing to encode an overlayfs file handle goes beyond this assertion.
As shown in the LTP test case mentioned in the link below, failure to encode an overlayfs file handle from a non-aliased inode also leads to failure to report an fid with FAN_DELETE_SELF fanotify events.
As Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails if it cannot find an alias for the inode, but this failure can be fixed. ovl_encode_fh() seldom uses the alias and in the case of non-decodable file handles, as is often the case with fanotify fid info, ovl_encode_fh() never needs to use the alias to encode a file handle.
Defer finding an alias until it is actually needed so ovl_encode_fh() will not fail in the common case of FAN_DELETE_SELF fanotify events.(CVE-2025-21654)
In the Linux kernel, the following vulnerability has been resolved:
io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period
io_eventfd_do_signal() is invoked from an RCU callback, but when dropping the reference to the io_ev_fd, it calls io_eventfd_free() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the io_ev_fd should be deferred another RCU grace period.
Just call io_eventfd_put() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.(CVE-2025-21655)
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked
When ksmbd_vfs_kern_path_locked met an error and it is not the last
entry, it will exit without restoring changed path buffer. But later this
buffer may be used as the filename for creation.(CVE-2025-21660)
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Fix variable not being completed when function returns
When cmd_alloc_index(), fails cmd_work_handler() needs to complete ent->slotted before returning early. Otherwise the task which issued the command may hang:
mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry INFO: task kworker/13:2:4055883 blocked for more than 120 seconds. Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/13:2 D 0 4055883 2 0x00000228 Workqueue: events mlx5e_tx_dim_work [mlx5_core] Call trace: __switch_to+0xe8/0x150 __schedule+0x2a8/0x9b8 schedule+0x2c/0x88 schedule_timeout+0x204/0x478 wait_for_common+0x154/0x250 wait_for_completion+0x28/0x38 cmd_exec+0x7a0/0xa00 [mlx5_core] mlx5_cmd_exec+0x54/0x80 [mlx5_core] mlx5_core_modify_cq+0x6c/0x80 [mlx5_core] mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core] mlx5e_tx_dim_work+0x54/0x68 [mlx5_core] process_one_work+0x1b0/0x448 worker_thread+0x54/0x468 kthread+0x134/0x138 ret_from_fork+0x10/0x18(CVE-2025-21662)
In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: dwmac-tegra: Read iommu stream id from device tree
Nvidia's Tegra MGBE controllers require the IOMMU "Stream ID" (SID) to be written to the MGBE_WRAP_AXI_ASID0_CTRL register.
The current driver is hard coded to use MGBE0's SID for all controllers. This causes softirq time outs and kernel panics when using controllers other than MGBE0.
Example dmesg errors when an ethernet cable is connected to MGBE1:
[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms [ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter. [ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171) [ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features [ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported [ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock [ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode [ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx [ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [ 181.921404] rcu: 7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337 [ 181.921684] rcu: (detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8) [ 181.921878] Sending NMI from CPU 4 to CPUs 7: [ 181.921886] NMI backtrace for cpu 7 [ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6 [ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024 [ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 181.922847] pc : handle_softirqs+0x98/0x368 [ 181.922978] lr : __do_softirq+0x18/0x20 [ 181.923095] sp : ffff80008003bf50 [ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000 [ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0 [ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70 [ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000 [ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000 [ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d [ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160 [ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74 [ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1 [ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000 [ 181.967591] Call trace: [ 181.970043] handle_softirqs+0x98/0x368 (P) [ 181.974240] __do_softirq+0x18/0x20 [ 181.977743] _dosoftirq+0x14/0x28 [ 181.981415] call_on_irq_stack+0x24/0x30 [ 181.985180] do_softirq_own_stack+0x20/0x30 [ 181.989379] irq_exit_rcu+0x114/0x140 [ 181.993142] irq_exit_rcu+0x14/0x28 [ 181.996816] el1_interrupt+0x44/0xb8 [ 182.000316] el1h_64_irq_handler+0x14/0x20 [ 182.004343] el1h_64_irq+0x80/0x88 [ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P) [ 182.012305] cpuidle_enter+0x3c/0x58 [ 182.015980] cpuidle_idle_call+0x128/0x1c0 [ 182.020005] do_idle+0xe0/0xf0 [ 182.023155] cpu_startup_entry+0x3c/0x48 [ 182.026917] secondary_start_kernel+0xdc/0x120 [ 182.031379] __secondary_switched+0x74/0x78 [ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/. [ 212.985935] rcu: blocking rcu_node structures (internal RCU debug): [ 212.992758] Sending NMI from CPU 0 to CPUs 7: [ 212.998539] NMI backtrace for cpu 7 [ 213.004304] CPU: 7 UID: 0 PI ---truncated---(CVE-2025-21663)
In the Linux kernel, the following vulnerability has been resolved:
dm thin: make get_first_thin use rcu-safe list first function
The documentation in rculist.h explains the absence of list_empty_rcu() and cautions programmers against relying on a list_empty() -> list_first() sequence in RCU safe code. This is because each of these functions performs its own READ_ONCE() of the list head. This can lead to a situation where the list_empty() sees a valid list entry, but the subsequent list_first() sees a different view of list head state after a modification.
In the case of dm-thin, this author had a production box crash from a GP fault in the process_deferred_bios path. This function saw a valid list head in get_first_thin() but when it subsequently dereferenced that and turned it into a thin_c, it got the inside of the struct pool, since the list was now empty and referring to itself. The kernel on which this occurred printed both a warning about a refcount_t being saturated, and a UBSAN error for an out-of-bounds cpuid access in the queued spinlock, prior to the fault itself. When the resulting kdump was examined, it was possible to see another thread patiently waiting in thin_dtr's synchronize_rcu.
The thin_dtr call managed to pull the thin_c out of the active thins list (and have it be the last entry in the active_thins list) at just the wrong moment which lead to this crash.
Fortunately, the fix here is straight forward. Switch get_first_thin() function to use list_first_or_null_rcu() which performs just a single READ_ONCE() and returns NULL if the list is already empty.
This was run against the devicemapper test suite's thin-provisioning suites for delete and suspend and no regressions were observed.(CVE-2025-21664)
In the Linux kernel, the following vulnerability has been resolved:
ipmr: do not call mr_mfc_uses_dev() for unres entries
syzbot found that calling mr_mfc_uses_dev() for unres entries would crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvif alias to "struct sk_buff_head unresolved", which contain two pointers.
This code never worked, lets remove it.
[1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334 Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708(CVE-2025-21719)
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Check the return value of of_property_read_string_index()
Somewhen between 6.10 and 6.11 the driver started to crash on my MacBookPro14,3. The property doesn't exist and 'tmp' remains uninitialized, so we pass a random pointer to devm_kstrdup().
The crash I am getting looks like this:
BUG: unable to handle page fault for address: 00007f033c669379 PF: supervisor read access in kernel mode PF: error_code(0x0001) - permissions violation PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 Oops: Oops: 0001 [#1] SMP PTI CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1 Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024 RIP: 0010:strlen+0x4/0x30 Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 brcmfmac
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"bpftool-debuginfo-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"kernel-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"kernel-debuginfo-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"kernel-debugsource-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"kernel-devel-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"kernel-headers-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"kernel-source-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"kernel-tools-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"kernel-tools-debuginfo-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"kernel-tools-devel-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"perf-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"perf-debuginfo-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"python3-perf-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm",
"python3-perf-debuginfo-6.6.0-83.0.0.88.oe2403sp1.aarch64.rpm"
],
"src": [
"kernel-6.6.0-83.0.0.88.oe2403sp1.src.rpm"
],
"x86_64": [
"bpftool-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"bpftool-debuginfo-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"kernel-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"kernel-debuginfo-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"kernel-debugsource-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"kernel-devel-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"kernel-headers-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"kernel-source-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"kernel-tools-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"kernel-tools-debuginfo-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"kernel-tools-devel-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"perf-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"perf-debuginfo-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"python3-perf-6.6.0-83.0.0.88.oe2403sp1.x86_64.rpm",
"python3-perf-debuginfo-6.6.0-83.0.0.88.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-83.0.0.88.oe2403sp1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\n\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rtrs: Ensure \u0026apos;ib_sge list\u0026apos; is accessible\n\nMove the declaration of the \u0026apos;ib_sge list\u0026apos; variable outside the\n\u0026apos;always_invalidate\u0026apos; block to ensure it remains accessible for use\nthroughout the function.\n\nPreviously, \u0026apos;ib_sge list\u0026apos; was declared within the \u0026apos;always_invalidate\u0026apos;\nblock, limiting its accessibility, then caused a\n\u0026apos;BUG: kernel NULL pointer dereference\u0026apos;[1].\n ? __die_body.cold+0x19/0x27\n ? page_fault_oops+0x15a/0x2d0\n ? search_module_extables+0x19/0x60\n ? search_bpf_extables+0x5f/0x80\n ? exc_page_fault+0x7e/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? memcpy_orig+0xd5/0x140\n rxe_mr_copy+0x1c3/0x200 [rdma_rxe]\n ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe]\n copy_data+0xa5/0x230 [rdma_rxe]\n rxe_requester+0xd9b/0xf70 [rdma_rxe]\n ? finish_task_switch.isra.0+0x99/0x2e0\n rxe_sender+0x13/0x40 [rdma_rxe]\n do_task+0x68/0x1e0 [rdma_rxe]\n process_one_work+0x177/0x330\n worker_thread+0x252/0x390\n ? __pfx_worker_thread+0x10/0x10\n\nThis change ensures the variable is available for subsequent operations\nthat require it.\n\n[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/(CVE-2024-36476)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check\n\nThe return value of drm_atomic_get_crtc_state() needs to be\nchecked. To avoid use of error pointer \u0026apos;crtc_state\u0026apos; in case\nof the failure.(CVE-2024-56778)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetrom: check buffer length before accessing it\n\nSyzkaller reports an uninit value read from ax25cmp when sending raw message\nthrough ieee802154 implementation.\n\n=====================================================\nBUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119\n ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119\n nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601\n nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774\n nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144\n __netdev_start_xmit include/linux/netdevice.h:4940 [inline]\n netdev_start_xmit include/linux/netdevice.h:4954 [inline]\n xmit_one net/core/dev.c:3548 [inline]\n dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564\n __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349\n dev_queue_xmit include/linux/netdevice.h:3134 [inline]\n raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299\n ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560\n __alloc_skb+0x318/0x740 net/core/skbuff.c:651\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780\n sock_alloc_send_skb include/net/sock.h:1884 [inline]\n raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282\n ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nCPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\n=====================================================\n\nThis issue occurs because the skb buffer is too small, and it\u0026apos;s actual\nallocation is aligned. This hides an actual issue, which is that nr_route_frame\ndoes not validate the buffer size before using it.\n\nFix this issue by checking skb-\u0026gt;len before accessing any fields in skb-\u0026gt;data.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2024-57802)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread\n\nsyzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]\n\nIf dvb-\u0026gt;mux is not initialized successfully by vidtv_mux_init() in the\nvidtv_start_streaming(), it will trigger null pointer dereference about mux\nin vidtv_mux_stop_thread().\n\nAdjust the timing of streaming initialization and check it before\nstopping it.\n\n[1]\nKASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]\nCPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nRIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471\nCode: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 \u0026lt;0f\u0026gt; b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8\nRSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125\nRDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128\nRBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188\nR13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710\nFS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline]\n vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252\n dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000\n dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486\n dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559\n dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]\n dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246\n __fput+0x3f8/0xb60 fs/file_table.c:450\n task_work_run+0x14e/0x250 kernel/task_work.c:239\n get_signal+0x1d3/0x2610 kernel/signal.c:2790\n arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218\n do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-57834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: hugetlb: independent PMD page table shared count\n\nThe folio refcount may be increased unexpectly through try_get_folio() by\ncaller such as split_huge_pages. In huge_pmd_unshare(), we use refcount\nto check whether a pmd page table is shared. The check is incorrect if\nthe refcount is increased by the above caller, and this can cause the page\ntable leaked:\n\n BUG: Bad page state in process sh pfn:109324\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324\n flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff)\n page_type: f2(table)\n raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000\n raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000\n page dumped because: nonzero mapcount\n ...\n CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7\n Tainted: [B]=BAD_PAGE\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n Call trace:\n show_stack+0x20/0x38 (C)\n dump_stack_lvl+0x80/0xf8\n dump_stack+0x18/0x28\n bad_page+0x8c/0x130\n free_page_is_bad_report+0xa4/0xb0\n free_unref_page+0x3cc/0x620\n __folio_put+0xf4/0x158\n split_huge_pages_all+0x1e0/0x3e8\n split_huge_pages_write+0x25c/0x2d8\n full_proxy_write+0x64/0xd8\n vfs_write+0xcc/0x280\n ksys_write+0x70/0x110\n __arm64_sys_write+0x24/0x38\n invoke_syscall+0x50/0x120\n el0_svc_common.constprop.0+0xc8/0xf0\n do_el0_svc+0x24/0x38\n el0_svc+0x34/0x128\n el0t_64_sync_handler+0xc8/0xd0\n el0t_64_sync+0x190/0x198\n\nThe issue may be triggered by damon, offline_page, page_idle, etc, which\nwill increase the refcount of page table.\n\n1. The page table itself will be discarded after reporting the\n \u0026quot;nonzero mapcount\u0026quot;.\n\n2. The HugeTLB page mapped by the page table miss freeing since we\n treat the page table as shared and a shared page table will not be\n unmapped.\n\nFix it by introducing independent PMD page table shared count. As\ndescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390\ngmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv\npmds, so we can reuse the field as pt_share_count.(CVE-2024-57883)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()\n\nThe task sometimes continues looping in throttle_direct_reclaim() because\nallow_direct_reclaim(pgdat) keeps returning false. \n\n #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac\n #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c\n #2 [ffff80002cb6f990] schedule at ffff800008abc50c\n #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550\n #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68\n #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660\n #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98\n #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8\n #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974\n #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4\n\nAt this point, the pgdat contains the following two zones:\n\n NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: \u0026quot;DMA32\u0026quot;\n SIZE: 20480 MIN/LOW/HIGH: 11/28/45\n VM_STAT:\n NR_FREE_PAGES: 359\n NR_ZONE_INACTIVE_ANON: 18813\n NR_ZONE_ACTIVE_ANON: 0\n NR_ZONE_INACTIVE_FILE: 50\n NR_ZONE_ACTIVE_FILE: 0\n NR_ZONE_UNEVICTABLE: 0\n NR_ZONE_WRITE_PENDING: 0\n NR_MLOCK: 0\n NR_BOUNCE: 0\n NR_ZSPAGES: 0\n NR_FREE_CMA_PAGES: 0\n\n NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: \u0026quot;Normal\u0026quot;\n SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264\n VM_STAT:\n NR_FREE_PAGES: 146\n NR_ZONE_INACTIVE_ANON: 94668\n NR_ZONE_ACTIVE_ANON: 3\n NR_ZONE_INACTIVE_FILE: 735\n NR_ZONE_ACTIVE_FILE: 78\n NR_ZONE_UNEVICTABLE: 0\n NR_ZONE_WRITE_PENDING: 0\n NR_MLOCK: 0\n NR_BOUNCE: 0\n NR_ZSPAGES: 0\n NR_FREE_CMA_PAGES: 0\n\nIn allow_direct_reclaim(), while processing ZONE_DMA32, the sum of\ninactive/active file-backed pages calculated in zone_reclaimable_pages()\nbased on the result of zone_page_state_snapshot() is zero. \n\nAdditionally, since this system lacks swap, the calculation of inactive/\nactive anonymous pages is skipped.\n\n crash\u0026gt; p nr_swap_pages\n nr_swap_pages = $1937 = {\n counter = 0\n }\n\nAs a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on to\nthe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 having\nfree pages significantly exceeding the high watermark.\n\nThe problem is that the pgdat-\u0026gt;kswapd_failures hasn\u0026apos;t been incremented.\n\n crash\u0026gt; px ((struct pglist_data *) 0xffff00817fffe540)-\u0026gt;kswapd_failures\n $1935 = 0x0\n\nThis is because the node deemed balanced. The node balancing logic in\nbalance_pgdat() evaluates all zones collectively. If one or more zones\n(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, the\nentire node is deemed balanced. This causes balance_pgdat() to exit early\nbefore incrementing the kswapd_failures, as it considers the overall\nmemory state acceptable, even though some zones (like ZONE_NORMAL) remain\nunder significant pressure.\n\n\nThe patch ensures that zone_reclaimable_pages() includes free pages\n(NR_FREE_PAGES) in its calculation when no other reclaimable pages are\navailable (e.g., file-backed or anonymous pages). This change prevents\nzones like ZONE_DMA32, which have sufficient free pages, from being\nmistakenly deemed unreclaimable. By doing so, the patch ensures proper\nnode balancing, avoids masking pressure on other zones like ZONE_NORMAL,\nand prevents infinite loops in throttle_direct_reclaim() caused by\nallow_direct_reclaim(pgdat) repeatedly returning false.\n\n\nThe kernel hangs due to a task stuck in throttle_direct_reclaim(), caused\nby a node being incorrectly deemed balanced despite pressure in certain\nzones, such as ZONE_NORMAL. This issue arises from\nzone_reclaimable_pages\n---truncated---(CVE-2024-57884)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: fix sleeping function called from invalid context at print message\n\nAddress a bug in the kernel that triggers a \u0026quot;sleeping function called from\ninvalid context\u0026quot; warning when /sys/kernel/debug/kmemleak is printed under\nspecific conditions:\n- CONFIG_PREEMPT_RT=y\n- Set SELinux as the LSM for the system\n- Set kptr_restrict to 1\n- kmemleak buffer contains at least one item\n\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 136, name: cat\npreempt_count: 1, expected: 0\nRCU nest depth: 2, expected: 2\n6 locks held by cat/136:\n #0: ffff32e64bcbf950 (\u0026amp;p-\u0026gt;lock){+.+.}-{3:3}, at: seq_read_iter+0xb8/0xe30\n #1: ffffafe6aaa9dea0 (scan_mutex){+.+.}-{3:3}, at: kmemleak_seq_start+0x34/0x128\n #3: ffff32e6546b1cd0 (\u0026amp;object-\u0026gt;lock){....}-{2:2}, at: kmemleak_seq_show+0x3c/0x1e0\n #4: ffffafe6aa8d8560 (rcu_read_lock){....}-{1:2}, at: has_ns_capability_noaudit+0x8/0x1b0\n #5: ffffafe6aabbc0f8 (notif_lock){+.+.}-{2:2}, at: avc_compute_av+0xc4/0x3d0\nirq event stamp: 136660\nhardirqs last enabled at (136659): [\u0026lt;ffffafe6a80fd7a0\u0026gt;] _raw_spin_unlock_irqrestore+0xa8/0xd8\nhardirqs last disabled at (136660): [\u0026lt;ffffafe6a80fd85c\u0026gt;] _raw_spin_lock_irqsave+0x8c/0xb0\nsoftirqs last enabled at (0): [\u0026lt;ffffafe6a5d50b28\u0026gt;] copy_process+0x11d8/0x3df8\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\nPreemption disabled at:\n[\u0026lt;ffffafe6a6598a4c\u0026gt;] kmemleak_seq_show+0x3c/0x1e0\nCPU: 1 UID: 0 PID: 136 Comm: cat Tainted: G E 6.11.0-rt7+ #34\nTainted: [E]=UNSIGNED_MODULE\nHardware name: linux,dummy-virt (DT)\nCall trace:\n dump_backtrace+0xa0/0x128\n show_stack+0x1c/0x30\n dump_stack_lvl+0xe8/0x198\n dump_stack+0x18/0x20\n rt_spin_lock+0x8c/0x1a8\n avc_perm_nonode+0xa0/0x150\n cred_has_capability.isra.0+0x118/0x218\n selinux_capable+0x50/0x80\n security_capable+0x7c/0xd0\n has_ns_capability_noaudit+0x94/0x1b0\n has_capability_noaudit+0x20/0x30\n restricted_pointer+0x21c/0x4b0\n pointer+0x298/0x760\n vsnprintf+0x330/0xf70\n seq_printf+0x178/0x218\n print_unreferenced+0x1a4/0x2d0\n kmemleak_seq_show+0xd0/0x1e0\n seq_read_iter+0x354/0xe30\n seq_read+0x250/0x378\n full_proxy_read+0xd8/0x148\n vfs_read+0x190/0x918\n ksys_read+0xf0/0x1e0\n __arm64_sys_read+0x70/0xa8\n invoke_syscall.constprop.0+0xd4/0x1d8\n el0_svc+0x50/0x158\n el0t_64_sync+0x17c/0x180\n\n%pS and %pK, in the same back trace line, are redundant, and %pS can void\n%pK service in certain contexts.\n\n%pS alone already provides the necessary information, and if it cannot\nresolve the symbol, it falls back to printing the raw address voiding\nthe original intent behind the %pK.\n\nAdditionally, %pK requires a privilege check CAP_SYSLOG enforced through\nthe LSM, which can trigger a \u0026quot;sleeping function called from invalid\ncontext\u0026quot; warning under RT_PREEMPT kernels when the check occurs in an\natomic context. This issue may also affect other LSMs.\n\nThis change avoids the unnecessary privilege check and resolves the\nsleeping function warning without any loss of information.(CVE-2024-57885)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/uverbs: Prevent integer overflow issue\n\nIn the expression \u0026quot;cmd.wqe_size * cmd.wr_count\u0026quot;, both variables are u32\nvalues that come from the user so the multiplication can lead to integer\nwrapping. Then we pass the result to uverbs_request_next_ptr() which also\ncould potentially wrap. The \u0026quot;cmd.sge_count * sizeof(struct ib_uverbs_sge)\u0026quot;\nmultiplication can also overflow on 32bit systems although it\u0026apos;s fine on\n64bit systems.\n\nThis patch does two things. First, I\u0026apos;ve re-arranged the condition in\nuverbs_request_next_ptr() so that the use controlled variable \u0026quot;len\u0026quot; is on\none side of the comparison by itself without any math. Then I\u0026apos;ve modified\nall the callers to use size_mul() for the multiplications.(CVE-2024-57890)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_core: Fix sleeping function called from invalid context\n\nThis reworks hci_cb_list to not use mutex hci_cb_list_lock to avoid bugs\nlike the bellow:\n\nBUG: sleeping function called from invalid context at kernel/locking/mutex.c:585\nin_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5070, name: kworker/u9:2\npreempt_count: 0, expected: 0\nRCU nest depth: 1, expected: 0\n4 locks held by kworker/u9:2/5070:\n #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3229 [inline]\n #0: ffff888015be3948 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_scheduled_works+0x8e0/0x1770 kernel/workqueue.c:3335\n #1: ffffc90003b6fd00 ((work_completion)(\u0026amp;hdev-\u0026gt;rx_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3230 [inline]\n #1: ffffc90003b6fd00 ((work_completion)(\u0026amp;hdev-\u0026gt;rx_work)){+.+.}-{0:0}, at: process_scheduled_works+0x91b/0x1770 kernel/workqueue.c:3335\n #2: ffff8880665d0078 (\u0026amp;hdev-\u0026gt;lock){+.+.}-{3:3}, at: hci_le_create_big_complete_evt+0xcf/0xae0 net/bluetooth/hci_event.c:6914\n #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:298 [inline]\n #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:750 [inline]\n #3: ffffffff8e132020 (rcu_read_lock){....}-{1:2}, at: hci_le_create_big_complete_evt+0xdb/0xae0 net/bluetooth/hci_event.c:6915\nCPU: 0 PID: 5070 Comm: kworker/u9:2 Not tainted 6.8.0-syzkaller-08073-g480e035fc4c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: hci0 hci_rx_work\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n __might_resched+0x5d4/0x780 kernel/sched/core.c:10187\n __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n __mutex_lock+0xc1/0xd70 kernel/locking/mutex.c:752\n hci_connect_cfm include/net/bluetooth/hci_core.h:2004 [inline]\n hci_le_create_big_complete_evt+0x3d9/0xae0 net/bluetooth/hci_event.c:6939\n hci_event_func net/bluetooth/hci_event.c:7514 [inline]\n hci_event_packet+0xa53/0x1540 net/bluetooth/hci_event.c:7569\n hci_rx_work+0x3e8/0xca0 net/bluetooth/hci_core.c:4171\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0xa00/0x1770 kernel/workqueue.c:3335\n worker_thread+0x86d/0xd70 kernel/workqueue.c:3416\n kthread+0x2f0/0x390 kernel/kthread.c:388\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\n \u0026lt;/TASK\u0026gt;(CVE-2024-57894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Correct the migration DMA map direction\n\nThe SVM DMA device map direction should be set the same as\nthe DMA unmap setting, otherwise the DMA core will report\nthe following warning.\n\nBefore finialize this solution, there\u0026apos;re some discussion on\nthe DMA mapping type(stream-based or coherent) in this KFD\nmigration case, followed by https://lore.kernel.org/all/04d4ab32\n-45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/.\n\nAs there\u0026apos;s no dma_sync_single_for_*() in the DMA buffer accessed\nthat because this migration operation should be sync properly and\nautomatically. Give that there\u0026apos;s might not be a performance problem\nin various cache sync policy of DMA sync. Therefore, in order to\nsimplify the DMA direction setting alignment, let\u0026apos;s set the DMA map\ndirection as BIDIRECTIONAL.\n\n[ 150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930\n[ 150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds\n[ 150.834310] wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii\n[ 150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G OE 6.10.0-custom #492\n[ 150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021\n[ 150.834360] RIP: 0010:check_unmap+0x1cc/0x930\n[ 150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff \u0026lt;0f\u0026gt; 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50\n[ 150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086\n[ 150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027\n[ 150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680\n[ 150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850\n[ 150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40\n[ 150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b\n[ 150.834377] FS: 00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000\n[ 150.834379] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0\n[ 150.834383] Call Trace:\n[ 150.834385] \u0026lt;TASK\u0026gt;\n[ 150.834387] ? show_regs+0x6d/0x80\n[ 150.834393] ? __warn+0x8c/0x140\n[ 150.834397] ? check_unmap+0x1cc/0x930\n[ 150.834400] ? report_bug+0x193/0x1a0\n[ 150.834406] ? handle_bug+0x46/0x80\n[ 150.834410] ? exc_invalid_op+0x1d/0x80\n[ 150.834413] ? asm_exc_invalid_op+0x1f/0x30\n[ 150.834420] ? check_unmap+0x1cc/0x930\n[ 150.834425] debug_dma_unmap_page+0x86/0x90\n[ 150.834431] ? srso_return_thunk+0x5/0x5f\n[ 150.834435] \n---truncated---(CVE-2024-57897)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK\n\nBlamed commit forgot MSG_PEEK case, allowing a crash [1] as found\nby syzbot.\n\nRework vlan_get_protocol_dgram() to not touch skb at all,\nso that it can be used from many cpus on the same skb.\n\nAdd a const qualifier to skb argument.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff8a8ccd05 len:29 put:14 head:ffff88807fc8e400 data:ffff88807fc8e3f4 tail:0x11 end:0x140 dev:\u0026lt;NULL\u0026gt;\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 1 UID: 0 PID: 5892 Comm: syz-executor883 Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 0b 8d 48 c7 c6 86 d5 25 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 5a 69 79 f7 48 83 c4 20 90 \u0026lt;0f\u0026gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc900038d7638 EFLAGS: 00010282\nRAX: 0000000000000087 RBX: dffffc0000000000 RCX: 609ffd18ea660600\nRDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\nRBP: ffff88802483c8d0 R08: ffffffff817f0a8c R09: 1ffff9200071ae60\nR10: dffffc0000000000 R11: fffff5200071ae61 R12: 0000000000000140\nR13: ffff88807fc8e400 R14: ffff88807fc8e3f4 R15: 0000000000000011\nFS: 00007fbac5e006c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fbac5e00d58 CR3: 000000001238e000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_push+0xe5/0x100 net/core/skbuff.c:2636\n vlan_get_protocol_dgram+0x165/0x290 net/packet/af_packet.c:585\n packet_recvmsg+0x948/0x1ef0 net/packet/af_packet.c:3552\n sock_recvmsg_nosec net/socket.c:1033 [inline]\n sock_recvmsg+0x22f/0x280 net/socket.c:1055\n ____sys_recvmsg+0x1c6/0x480 net/socket.c:2803\n ___sys_recvmsg net/socket.c:2845 [inline]\n do_recvmmsg+0x426/0xab0 net/socket.c:2940\n __sys_recvmmsg net/socket.c:3014 [inline]\n __do_sys_recvmmsg net/socket.c:3037 [inline]\n __se_sys_recvmmsg net/socket.c:3030 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3030\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(CVE-2024-57901)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naf_packet: fix vlan_get_tci() vs MSG_PEEK\n\nBlamed commit forgot MSG_PEEK case, allowing a crash [1] as found\nby syzbot.\n\nRework vlan_get_tci() to not touch skb at all,\nso that it can be used from many cpus on the same skb.\n\nAdd a const qualifier to skb argument.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff8a8da482 len:32 put:14 head:ffff88807a1d5800 data:ffff88807a1d5810 tail:0x14 end:0x140 dev:\u0026lt;NULL\u0026gt;\n------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:206 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 UID: 0 PID: 5880 Comm: syz-executor172 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]\n RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216\nCode: 0b 8d 48 c7 c6 9e 6c 26 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 3a 5a 79 f7 48 83 c4 20 90 \u0026lt;0f\u0026gt; 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3\nRSP: 0018:ffffc90003baf5b8 EFLAGS: 00010286\nRAX: 0000000000000087 RBX: dffffc0000000000 RCX: 8565c1eec37aa000\nRDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\nRBP: ffff88802616fb50 R08: ffffffff817f0a4c R09: 1ffff92000775e50\nR10: dffffc0000000000 R11: fffff52000775e51 R12: 0000000000000140\nR13: ffff88807a1d5800 R14: ffff88807a1d5810 R15: 0000000000000014\nFS: 00007fa03261f6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffd65753000 CR3: 0000000031720000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n skb_push+0xe5/0x100 net/core/skbuff.c:2636\n vlan_get_tci+0x272/0x550 net/packet/af_packet.c:565\n packet_recvmsg+0x13c9/0x1ef0 net/packet/af_packet.c:3616\n sock_recvmsg_nosec net/socket.c:1044 [inline]\n sock_recvmsg+0x22f/0x280 net/socket.c:1066\n ____sys_recvmsg+0x1c6/0x480 net/socket.c:2814\n ___sys_recvmsg net/socket.c:2856 [inline]\n do_recvmmsg+0x426/0xab0 net/socket.c:2951\n __sys_recvmmsg net/socket.c:3025 [inline]\n __do_sys_recvmmsg net/socket.c:3048 [inline]\n __se_sys_recvmmsg net/socket.c:3041 [inline]\n __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3041\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83(CVE-2024-57902)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: restrict SO_REUSEPORT to inet sockets\n\nAfter blamed commit, crypto sockets could accidentally be destroyed\nfrom RCU call back, as spotted by zyzbot [1].\n\nTrying to acquire a mutex in RCU callback is not allowed.\n\nRestrict SO_REUSEPORT socket option to inet sockets.\n\nv1 of this patch supported TCP, UDP and SCTP sockets,\nbut fcnal-test.sh test needed RAW and ICMP support.\n\n[1]\nBUG: sleeping function called from invalid context at kernel/locking/mutex.c:562\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1\npreempt_count: 100, expected: 0\nRCU nest depth: 0, expected: 0\n1 lock held by ksoftirqd/1/24:\n #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline]\n #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline]\n #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823\nPreemption disabled at:\n [\u0026lt;ffffffff8161c8c8\u0026gt;] softirq_handle_begin kernel/softirq.c:402 [inline]\n [\u0026lt;ffffffff8161c8c8\u0026gt;] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537\nCPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n __might_resched+0x5d4/0x780 kernel/sched/core.c:8758\n __mutex_lock_common kernel/locking/mutex.c:562 [inline]\n __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735\n crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179\n aead_release+0x3d/0x50 crypto/algif_aead.c:489\n alg_do_release crypto/af_alg.c:118 [inline]\n alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502\n __sk_destruct+0x58/0x5f0 net/core/sock.c:2260\n rcu_do_batch kernel/rcu/tree.c:2567 [inline]\n rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823\n handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n run_ksoftirqd+0xca/0x130 kernel/softirq.c:950\n smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n \u0026lt;/TASK\u0026gt;(CVE-2024-57903)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Remove WARN_ON in functionfs_bind\n\nThis commit addresses an issue related to below kernel panic where\npanic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON\nin functionsfs_bind, which easily leads to the following scenarios.\n\n1.adb_write in adbd 2. UDC write via configfs\n =================\t =====================\n\n-\u0026gt;usb_ffs_open_thread() -\u0026gt;UDC write\n -\u0026gt;open_functionfs() -\u0026gt;configfs_write_iter()\n -\u0026gt;adb_open() -\u0026gt;gadget_dev_desc_UDC_store()\n -\u0026gt;adb_write() -\u0026gt;usb_gadget_register_driver_owner\n -\u0026gt;driver_register()\n-\u0026gt;StartMonitor() -\u0026gt;bus_add_driver()\n -\u0026gt;adb_read() -\u0026gt;gadget_bind_driver()\n\u0026lt;times-out without BIND event\u0026gt; -\u0026gt;configfs_composite_bind()\n -\u0026gt;usb_add_function()\n-\u0026gt;open_functionfs() -\u0026gt;ffs_func_bind()\n -\u0026gt;adb_open() -\u0026gt;functionfs_bind()\n \u0026lt;ffs-\u0026gt;state !=FFS_ACTIVE\u0026gt;\n\nThe adb_open, adb_read, and adb_write operations are invoked from the\ndaemon, but trying to bind the function is a process that is invoked by\nUDC write through configfs, which opens up the possibility of a race\ncondition between the two paths. In this race scenario, the kernel panic\noccurs due to the WARN_ON from functionfs_bind when panic_on_warn is\nenabled. This commit fixes the kernel panic by removing the unnecessary\nWARN_ON.\n\nKernel panic - not syncing: kernel: panic_on_warn set ...\n[ 14.542395] Call trace:\n[ 14.542464] ffs_func_bind+0x1c8/0x14a8\n[ 14.542468] usb_add_function+0xcc/0x1f0\n[ 14.542473] configfs_composite_bind+0x468/0x588\n[ 14.542478] gadget_bind_driver+0x108/0x27c\n[ 14.542483] really_probe+0x190/0x374\n[ 14.542488] __driver_probe_device+0xa0/0x12c\n[ 14.542492] driver_probe_device+0x3c/0x220\n[ 14.542498] __driver_attach+0x11c/0x1fc\n[ 14.542502] bus_for_each_dev+0x104/0x160\n[ 14.542506] driver_attach+0x24/0x34\n[ 14.542510] bus_add_driver+0x154/0x270\n[ 14.542514] driver_register+0x68/0x104\n[ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4\n[ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144\n[ 14.542526] configfs_write_iter+0xf0/0x138(CVE-2024-57913)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sctp: Prevent autoclose integer overflow in sctp_association_init()\n\nWhile by default max_autoclose equals to INT_MAX / HZ, one may set\nnet.sctp.max_autoclose to UINT_MAX. There is code in\nsctp_association_init() that can consequently trigger overflow.(CVE-2024-57938)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: mm: Fix the out of bound issue of vmemmap address\n\nIn sparse vmemmap model, the virtual address of vmemmap is calculated as:\n((struct page *)VMEMMAP_START - (phys_ram_base \u0026gt;\u0026gt; PAGE_SHIFT)).\nAnd the struct page\u0026apos;s va can be calculated with an offset:\n(vmemmap + (pfn)).\n\nHowever, when initializing struct pages, kernel actually starts from the\nfirst page from the same section that phys_ram_base belongs to. If the\nfirst page\u0026apos;s physical address is not (phys_ram_base \u0026gt;\u0026gt; PAGE_SHIFT), then\nwe get an va below VMEMMAP_START when calculating va for it\u0026apos;s struct page.\n\nFor example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the\nfirst page in the same section is actually pfn 0x80000. During\ninit_unavailable_range(), we will initialize struct page for pfn 0x80000\nwith virtual address ((struct page *)VMEMMAP_START - 0x2000), which is\nbelow VMEMMAP_START as well as PCI_IO_END.\n\nThis commit fixes this bug by introducing a new variable\n\u0026apos;vmemmap_start_pfn\u0026apos; which is aligned with memory section size and using\nit to calculate vmemmap address instead of phys_ram_base.(CVE-2024-57945)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nclk: qcom: dispcc-sm6350: Add missing parent_map for a clock\n\nIf a clk_rcg2 has a parent, it should also have parent_map defined,\notherwise we\u0026apos;ll get a NULL pointer dereference when calling clk_set_rate\nlike the following:\n\n [ 3.388105] Call trace:\n [ 3.390664] qcom_find_src_index+0x3c/0x70 (P)\n [ 3.395301] qcom_find_src_index+0x1c/0x70 (L)\n [ 3.399934] _freq_tbl_determine_rate+0x48/0x100\n [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28\n [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4\n [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc\n [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc\n [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300\n [ 3.455886] clk_set_rate+0x38/0x14c\n\nAdd the parent_map property for the clock where it\u0026apos;s missing and also\nun-inline the parent_data as well to keep the matching parent_map and\nparent_data together.(CVE-2024-58080)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix racy issue from session lookup and expire\n\nIncrement the session reference count within the lock for lookup to avoid\nracy issue with session expire.(CVE-2024-58087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets\n\nThe blamed commit disabled hardware offoad of IPv6 packets with\nextension headers on devices that advertise NETIF_F_IPV6_CSUM,\nbased on the definition of that feature in skbuff.h:\n\n * * - %NETIF_F_IPV6_CSUM\n * - Driver (device) is only able to checksum plain\n * TCP or UDP packets over IPv6. These are specifically\n * unencapsulated packets of the form IPv6|TCP or\n * IPv6|UDP where the Next Header field in the IPv6\n * header is either TCP or UDP. IPv6 extension headers\n * are not supported with this feature. This feature\n * cannot be set in features for a device with\n * NETIF_F_HW_CSUM also set. This feature is being\n * DEPRECATED (see below).\n\nThe change causes skb_warn_bad_offload to fire for BIG TCP\npackets.\n\n[ 496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skb_warn_bad_offload+0xc4/0xe0\n\n[ 496.310297] ? skb_warn_bad_offload+0xc4/0xe0\n[ 496.310300] skb_checksum_help+0x129/0x1f0\n[ 496.310303] skb_csum_hwoffload_help+0x150/0x1b0\n[ 496.310306] validate_xmit_skb+0x159/0x270\n[ 496.310309] validate_xmit_skb_list+0x41/0x70\n[ 496.310312] sch_direct_xmit+0x5c/0x250\n[ 496.310317] __qdisc_run+0x388/0x620\n\nBIG TCP introduced an IPV6_TLV_JUMBO IPv6 extension header to\ncommunicate packet length, as this is an IPv6 jumbogram. But, the\nfeature is only enabled on devices that support BIG TCP TSO. The\nheader is only present for PF_PACKET taps like tcpdump, and not\ntransmitted by physical devices.\n\nFor this specific case of extension headers that are not\ntransmitted, return to the situation before the blamed commit\nand support hardware offload.\n\nipv6_has_hopopt_jumbo() tests not only whether this header is present,\nbut also that it is the only extension header before a terminal (L4)\nheader.(CVE-2025-21629)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsctp: sysctl: rto_min/max: avoid using current-\u0026gt;nsproxy\n\nAs mentioned in a previous commit of this series, using the \u0026apos;net\u0026apos;\nstructure via \u0026apos;current\u0026apos; is not recommended for different reasons:\n\n- Inconsistency: getting info from the reader\u0026apos;s/writer\u0026apos;s netns vs only\n from the opener\u0026apos;s netns.\n\n- current-\u0026gt;nsproxy can be NULL in some cases, resulting in an \u0026apos;Oops\u0026apos;\n (null-ptr-deref), e.g. when the current task is exiting, as spotted by\n syzbot [1] using acct(2).\n\nThe \u0026apos;net\u0026apos; structure can be obtained from the table-\u0026gt;data using\ncontainer_of().\n\nNote that table-\u0026gt;data could also be used directly, as this is the only\nmember needed from the \u0026apos;net\u0026apos; structure, but that would increase the size\nof this fix, to use \u0026apos;*data\u0026apos; everywhere \u0026apos;net-\u0026gt;sctp.rto_min/max\u0026apos; is used.(CVE-2025-21639)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: sysctl: sched: avoid using current-\u0026gt;nsproxy\n\nUsing the \u0026apos;net\u0026apos; structure via \u0026apos;current\u0026apos; is not recommended for different\nreasons.\n\nFirst, if the goal is to use it to read or write per-netns data, this is\ninconsistent with how the \u0026quot;generic\u0026quot; sysctl entries are doing: directly\nby only using pointers set to the table entry, e.g. table-\u0026gt;data. Linked\nto that, the per-netns data should always be obtained from the table\nlinked to the netns it had been created for, which may not coincide with\nthe reader\u0026apos;s or writer\u0026apos;s netns.\n\nAnother reason is that access to current-\u0026gt;nsproxy-\u0026gt;netns can oops if\nattempted when current-\u0026gt;nsproxy had been dropped when the current task\nis exiting. This is what syzbot found, when using acct(2):\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN PTI\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n CPU: 1 UID: 0 PID: 5924 Comm: syz-executor Not tainted 6.13.0-rc5-syzkaller-00004-gccb98ccef0e5 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125\n Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 28 48 89 fa 48 c1 ea 03 \u0026lt;80\u0026gt; 3c 02 00 0f 85 cc 02 00 00 4d 8b 7c 24 28 48 8d 84 24 c8 00 00\n RSP: 0018:ffffc900034774e8 EFLAGS: 00010206\n\n RAX: dffffc0000000000 RBX: 1ffff9200068ee9e RCX: ffffc90003477620\n RDX: 0000000000000005 RSI: ffffffff8b08f91e RDI: 0000000000000028\n RBP: 0000000000000001 R08: ffffc90003477710 R09: 0000000000000040\n R10: 0000000000000040 R11: 00000000726f7475 R12: 0000000000000000\n R13: ffffc90003477620 R14: ffffc90003477710 R15: dffffc0000000000\n FS: 0000000000000000(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fee3cd452d8 CR3: 000000007d116000 CR4: 00000000003526f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n \u0026lt;TASK\u0026gt;\n proc_sys_call_handler+0x403/0x5d0 fs/proc/proc_sysctl.c:601\n __kernel_write_iter+0x318/0xa80 fs/read_write.c:612\n __kernel_write+0xf6/0x140 fs/read_write.c:632\n do_acct_process+0xcb0/0x14a0 kernel/acct.c:539\n acct_pin_kill+0x2d/0x100 kernel/acct.c:192\n pin_kill+0x194/0x7c0 fs/fs_pin.c:44\n mnt_pin_kill+0x61/0x1e0 fs/fs_pin.c:81\n cleanup_mnt+0x3ac/0x450 fs/namespace.c:1366\n task_work_run+0x14e/0x250 kernel/task_work.c:239\n exit_task_work include/linux/task_work.h:43 [inline]\n do_exit+0xad8/0x2d70 kernel/exit.c:938\n do_group_exit+0xd3/0x2a0 kernel/exit.c:1087\n get_signal+0x2576/0x2610 kernel/signal.c:3017\n arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337\n exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218\n do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7fee3cb87a6a\n Code: Unable to access opcode bytes at 0x7fee3cb87a40.\n RSP: 002b:00007fffcccac688 EFLAGS: 00000202 ORIG_RAX: 0000000000000037\n RAX: 0000000000000000 RBX: 00007fffcccac710 RCX: 00007fee3cb87a6a\n RDX: 0000000000000041 RSI: 0000000000000000 RDI: 0000000000000003\n RBP: 0000000000000003 R08: 00007fffcccac6ac R09: 00007fffcccacac7\n R10: 00007fffcccac710 R11: 0000000000000202 R12: 00007fee3cd49500\n R13: 00007fffcccac6ac R14: 0000000000000000 R15: 00007fee3cd4b000\n \u0026lt;/TASK\u0026gt;\n Modules linked in:\n ---[ end trace 0000000000000000 ]---\n RIP: 0010:proc_scheduler+0xc6/0x3c0 net/mptcp/ctrl.c:125\n Code: 03 42 80 3c 38 00 0f 85 fe 02 00 00 4d 8b a4 24 08 09 00 00 48 b8 00 00 00 00 00 fc\n---truncated---(CVE-2025-21642)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix the maximum cell name length\n\nThe kafs filesystem limits the maximum length of a cell to 256 bytes, but a\nproblem occurs if someone actually does that: kafs tries to create a\ndirectory under /proc/net/afs/ with the name of the cell, but that fails\nwith a warning:\n\n WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405\n\nbecause procfs limits the maximum filename length to 255.\n\nHowever, the DNS limits the maximum lookup length and, by extension, the\nmaximum cell name, to 255 less two (length count and trailing NUL).\n\nFix this by limiting the maximum acceptable cellname length to 253. This\nalso allows us to be sure we can create the \u0026quot;/afs/.\u0026lt;cell\u0026gt;/\u0026quot; mountpoint too.\n\nFurther, split the YFS VL record cell name maximum to be the 256 allowed by\nthe protocol and ignore the record retrieved by YFSVL.GetCellName if it\nexceeds 253.(CVE-2025-21646)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\novl: support encoding fid from inode with no alias\n\nDmitry Safonov reported that a WARN_ON() assertion can be trigered by\nuserspace when calling inotify_show_fdinfo() for an overlayfs watched\ninode, whose dentry aliases were discarded with drop_caches.\n\nThe WARN_ON() assertion in inotify_show_fdinfo() was removed, because\nit is possible for encoding file handle to fail for other reason, but\nthe impact of failing to encode an overlayfs file handle goes beyond\nthis assertion.\n\nAs shown in the LTP test case mentioned in the link below, failure to\nencode an overlayfs file handle from a non-aliased inode also leads to\nfailure to report an fid with FAN_DELETE_SELF fanotify events.\n\nAs Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails\nif it cannot find an alias for the inode, but this failure can be fixed.\novl_encode_fh() seldom uses the alias and in the case of non-decodable\nfile handles, as is often the case with fanotify fid info,\novl_encode_fh() never needs to use the alias to encode a file handle.\n\nDefer finding an alias until it is actually needed so ovl_encode_fh()\nwill not fail in the common case of FAN_DELETE_SELF fanotify events.(CVE-2025-21654)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/eventfd: ensure io_eventfd_signal() defers another RCU period\n\nio_eventfd_do_signal() is invoked from an RCU callback, but when\ndropping the reference to the io_ev_fd, it calls io_eventfd_free()\ndirectly if the refcount drops to zero. This isn\u0026apos;t correct, as any\npotential freeing of the io_ev_fd should be deferred another RCU grace\nperiod.\n\nJust call io_eventfd_put() rather than open-code the dec-and-test and\nfree, which will correctly defer it another RCU grace period.(CVE-2025-21655)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked\n\nWhen `ksmbd_vfs_kern_path_locked` met an error and it is not the last\nentry, it will exit without restoring changed path buffer. But later this\nbuffer may be used as the filename for creation.(CVE-2025-21660)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix variable not being completed when function returns\n\nWhen cmd_alloc_index(), fails cmd_work_handler() needs\nto complete ent-\u0026gt;slotted before returning early.\nOtherwise the task which issued the command may hang:\n\n mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry\n INFO: task kworker/13:2:4055883 blocked for more than 120 seconds.\n Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n kworker/13:2 D 0 4055883 2 0x00000228\n Workqueue: events mlx5e_tx_dim_work [mlx5_core]\n Call trace:\n __switch_to+0xe8/0x150\n __schedule+0x2a8/0x9b8\n schedule+0x2c/0x88\n schedule_timeout+0x204/0x478\n wait_for_common+0x154/0x250\n wait_for_completion+0x28/0x38\n cmd_exec+0x7a0/0xa00 [mlx5_core]\n mlx5_cmd_exec+0x54/0x80 [mlx5_core]\n mlx5_core_modify_cq+0x6c/0x80 [mlx5_core]\n mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core]\n mlx5e_tx_dim_work+0x54/0x68 [mlx5_core]\n process_one_work+0x1b0/0x448\n worker_thread+0x54/0x468\n kthread+0x134/0x138\n ret_from_fork+0x10/0x18(CVE-2025-21662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: dwmac-tegra: Read iommu stream id from device tree\n\nNvidia\u0026apos;s Tegra MGBE controllers require the IOMMU \u0026quot;Stream ID\u0026quot; (SID) to be\nwritten to the MGBE_WRAP_AXI_ASID0_CTRL register.\n\nThe current driver is hard coded to use MGBE0\u0026apos;s SID for all controllers.\nThis causes softirq time outs and kernel panics when using controllers\nother than MGBE0.\n\nExample dmesg errors when an ethernet cable is connected to MGBE1:\n\n[ 116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[ 121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms\n[ 121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.\n[ 121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0\n[ 121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)\n[ 121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features\n[ 121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported\n[ 121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock\n[ 121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode\n[ 125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[ 181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n[ 181.921404] rcu: \t7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337\n[ 181.921684] rcu: \t(detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)\n[ 181.921878] Sending NMI from CPU 4 to CPUs 7:\n[ 181.921886] NMI backtrace for cpu 7\n[ 181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6\n[ 181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024\n[ 181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 181.922847] pc : handle_softirqs+0x98/0x368\n[ 181.922978] lr : __do_softirq+0x18/0x20\n[ 181.923095] sp : ffff80008003bf50\n[ 181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000\n[ 181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0\n[ 181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70\n[ 181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000\n[ 181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000\n[ 181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d\n[ 181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160\n[ 181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74\n[ 181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1\n[ 181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000\n[ 181.967591] Call trace:\n[ 181.970043] handle_softirqs+0x98/0x368 (P)\n[ 181.974240] __do_softirq+0x18/0x20\n[ 181.977743] ____do_softirq+0x14/0x28\n[ 181.981415] call_on_irq_stack+0x24/0x30\n[ 181.985180] do_softirq_own_stack+0x20/0x30\n[ 181.989379] __irq_exit_rcu+0x114/0x140\n[ 181.993142] irq_exit_rcu+0x14/0x28\n[ 181.996816] el1_interrupt+0x44/0xb8\n[ 182.000316] el1h_64_irq_handler+0x14/0x20\n[ 182.004343] el1h_64_irq+0x80/0x88\n[ 182.007755] cpuidle_enter_state+0xc4/0x4a8 (P)\n[ 182.012305] cpuidle_enter+0x3c/0x58\n[ 182.015980] cpuidle_idle_call+0x128/0x1c0\n[ 182.020005] do_idle+0xe0/0xf0\n[ 182.023155] cpu_startup_entry+0x3c/0x48\n[ 182.026917] secondary_start_kernel+0xdc/0x120\n[ 182.031379] __secondary_switched+0x74/0x78\n[ 212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.\n[ 212.985935] rcu: blocking rcu_node structures (internal RCU debug):\n[ 212.992758] Sending NMI from CPU 0 to CPUs 7:\n[ 212.998539] NMI backtrace for cpu 7\n[ 213.004304] CPU: 7 UID: 0 PI\n---truncated---(CVE-2025-21663)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: make get_first_thin use rcu-safe list first function\n\nThe documentation in rculist.h explains the absence of list_empty_rcu()\nand cautions programmers against relying on a list_empty() -\u0026gt;\nlist_first() sequence in RCU safe code. This is because each of these\nfunctions performs its own READ_ONCE() of the list head. This can lead\nto a situation where the list_empty() sees a valid list entry, but the\nsubsequent list_first() sees a different view of list head state after a\nmodification.\n\nIn the case of dm-thin, this author had a production box crash from a GP\nfault in the process_deferred_bios path. This function saw a valid list\nhead in get_first_thin() but when it subsequently dereferenced that and\nturned it into a thin_c, it got the inside of the struct pool, since the\nlist was now empty and referring to itself. The kernel on which this\noccurred printed both a warning about a refcount_t being saturated, and\na UBSAN error for an out-of-bounds cpuid access in the queued spinlock,\nprior to the fault itself. When the resulting kdump was examined, it\nwas possible to see another thread patiently waiting in thin_dtr\u0026apos;s\nsynchronize_rcu.\n\nThe thin_dtr call managed to pull the thin_c out of the active thins\nlist (and have it be the last entry in the active_thins list) at just\nthe wrong moment which lead to this crash.\n\nFortunately, the fix here is straight forward. Switch get_first_thin()\nfunction to use list_first_or_null_rcu() which performs just a single\nREAD_ONCE() and returns NULL if the list is already empty.\n\nThis was run against the devicemapper test suite\u0026apos;s thin-provisioning\nsuites for delete and suspend and no regressions were observed.(CVE-2025-21664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipmr: do not call mr_mfc_uses_dev() for unres entries\n\nsyzbot found that calling mr_mfc_uses_dev() for unres entries\nwould crash [1], because c-\u0026gt;mfc_un.res.minvif / c-\u0026gt;mfc_un.res.maxvif\nalias to \u0026quot;struct sk_buff_head unresolved\u0026quot;, which contain two pointers.\n\nThis code never worked, lets remove it.\n\n[1]\nUnable to handle kernel paging request at virtual address ffff5fff2d536613\nKASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]\nModules linked in:\nCPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline]\n pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334\n lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline]\n lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334\nCall trace:\n mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P)\n mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P)\n mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382\n ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648\n rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327\n rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791\n netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317\n netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973\n sock_recvmsg_nosec net/socket.c:1033 [inline]\n sock_recvmsg net/socket.c:1055 [inline]\n sock_read_iter+0x2d8/0x40c net/socket.c:1125\n new_sync_read fs/read_write.c:484 [inline]\n vfs_read+0x740/0x970 fs/read_write.c:565\n ksys_read+0x15c/0x26c fs/read_write.c:708(CVE-2025-21719)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Check the return value of of_property_read_string_index()\n\nSomewhen between 6.10 and 6.11 the driver started to crash on my\nMacBookPro14,3. The property doesn\u0026apos;t exist and \u0026apos;tmp\u0026apos; remains\nuninitialized, so we pass a random pointer to devm_kstrdup().\n\nThe crash I am getting looks like this:\n\nBUG: unable to handle page fault for address: 00007f033c669379\nPF: supervisor read access in kernel mode\nPF: error_code(0x0001) - permissions violation\nPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025\nOops: Oops: 0001 [#1] SMP PTI\nCPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1\nHardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024\nRIP: 0010:strlen+0x4/0x30\nCode: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa \u0026lt;80\u0026gt; 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc\nRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202\nRAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001\nRDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379\nRBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a\nR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8\nR13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30\nFS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __die+0x23/0x70\n ? page_fault_oops+0x149/0x4c0\n ? raw_spin_rq_lock_nested+0xe/0x20\n ? sched_balance_newidle+0x22b/0x3c0\n ? update_load_avg+0x78/0x770\n ? exc_page_fault+0x6f/0x150\n ? asm_exc_page_fault+0x26/0x30\n ? __pfx_pci_conf1_write+0x10/0x10\n ? strlen+0x4/0x30\n devm_kstrdup+0x25/0x70\n brcmf_of_probe+0x273/0x350 [brcmfmac](CVE-2025-21750)",
"id": "OESA-2025-1321",
"modified": "2026-08-06T11:08:25Z",
"published": "2025-03-21T11:08:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-1321"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36476"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56778"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57802"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57834"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57883"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57884"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57885"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57890"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57894"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57897"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57901"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57902"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57903"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57913"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57938"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57945"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58069"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58080"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58087"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21629"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21639"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21642"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21646"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21654"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21655"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21660"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21662"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21663"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21719"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21750"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2024-36476",
"CVE-2024-56778",
"CVE-2024-57802",
"CVE-2024-57834",
"CVE-2024-57883",
"CVE-2024-57884",
"CVE-2024-57885",
"CVE-2024-57890",
"CVE-2024-57894",
"CVE-2024-57897",
"CVE-2024-57901",
"CVE-2024-57902",
"CVE-2024-57903",
"CVE-2024-57913",
"CVE-2024-57938",
"CVE-2024-57945",
"CVE-2024-58069",
"CVE-2024-58080",
"CVE-2024-58087",
"CVE-2025-21629",
"CVE-2025-21639",
"CVE-2025-21642",
"CVE-2025-21646",
"CVE-2025-21654",
"CVE-2025-21655",
"CVE-2025-21660",
"CVE-2025-21662",
"CVE-2025-21663",
"CVE-2025-21664",
"CVE-2025-21719",
"CVE-2025-21750"
]
}
OESA-2025-2081 (CVE-2022-49377)
Vulnerability from osv_openeuler – Published: 2025-08-29 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx
blk_mq_run_hw_queues() could be run when there isn't queued request and after queue is cleaned up, at that time tagset is freed, because tagset lifetime is covered by driver, and often freed after blk_cleanup_queue() returns.
So don't touch ->tagset for figuring out current default hctx by the mapping built in request queue, so use-after-free on tagset can be avoided. Meantime this way should be fast than retrieving mapping from tagset.(CVE-2022-49377)
In the Linux kernel, the following vulnerability has been resolved:
macsec: fix UAF bug for real_dev
Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:
================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.(CVE-2022-49390)
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: don't skip expired elements during walk
There is an asymmetry between commit/abort and preparation phase if the following conditions are met:
- set is a verdict map ("1.2.3.4 : jump foo")
- timeouts are enabled
In this case, following sequence is problematic:
- element E in set S refers to chain C
- userspace requests removal of set S
- kernel does a set walk to decrement chain->use count for all elements from preparation phase
- kernel does another set walk to remove elements from the commit phase (or another walk to do a chain->use increment for all elements from abort phase)
If E has already expired in 1), it will be ignored during list walk, so its use count won't have been changed.
Then, when set is culled, ->destroy callback will zap the element via nf_tables_set_elem_destroy(), but this function is only safe for elements that have been deactivated earlier from the preparation phase: lack of earlier deactivate removes the element but leaks the chain use count, which results in a WARN splat when the chain gets removed later, plus a leak of the nft_chain structure.
Update pipapo_get() not to skip expired elements, otherwise flush command reports bogus ENOENT errors.(CVE-2023-52924)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm/fault: Fix kfence page fault reporting
copy_from_kernel_nofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copy_from_kernel_nofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults.
Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within ___do_page_fault().
This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M
Some example false negatives:
=============================== BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec
BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
The action force umount(umount -f) will attempt to kill all rpc_task even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpc_task to nfs server.
NFS CLIENT
thread1 thread2 open("file") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task / rpc_task1 / rpc_run_task rpc_wait_for_completion_task
umount -f
nfs_umount_begin
rpc_killall_tasks
rpc_signal_task
rpc_task1 been wakeup
and return -512
_nfs4_do_open // while loop ... nfs4_run_open_task / rpc_task2 / rpc_run_task rpc_wait_for_completion_task
While processing an open request, nfsd will first attempt to find or allocate an nfs4_openowner. If it finds an nfs4_openowner that is not marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since two rpc_task can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.
NFS SERVER
nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads
nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2
nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!!
nfsd4_process_open2
...
write_threads
...
nfsd_destroy_serv
nfsd_shutdown_net
nfs4_state_shutdown_net
nfs4_state_destroy_net
destroy_client
__destroy_client
// won't find oo1!!!
nfsd_shutdown_generic
nfsd_file_cache_shutdown
kmem_cache_destroy
for nfsd_file_slab
and nfsd_file_mark_slab
// bark since nfsd_file1
// and nfsd_file_mark1
// still alive
======================================================================= BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown()
Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated---(CVE-2024-56779)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: state: fix out-of-bounds read during lookup
lookup and resize can run in parallel.
The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array.
rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask;
While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {
This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again).
Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent.
The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side.
xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)
In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int.
Fix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)
In the Linux kernel, the following vulnerability has been resolved:
atm: Fix NULL pointer dereference
When MPOA_cache_impos_rcvd() receives the msg, it can trigger Null Pointer Dereference Vulnerability if both entry and holding_time are NULL. Because there is only for the situation where entry is NULL and holding_time exists, it can be passed when both entry and holding_time are NULL. If these are NULL, the entry will be passd to eg_cache_put() as parameter and it is referenced by entry->use code in it.
kasan log:
[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[ 3.326430] Call Trace:
[ 3.326725] <TASK>
[ 3.326927] ? die_addr+0x3c/0xa0
[ 3.327330] ? exc_general_protection+0x161/0x2a0
[ 3.327662] ? asm_exc_general_protection+0x26/0x30
[ 3.328214] ? vprintk_emit+0x15e/0x420
[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470
[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470
[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10
[ 3.329664] ? console_unlock+0x107/0x1d0
[ 3.329946] ? __pfx_console_unlock+0x10/0x10
[ 3.330283] ? do_syscall_64+0xa6/0x1a0
[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f
[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10
[ 3.331395] ? down_trylock+0x52/0x80
[ 3.331703] ? vprintk_emit+0x15e/0x420
[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10
[ 3.332279] ? down_trylock+0x52/0x80
[ 3.332527] ? _printk+0xbf/0x100
[ 3.332762] ? __pfx__printk+0x10/0x10
[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0
[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10
[ 3.333614] msg_from_mpoad+0x1185/0x2750
[ 3.333893] ? __build_skb_around+0x27b/0x3a0
[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10
[ 3.334501] ? __alloc_skb+0x1c0/0x310
[ 3.334809] ? __pfxallocskb+0x10/0x10
[ 3.335283] ? _raw_spin_lock+0xe0/0xe0
[ 3.335632] ? finish_wait+0x8d/0x1e0
[ 3.335975] vcc_sendmsg+0x684/0xba0
[ 3.336250] ? pfx_vcc_sendmsg+0x10/0x10
[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10
[ 3.337056] ? fdget+0x176/0x3e0
[ 3.337348] __sys_sendto+0x4a2/0x510
[ 3.337663] ? __pfxsyssendto+0x10/0x10
[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400
[ 3.338364] ? sock_ioctl+0x1bb/0x5a0
[ 3.338653] ? rseq_handle_notify_resume+0x825/0xd20
[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10
[ 3.339316] ? __pfxrseqhandle_notify_resume+0x10/0x10
[ 3.339727] ? selinux_file_ioctl+0xa4/0x260
[ 3.340166] x64_sys_sendto+0xe0/0x1c0
[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140
[ 3.340898] do_syscall_64+0xa6/0x1a0
[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 3.341533] RIP: 0033:0x44a380
[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00
[
---truncated---(CVE-2025-22018)
In the Linux kernel, the following vulnerability has been resolved:
udp: Fix memory accounting leak.
Matt Dowling reported a weird UDP memory usage issue.
Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops.
We can reproduce the issue with the script below [0]:
-
/proc/net/sockstat reports 0 pages
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 0
-
Run the script till the report reaches 524,288
python3 test.py & sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT
-
Kill the socket and confirm the number never drops
pkill python3 && sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 524288
-
(necessary since v6.0) Trigger proto_memory_pcpu_drain()
python3 test.py & sleep 1 && pkill python3
-
The number doubles
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 1048577
The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release().
When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable.
The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow.
Then, the released amount is calculated as follows:
1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().
When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().
At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4).
Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double.
This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops.
To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta.
Note that first_packet_length() also potentially has the same problem.
[0]: from socket import *
SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1
s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)
c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname())
data = b'a' * 100
while True: c.send(data)(CVE-2025-22058)
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Allocate vfinfo size for VF GUIDs when supported
Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long
Kernel warning:
------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfxmutexlock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfxnetlinklookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 _syssendmsg+0x559/0x5a0 ? pfx_sys_sendmsg+0x10/0x10 ? pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 syssendmsg+0xe4/0x150 ? pfx_syssendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? pfx_handle_pte_fault+0x10/0x10 ---truncated---(CVE-2025-22075)
In the Linux kernel, the following vulnerability has been resolved:
isofs: Prevent the use of too small fid
syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]
The handle_bytes value passed in by the reproducing program is equal to 12. In handle_to_path(), only 12 bytes of memory are allocated for the structure file_handle->f_handle member, which causes an out-of-bounds access when accessing the member parent_block of the structure isofs_fid in isofs, because accessing parent_block requires at least 16 bytes of f_handle. Here, fh_len is used to indirectly confirm that the value of handle_bytes is greater than 3 before accessing parent_block.
[1] BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class handling
This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfsc_change_class() when working with certain child qdiscs like netem or codel.
The vulnerability works as follows: 1. hfsc_change_class() checks if a class has packets (q.qlen != 0) 2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free
The fix adds a second queue length check after qdisc_peek_len() to verify the queue wasn't emptied.(CVE-2025-37797)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc
As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case).
This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)
In the Linux kernel, the following vulnerability has been resolved:
sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()
When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free.
This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek.(CVE-2025-38000)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Address reentrant enqueue adding class to eltree twice
Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.
The patch only checks the cl->cl_nactive field to determine whether
it is the first insertion or not [2], but this field is only
incremented by init_vf [3].
By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
check and insert the class twice in the eltree.
Under normal conditions, this would lead to an infinite loop in
hfsc_dequeue for the reasons we already explained in this report [5].
However, if TBF is added as root qdisc and it is configured with a
very low rate,
it can be utilized to prevent packets from being dequeued.
This behavior can be exploited to perform subsequent insertions in the
HFSC eltree and cause a UAF."
To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set.
[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)
In the Linux kernel, the following vulnerability has been resolved:
net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done
Syzbot reported a slab-use-after-free with the following call trace:
================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25
Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394
Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue.
I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1
The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited.
tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base;
simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)
Fix this by holding net reference count before encrypt.(CVE-2025-38052)
A vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.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 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 c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 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-38115)
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, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer
The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun
tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer <eth:syz_tun>, priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0
the ub was in fact a struct dev.
when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or other media when other thread changes it.
fix this by checking media_id.(CVE-2025-38184)
A vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as 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.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 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-20064).(CVE-2025-38192)
In the Linux kernel, the following vulnerability has been resolved:
md/raid1: Fix stack memory use after return in raid1_reshape
In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic.
Example access path:
raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; }
raid1_read_request() or raid1_write_request() { alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } }
mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } }
Fix: reinit conf->r1bio_pool.wait after assigning newpool.(CVE-2025-38445)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free in tipc_conn_close().
syzbot reported a null-ptr-deref in tipc_conn_close() during netns dismantle. [0]
tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls tipc_conn_close() for each tipc_conn.
The problem is that tipc_conn_close() is called after releasing the IDR lock.
At the same time, there might be tipc_conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref.
Once we release the IDR lock in tipc_topsrv_stop(), there is no guarantee that the tipc_conn is alive.
Let's hold the ref before releasing the lock and put the ref after tipc_conn_close() in tipc_topsrv_stop().
[0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435
CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)
A vulnerability was found in Linux Kernel up to 6.16-rc5 (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 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc 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-38465)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add down_write(trace_event_sem) when adding trace event
When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values.
If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel.
The addition of the event should take the trace_event_sem for write while it adds the new event.
Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list.(CVE-2025-38539)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Exit early on perf_mmap() fail
When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak.
Return early on failure to prevent that.(CVE-2025-38565)
A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).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.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb 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-38670)
| URL | Type | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"kernel-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-debugsource-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-devel-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-headers-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-source-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-tools-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"kernel-tools-devel-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"perf-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"python3-perf-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.aarch64.rpm"
],
"src": [
"kernel-5.10.0-279.0.0.181.oe2203sp3.src.rpm"
],
"x86_64": [
"kernel-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-debugsource-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-devel-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-headers-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-source-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-tools-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"kernel-tools-devel-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"perf-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"python3-perf-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-279.0.0.181.oe2203sp3.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:22.03-LTS-SP3",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.10.0-279.0.0.181.oe2203sp3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: don\u0026apos;t touch -\u0026gt;tagset in blk_mq_get_sq_hctx\n\nblk_mq_run_hw_queues() could be run when there isn\u0026apos;t queued request and\nafter queue is cleaned up, at that time tagset is freed, because tagset\nlifetime is covered by driver, and often freed after blk_cleanup_queue()\nreturns.\n\nSo don\u0026apos;t touch -\u0026gt;tagset for figuring out current default hctx by the mapping\nbuilt in request queue, so use-after-free on tagset can be avoided. Meantime\nthis way should be fast than retrieving mapping from tagset.(CVE-2022-49377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\u0026quot;net: allow out-of-order netdev unregistration\u0026quot;)\nand commit e5f80fcf869a (\u0026quot;ipv6: give an IPv6 dev to blackhole_netdev\u0026quot;), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem.(CVE-2022-49390)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: don\u0026apos;t skip expired elements during walk\n\nThere is an asymmetry between commit/abort and preparation phase if the\nfollowing conditions are met:\n\n1. set is a verdict map (\u0026quot;1.2.3.4 : jump foo\u0026quot;)\n2. timeouts are enabled\n\nIn this case, following sequence is problematic:\n\n1. element E in set S refers to chain C\n2. userspace requests removal of set S\n3. kernel does a set walk to decrement chain-\u0026gt;use count for all elements\n from preparation phase\n4. kernel does another set walk to remove elements from the commit phase\n (or another walk to do a chain-\u0026gt;use increment for all elements from\n abort phase)\n\nIf E has already expired in 1), it will be ignored during list walk, so its use count\nwon\u0026apos;t have been changed.\n\nThen, when set is culled, -\u0026gt;destroy callback will zap the element via\nnf_tables_set_elem_destroy(), but this function is only safe for\nelements that have been deactivated earlier from the preparation phase:\nlack of earlier deactivate removes the element but leaks the chain use\ncount, which results in a WARN splat when the chain gets removed later,\nplus a leak of the nft_chain structure.\n\nUpdate pipapo_get() not to skip expired elements, otherwise flush\ncommand reports bogus ENOENT errors.(CVE-2023-52924)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm/fault: Fix kfence page fault reporting\n\ncopy_from_kernel_nofault() can be called when doing read of /proc/kcore.\n/proc/kcore can have some unmapped kfence objects which when read via\ncopy_from_kernel_nofault() can cause page faults. Since *_nofault()\nfunctions define their own fixup table for handling fault, use that\ninstead of asking kfence to handle such faults.\n\nHence we search the exception tables for the nip which generated the\nfault. If there is an entry then we let the fixup table handler handle the\npage fault by returning an error from within ___do_page_fault().\n\nThis can be easily triggered if someone tries to do dd from /proc/kcore.\neg. dd if=/proc/kcore of=/dev/null bs=1M\n\nSome example false negatives:\n\n ===============================\n BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0\n Invalid read at 0xc0000000fdff0000:\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec\n\n BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0\n Use-after-free read at 0xc0000000fe050000 (in kfence-#2):\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur\n\nThe action force umount(umount -f) will attempt to kill all rpc_task even\numount operation may ultimately fail if some files remain open.\nConsequently, if an action attempts to open a file, it can potentially\nsend two rpc_task to nfs server.\n\n NFS CLIENT\nthread1 thread2\nopen(\u0026quot;file\u0026quot;)\n...\nnfs4_do_open\n _nfs4_do_open\n _nfs4_open_and_get_state\n _nfs4_proc_open\n nfs4_run_open_task\n /* rpc_task1 */\n rpc_run_task\n rpc_wait_for_completion_task\n\n umount -f\n nfs_umount_begin\n rpc_killall_tasks\n rpc_signal_task\n rpc_task1 been wakeup\n and return -512\n _nfs4_do_open // while loop\n ...\n nfs4_run_open_task\n /* rpc_task2 */\n rpc_run_task\n rpc_wait_for_completion_task\n\nWhile processing an open request, nfsd will first attempt to find or\nallocate an nfs4_openowner. If it finds an nfs4_openowner that is not\nmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since\ntwo rpc_task can attempt to open the same file simultaneously from the\nclient to server, and because two instances of nfsd can run\nconcurrently, this situation can lead to lots of memory leak.\nAdditionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be\ntriggered.\n\n NFS SERVER\nnfsd1 nfsd2 echo 0 \u0026gt; /proc/fs/nfsd/threads\n\nnfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // alloc oo1, stateid1\n nfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // find oo1, without NFS4_OO_CONFIRMED\n release_openowner\n unhash_openowner_locked\n list_del_init(\u0026amp;oo-\u0026gt;oo_perclient)\n // cannot find this oo\n // from client, LEAK!!!\n alloc_stateowner // alloc oo2\n\n nfsd4_process_open2\n init_open_stateid\n // associate oo1\n // with stateid1, stateid1 LEAK!!!\n nfs4_get_vfs_file\n // alloc nfsd_file1 and nfsd_file_mark1\n // all LEAK!!!\n\n nfsd4_process_open2\n ...\n\n write_threads\n ...\n nfsd_destroy_serv\n nfsd_shutdown_net\n nfs4_state_shutdown_net\n nfs4_state_destroy_net\n destroy_client\n __destroy_client\n // won\u0026apos;t find oo1!!!\n nfsd_shutdown_generic\n nfsd_file_cache_shutdown\n kmem_cache_destroy\n for nfsd_file_slab\n and nfsd_file_mark_slab\n // bark since nfsd_file1\n // and nfsd_file_mark1\n // still alive\n\n=======================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n-----------------------------------------------------------------------\n\nSlab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28\nflags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)\nCPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dum\n---truncated---(CVE-2024-56779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: state: fix out-of-bounds read during lookup\n\nlookup and resize can run in parallel.\n\nThe xfrm_state_hash_generation seqlock ensures a retry, but the hash\nfunctions can observe a hmask value that is too large for the new hlist\narray.\n\nrehash does:\n rcu_assign_pointer(net-\u0026gt;xfrm.state_bydst, ndst) [..]\n net-\u0026gt;xfrm.state_hmask = nhashmask;\n\nWhile state lookup does:\n h = xfrm_dst_hash(net, daddr, saddr, tmpl-\u0026gt;reqid, encap_family);\n hlist_for_each_entry_rcu(x, net-\u0026gt;xfrm.state_bydst + h, bydst) {\n\nThis is only safe in case the update to state_bydst is larger than\nnet-\u0026gt;xfrm.xfrm_state_hmask (or if the lookup function gets\nserialized via state spinlock again).\n\nFix this by prefetching state_hmask and the associated pointers.\nThe xfrm_state_hash_generation seqlock retry will ensure that the pointer\nand the hmask will be consistent.\n\nThe existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,\nadd lockdep assertions to document that they are only safe for insert\nside.\n\nxfrm_state_lookup_byaddr() uses the spinlock rather than RCU.\nAFAICS this is an oversight from back when state lookup was converted to\nRCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: Fix NULL pointer dereference\n\nWhen MPOA_cache_impos_rcvd() receives the msg, it can trigger\nNull Pointer Dereference Vulnerability if both entry and\nholding_time are NULL. Because there is only for the situation\nwhere entry is NULL and holding_time exists, it can be passed\nwhen both entry and holding_time are NULL. If these are NULL,\nthe entry will be passd to eg_cache_put() as parameter and\nit is referenced by entry-\u0026gt;use code in it.\n\nkasan log:\n\n[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I\n[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102\n[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470\n[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80\n[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006\n[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e\n[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030\n[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88\n[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15\n[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068\n[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000\n[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0\n[ 3.326430] Call Trace:\n[ 3.326725] \u0026lt;TASK\u0026gt;\n[ 3.326927] ? die_addr+0x3c/0xa0\n[ 3.327330] ? exc_general_protection+0x161/0x2a0\n[ 3.327662] ? asm_exc_general_protection+0x26/0x30\n[ 3.328214] ? vprintk_emit+0x15e/0x420\n[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470\n[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470\n[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10\n[ 3.329664] ? console_unlock+0x107/0x1d0\n[ 3.329946] ? __pfx_console_unlock+0x10/0x10\n[ 3.330283] ? do_syscall_64+0xa6/0x1a0\n[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f\n[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10\n[ 3.331395] ? down_trylock+0x52/0x80\n[ 3.331703] ? vprintk_emit+0x15e/0x420\n[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10\n[ 3.332279] ? down_trylock+0x52/0x80\n[ 3.332527] ? _printk+0xbf/0x100\n[ 3.332762] ? __pfx__printk+0x10/0x10\n[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0\n[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10\n[ 3.333614] msg_from_mpoad+0x1185/0x2750\n[ 3.333893] ? __build_skb_around+0x27b/0x3a0\n[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10\n[ 3.334501] ? __alloc_skb+0x1c0/0x310\n[ 3.334809] ? __pfx___alloc_skb+0x10/0x10\n[ 3.335283] ? _raw_spin_lock+0xe0/0xe0\n[ 3.335632] ? finish_wait+0x8d/0x1e0\n[ 3.335975] vcc_sendmsg+0x684/0xba0\n[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10\n[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10\n[ 3.337056] ? fdget+0x176/0x3e0\n[ 3.337348] __sys_sendto+0x4a2/0x510\n[ 3.337663] ? __pfx___sys_sendto+0x10/0x10\n[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400\n[ 3.338364] ? sock_ioctl+0x1bb/0x5a0\n[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20\n[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10\n[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10\n[ 3.339727] ? selinux_file_ioctl+0xa4/0x260\n[ 3.340166] __x64_sys_sendto+0xe0/0x1c0\n[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140\n[ 3.340898] do_syscall_64+0xa6/0x1a0\n[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 3.341533] RIP: 0033:0x44a380\n[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00\n[ \n---truncated---(CVE-2025-22018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix memory accounting leak.\n\nMatt Dowling reported a weird UDP memory usage issue.\n\nUnder normal operation, the UDP memory usage reported in /proc/net/sockstat\nremains close to zero. However, it occasionally spiked to 524,288 pages\nand never dropped. Moreover, the value doubled when the application was\nterminated. Finally, it caused intermittent packet drops.\n\nWe can reproduce the issue with the script below [0]:\n\n 1. /proc/net/sockstat reports 0 pages\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 0\n\n 2. Run the script till the report reaches 524,288\n\n # python3 test.py \u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 3 mem 524288 \u0026lt;-- (INT_MAX + 1) \u0026gt;\u0026gt; PAGE_SHIFT\n\n 3. Kill the socket and confirm the number never drops\n\n # pkill python3 \u0026amp;\u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 524288\n\n 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()\n\n # python3 test.py \u0026amp; sleep 1 \u0026amp;\u0026amp; pkill python3\n\n 5. The number doubles\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 1048577\n\nThe application set INT_MAX to SO_RCVBUF, which triggered an integer\noverflow in udp_rmem_release().\n\nWhen a socket is close()d, udp_destruct_common() purges its receive\nqueue and sums up skb-\u0026gt;truesize in the queue. This total is calculated\nand stored in a local unsigned integer variable.\n\nThe total size is then passed to udp_rmem_release() to adjust memory\naccounting. However, because the function takes a signed integer\nargument, the total size can wrap around, causing an overflow.\n\nThen, the released amount is calculated as follows:\n\n 1) Add size to sk-\u0026gt;sk_forward_alloc.\n 2) Round down sk-\u0026gt;sk_forward_alloc to the nearest lower multiple of\n PAGE_SIZE and assign it to amount.\n 3) Subtract amount from sk-\u0026gt;sk_forward_alloc.\n 4) Pass amount \u0026gt;\u0026gt; PAGE_SHIFT to __sk_mem_reduce_allocated().\n\nWhen the issue occurred, the total in udp_destruct_common() was 2147484480\n(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().\n\nAt 1) sk-\u0026gt;sk_forward_alloc is changed from 3264 to -2147479552, and\n2) sets -2147479552 to amount. 3) reverts the wraparound, so we don\u0026apos;t\nsee a warning in inet_sock_destruct(). However, udp_memory_allocated\nends up doubling at 4).\n\nSince commit 3cd3399dd7a8 (\u0026quot;net: implement per-cpu reserves for\nmemory_allocated\u0026quot;), memory usage no longer doubles immediately after\na socket is close()d because __sk_mem_reduce_allocated() caches the\namount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP\nsocket receives a packet, the subtraction takes effect, causing UDP\nmemory usage to double.\n\nThis issue makes further memory allocation fail once the socket\u0026apos;s\nsk-\u0026gt;sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet\ndrops.\n\nTo prevent this issue, let\u0026apos;s use unsigned int for the calculation and\ncall sk_forward_alloc_add() only once for the small delta.\n\nNote that first_packet_length() also potentially has the same problem.\n\n[0]:\nfrom socket import *\n\nSO_RCVBUFFORCE = 33\nINT_MAX = (2 ** 31) - 1\n\ns = socket(AF_INET, SOCK_DGRAM)\ns.bind((\u0026apos;\u0026apos;, 0))\ns.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)\n\nc = socket(AF_INET, SOCK_DGRAM)\nc.connect(s.getsockname())\n\ndata = b\u0026apos;a\u0026apos; * 100\n\nwhile True:\n c.send(data)(CVE-2025-22058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtnetlink: Allocate vfinfo size for VF GUIDs when supported\n\nCommit 30aad41721e0 (\u0026quot;net/core: Add support for getting VF GUIDs\u0026quot;)\nadded support for getting VF port and node GUIDs in netlink ifinfo\nmessages, but their size was not taken into consideration in the\nfunction that allocates the netlink message, causing the following\nwarning when a netlink message is filled with many VF port and node\nGUIDs:\n # echo 64 \u0026gt; /sys/bus/pci/devices/0000\\:08\\:00.0/sriov_numvfs\n # ip link show dev ib0\n RTNETLINK answers: Message too long\n Cannot send link get request: Message too long\n\nKernel warning:\n\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0\n Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core\n CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:rtnl_getlink+0x586/0x5a0\n Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff \u0026lt;0f\u0026gt; 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00\n RSP: 0018:ffff888113557348 EFLAGS: 00010246\n RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000\n RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8\n RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000\n R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00\n R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff\n FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0xa5/0x230\n ? rtnl_getlink+0x586/0x5a0\n ? report_bug+0x22d/0x240\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x14/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? skb_trim+0x6a/0x80\n ? rtnl_getlink+0x586/0x5a0\n ? __pfx_rtnl_getlink+0x10/0x10\n ? rtnetlink_rcv_msg+0x1e5/0x860\n ? __pfx___mutex_lock+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx_lock_acquire+0x10/0x10\n ? stack_trace_save+0x90/0xd0\n ? filter_irq_stacks+0x1d/0x70\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n rtnetlink_rcv_msg+0x21c/0x860\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? arch_stack_walk+0x9e/0xf0\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n ? rcu_is_watching+0x34/0x60\n netlink_rcv_skb+0xe0/0x210\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? __pfx_netlink_rcv_skb+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx___netlink_lookup+0x10/0x10\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0xfd/0x290\n ? rcu_is_watching+0x34/0x60\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0x95/0x290\n netlink_unicast+0x31f/0x480\n ? __pfx_netlink_unicast+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n netlink_sendmsg+0x369/0x660\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ? import_ubuf+0xb9/0xf0\n ? __import_iovec+0x254/0x2b0\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ____sys_sendmsg+0x559/0x5a0\n ? __pfx_____sys_sendmsg+0x10/0x10\n ? __pfx_copy_msghdr_from_user+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? do_read_fault+0x213/0x4a0\n ? rcu_is_watching+0x34/0x60\n ___sys_sendmsg+0xe4/0x150\n ? __pfx____sys_sendmsg+0x10/0x10\n ? do_fault+0x2cc/0x6f0\n ? handle_pte_fault+0x2e3/0x3d0\n ? __pfx_handle_pte_fault+0x10/0x10\n---truncated---(CVE-2025-22075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisofs: Prevent the use of too small fid\n\nsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]\n\nThe handle_bytes value passed in by the reproducing program is equal to 12.\nIn handle_to_path(), only 12 bytes of memory are allocated for the structure\nfile_handle-\u0026gt;f_handle member, which causes an out-of-bounds access when\naccessing the member parent_block of the structure isofs_fid in isofs,\nbecause accessing parent_block requires at least 16 bytes of f_handle.\nHere, fh_len is used to indirectly confirm that the value of handle_bytes\nis greater than 3 before accessing parent_block.\n\n[1]\nBUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\nRead of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466\nCPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nCall trace:\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0x198/0x550 mm/kasan/report.c:521\n kasan_report+0xd8/0x138 mm/kasan/report.c:634\n __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380\n isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\n exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523\n do_handle_to_path+0xa0/0x198 fs/fhandle.c:257\n handle_to_path fs/fhandle.c:385 [inline]\n do_handle_open+0x8cc/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n\nAllocated by task 6466:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4294 [inline]\n __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306\n kmalloc_noprof include/linux/slab.h:905 [inline]\n handle_to_path fs/fhandle.c:357 [inline]\n do_handle_open+0x5a4/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class handling\n\nThis patch fixes a Use-After-Free vulnerability in the HFSC qdisc class\nhandling. The issue occurs due to a time-of-check/time-of-use condition\nin hfsc_change_class() when working with certain child qdiscs like netem\nor codel.\n\nThe vulnerability works as follows:\n1. hfsc_change_class() checks if a class has packets (q.qlen != 0)\n2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,\n codel, netem) might drop packets and empty the queue\n3. The code continues assuming the queue is still non-empty, adding\n the class to vttree\n4. This breaks HFSC scheduler assumptions that only non-empty classes\n are in vttree\n5. Later, when the class is destroyed, this can lead to a Use-After-Free\n\nThe fix adds a second queue length check after qdisc_peek_len() to verify\nthe queue wasn\u0026apos;t emptied.(CVE-2025-37797)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], we have a UAF case when an hfsc class\nhas a netem child qdisc. The crux of the issue is that hfsc is assuming\nthat checking for cl-\u0026gt;qdisc-\u0026gt;q.qlen == 0 guarantees that it hasn\u0026apos;t inserted\nthe class in the vttree or eltree (which is not true for the netem\nduplicate case).\n\nThis patch checks the n_active class variable to make sure that the code\nwon\u0026apos;t insert the class in the vttree or eltree twice, catering for the\nreentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()\n\nWhen enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the\nchild qdisc\u0026apos;s peek() operation before incrementing sch-\u0026gt;q.qlen and\nsch-\u0026gt;qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may\ntrigger an immediate dequeue and potential packet drop. In such cases,\nqdisc_tree_reduce_backlog() is called, but the HFSC qdisc\u0026apos;s qlen and backlog\nhave not yet been updated, leading to inconsistent queue accounting. This\ncan leave an empty HFSC class in the active list, causing further\nconsequences like use-after-free.\n\nThis patch fixes the bug by moving the increment of sch-\u0026gt;q.qlen and\nsch-\u0026gt;qstats.backlog before the call to the child qdisc\u0026apos;s peek() operation.\nThis ensures that queue length and backlog are always accurate when packet\ndrops or dequeues are triggered during the peek.(CVE-2025-38000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Address reentrant enqueue adding class to eltree twice\n\nSavino says:\n \u0026quot;We are writing to report that this recent patch\n (141d34391abbb315d68556b7c67ad97885407547) [1]\n can be bypassed, and a UAF can still occur when HFSC is utilized with\n NETEM.\n\n The patch only checks the cl-\u0026gt;cl_nactive field to determine whether\n it is the first insertion or not [2], but this field is only\n incremented by init_vf [3].\n\n By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the\n check and insert the class twice in the eltree.\n Under normal conditions, this would lead to an infinite loop in\n hfsc_dequeue for the reasons we already explained in this report [5].\n\n However, if TBF is added as root qdisc and it is configured with a\n very low rate,\n it can be utilized to prevent packets from being dequeued.\n This behavior can be exploited to perform subsequent insertions in the\n HFSC eltree and cause a UAF.\u0026quot;\n\nTo fix both the UAF and the infinite loop, with netem as an hfsc child,\ncheck explicitly in hfsc_enqueue whether the class is already in the eltree\nwhenever the HFSC_RSC flag is set.\n\n[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547\n[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572\n[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677\n[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574\n[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\n\nSyzbot reported a slab-use-after-free with the following call trace:\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25\n\n Call Trace:\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n crypto_request_complete include/crypto/algapi.h:266\n aead_request_complete include/crypto/internal/aead.h:85\n cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772\n crypto_request_complete include/crypto/algapi.h:266\n cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\n Allocated by task 8355:\n kzalloc_noprof include/linux/slab.h:778\n tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466\n tipc_init_net+0x2dd/0x430 net/tipc/core.c:72\n ops_init+0xb9/0x650 net/core/net_namespace.c:139\n setup_net+0x435/0xb40 net/core/net_namespace.c:343\n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228\n ksys_unshare+0x419/0x970 kernel/fork.c:3323\n __do_sys_unshare kernel/fork.c:3394\n\n Freed by task 63:\n kfree+0x12a/0x3b0 mm/slub.c:4557\n tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539\n tipc_exit_net+0x8c/0x110 net/tipc/core.c:119\n ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173\n cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\nAfter freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done\nmay still visit it in cryptd_queue_worker workqueue.\n\nI reproduce this issue by:\n ip netns add ns1\n ip link add veth1 type veth peer name veth2\n ip link set veth1 netns ns1\n ip netns exec ns1 tipc bearer enable media eth dev veth1\n ip netns exec ns1 tipc node set key this_is_a_master_key master\n ip netns exec ns1 tipc bearer disable media eth dev veth1\n ip netns del ns1\n\nThe key of reproduction is that, simd_aead_encrypt is interrupted, leading\nto crypto_simd_usable() return false. Thus, the cryptd_queue_worker is\ntriggered, and the tipc_crypto tx will be visited.\n\n tipc_disc_timeout\n tipc_bearer_xmit_skb\n tipc_crypto_xmit\n tipc_aead_encrypt\n crypto_aead_encrypt\n // encrypt()\n simd_aead_encrypt\n // crypto_simd_usable() is false\n child = \u0026amp;ctx-\u0026gt;cryptd_tfm-\u0026gt;base;\n\n simd_aead_encrypt\n crypto_aead_encrypt\n // encrypt()\n cryptd_aead_encrypt_enqueue\n cryptd_aead_enqueue\n cryptd_enqueue_request\n // trigger cryptd_queue_worker\n queue_work_on(smp_processor_id(), cryptd_wq, \u0026amp;cpu_queue-\u0026gt;work)\n\nFix this by holding net reference count before encrypt.(CVE-2025-38052)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.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 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 c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 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-38115)\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, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer\n\nThe reproduction steps:\n1. create a tun interface\n2. enable l2 bearer\n3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun\n\ntipc: Started in network mode\ntipc: Node identity 8af312d38a21, cluster identity 4711\ntipc: Enabled bearer \u0026lt;eth:syz_tun\u0026gt;, priority 1\nOops: general protection fault\nKASAN: null-ptr-deref in range\nCPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT\nHardware name: QEMU Ubuntu 24.04 PC\nRIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0\n\nthe ub was in fact a struct dev.\n\nwhen bid != 0 \u0026amp;\u0026amp; skip_cnt != 0, bearer_list[bid] may be NULL or\nother media when other thread changes it.\n\nfix this by checking media_id.(CVE-2025-38184)\n\nA vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as 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.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 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-20064).(CVE-2025-38192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1: Fix stack memory use after return in raid1_reshape\n\nIn the raid1_reshape function, newpool is\nallocated on the stack and assigned to conf-\u0026gt;r1bio_pool.\nThis results in conf-\u0026gt;r1bio_pool.wait.head pointing\nto a stack address.\nAccessing this address later can lead to a kernel panic.\n\nExample access path:\n\nraid1_reshape()\n{\n\t// newpool is on the stack\n\tmempool_t newpool, oldpool;\n\t// initialize newpool.wait.head to stack address\n\tmempool_init(\u0026amp;newpool, ...);\n\tconf-\u0026gt;r1bio_pool = newpool;\n}\n\nraid1_read_request() or raid1_write_request()\n{\n\talloc_r1bio()\n\t{\n\t\tmempool_alloc()\n\t\t{\n\t\t\t// if pool-\u0026gt;alloc fails\n\t\t\tremove_element()\n\t\t\t{\n\t\t\t\t--pool-\u0026gt;curr_nr;\n\t\t\t}\n\t\t}\n\t}\n}\n\nmempool_free()\n{\n\tif (pool-\u0026gt;curr_nr \u0026lt; pool-\u0026gt;min_nr) {\n\t\t// pool-\u0026gt;wait.head is a stack address\n\t\t// wake_up() will try to access this invalid address\n\t\t// which leads to a kernel panic\n\t\treturn;\n\t\twake_up(\u0026amp;pool-\u0026gt;wait);\n\t}\n}\n\nFix:\nreinit conf-\u0026gt;r1bio_pool.wait after assigning newpool.(CVE-2025-38445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free in tipc_conn_close().\n\nsyzbot reported a null-ptr-deref in tipc_conn_close() during netns\ndismantle. [0]\n\ntipc_topsrv_stop() iterates tipc_net(net)-\u0026gt;topsrv-\u0026gt;conn_idr and calls\ntipc_conn_close() for each tipc_conn.\n\nThe problem is that tipc_conn_close() is called after releasing the\nIDR lock.\n\nAt the same time, there might be tipc_conn_recv_work() running and it\ncould call tipc_conn_close() for the same tipc_conn and release its\nlast -\u0026gt;kref.\n\nOnce we release the IDR lock in tipc_topsrv_stop(), there is no\nguarantee that the tipc_conn is alive.\n\nLet\u0026apos;s hold the ref before releasing the lock and put the ref after\ntipc_conn_close() in tipc_topsrv_stop().\n\n[0]:\nBUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\nRead of size 8 at addr ffff888099305a08 by task kworker/u4:3/435\n\nCPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: netns cleanup_net\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x1fc/0x2ef lib/dump_stack.c:118\n print_address_description.cold+0x54/0x219 mm/kasan/report.c:256\n kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354\n kasan_report mm/kasan/report.c:412 [inline]\n __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433\n tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\n tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]\n tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722\n ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153\n cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nAllocated by task 23:\n kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625\n kmalloc include/linux/slab.h:515 [inline]\n kzalloc include/linux/slab.h:709 [inline]\n tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192\n tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nFreed by task 23:\n __cache_free mm/slab.c:3503 [inline]\n kfree+0xcc/0x210 mm/slab.c:3822\n tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]\n kref_put include/linux/kref.h:70 [inline]\n conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nThe buggy address belongs to the object at ffff888099305a00\n which belongs to the cache kmalloc-512 of size 512\nThe buggy address is located 8 bytes inside of\n 512-byte region [ffff888099305a00, ffff888099305c00)\nThe buggy address belongs to the page:\npage:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0\nflags: 0xfff00000000100(slab)\nraw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940\nraw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n\u0026gt;ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ^\n ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc5 (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 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc 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-38465)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add down_write(trace_event_sem) when adding trace event\n\nWhen a module is loaded, it adds trace events defined by the module. It\nmay also need to modify the modules trace printk formats to replace enum\nnames with their values.\n\nIf two modules are loaded at the same time, the adding of the event to the\nftrace_events list can corrupt the walking of the list in the code that is\nmodifying the printk format strings and crash the kernel.\n\nThe addition of the event should take the trace_event_sem for write while\nit adds the new event.\n\nAlso add a lockdep_assert_held() on that semaphore in\n__trace_add_event_dirs() as it iterates the list.(CVE-2025-38539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Exit early on perf_mmap() fail\n\nWhen perf_mmap() fails to allocate a buffer, it still invokes the\nevent_mapped() callback of the related event. On X86 this might increase\nthe perf_rdpmc_allowed reference counter. But nothing undoes this as\nperf_mmap_close() is never called in this case, which causes another\nreference count leak.\n\nReturn early on failure to prevent that.(CVE-2025-38565)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).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.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb 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-38670)",
"id": "OESA-2025-2081",
"modified": "2026-08-06T11:09:09Z",
"published": "2025-08-29T11:09:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2081"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49377"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49390"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56779"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58069"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37780"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37797"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37890"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38115"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38124"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38445"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38464"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38465"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38539"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38670"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49377",
"CVE-2022-49390",
"CVE-2023-52924",
"CVE-2024-56678",
"CVE-2024-56779",
"CVE-2024-57982",
"CVE-2024-58069",
"CVE-2025-21687",
"CVE-2025-22018",
"CVE-2025-22058",
"CVE-2025-22075",
"CVE-2025-37780",
"CVE-2025-37797",
"CVE-2025-37890",
"CVE-2025-38000",
"CVE-2025-38001",
"CVE-2025-38052",
"CVE-2025-38115",
"CVE-2025-38124",
"CVE-2025-38184",
"CVE-2025-38192",
"CVE-2025-38445",
"CVE-2025-38464",
"CVE-2025-38465",
"CVE-2025-38539",
"CVE-2025-38565",
"CVE-2025-38670"
]
}
OESA-2025-2082 (CVE-2022-49377)
Vulnerability from osv_openeuler – Published: 2025-08-29 11:09 – Updated: 2026-08-06 11:09 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx
blk_mq_run_hw_queues() could be run when there isn't queued request and after queue is cleaned up, at that time tagset is freed, because tagset lifetime is covered by driver, and often freed after blk_cleanup_queue() returns.
So don't touch ->tagset for figuring out current default hctx by the mapping built in request queue, so use-after-free on tagset can be avoided. Meantime this way should be fast than retrieving mapping from tagset.(CVE-2022-49377)
In the Linux kernel, the following vulnerability has been resolved:
macsec: fix UAF bug for real_dev
Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following:
================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161
Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748
Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327
After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem.(CVE-2022-49390)
In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm/fault: Fix kfence page fault reporting
copy_from_kernel_nofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copy_from_kernel_nofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults.
Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within ___do_page_fault().
This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M
Some example false negatives:
=============================== BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec
BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur
The action force umount(umount -f) will attempt to kill all rpc_task even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpc_task to nfs server.
NFS CLIENT
thread1 thread2 open("file") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task / rpc_task1 / rpc_run_task rpc_wait_for_completion_task
umount -f
nfs_umount_begin
rpc_killall_tasks
rpc_signal_task
rpc_task1 been wakeup
and return -512
_nfs4_do_open // while loop ... nfs4_run_open_task / rpc_task2 / rpc_run_task rpc_wait_for_completion_task
While processing an open request, nfsd will first attempt to find or allocate an nfs4_openowner. If it finds an nfs4_openowner that is not marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since two rpc_task can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.
NFS SERVER
nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads
nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2
nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!!
nfsd4_process_open2
...
write_threads
...
nfsd_destroy_serv
nfsd_shutdown_net
nfs4_state_shutdown_net
nfs4_state_destroy_net
destroy_client
__destroy_client
// won't find oo1!!!
nfsd_shutdown_generic
nfsd_file_cache_shutdown
kmem_cache_destroy
for nfsd_file_slab
and nfsd_file_mark_slab
// bark since nfsd_file1
// and nfsd_file_mark1
// still alive
======================================================================= BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown()
Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated---(CVE-2024-56779)
In the Linux kernel, the following vulnerability has been resolved:
xfrm: state: fix out-of-bounds read during lookup
lookup and resize can run in parallel.
The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array.
rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask;
While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {
This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again).
Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent.
The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side.
xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)
In the Linux kernel, the following vulnerability has been resolved:
rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read
The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int.
Fix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.(CVE-2025-21687)
In the Linux kernel, the following vulnerability has been resolved:
atm: Fix NULL pointer dereference
When MPOA_cache_impos_rcvd() receives the msg, it can trigger Null Pointer Dereference Vulnerability if both entry and holding_time are NULL. Because there is only for the situation where entry is NULL and holding_time exists, it can be passed when both entry and holding_time are NULL. If these are NULL, the entry will be passd to eg_cache_put() as parameter and it is referenced by entry->use code in it.
kasan log:
[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I
[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102
[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470
[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80
[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006
[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e
[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030
[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88
[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15
[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068
[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000
[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0
[ 3.326430] Call Trace:
[ 3.326725] <TASK>
[ 3.326927] ? die_addr+0x3c/0xa0
[ 3.327330] ? exc_general_protection+0x161/0x2a0
[ 3.327662] ? asm_exc_general_protection+0x26/0x30
[ 3.328214] ? vprintk_emit+0x15e/0x420
[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470
[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470
[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10
[ 3.329664] ? console_unlock+0x107/0x1d0
[ 3.329946] ? __pfx_console_unlock+0x10/0x10
[ 3.330283] ? do_syscall_64+0xa6/0x1a0
[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f
[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10
[ 3.331395] ? down_trylock+0x52/0x80
[ 3.331703] ? vprintk_emit+0x15e/0x420
[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10
[ 3.332279] ? down_trylock+0x52/0x80
[ 3.332527] ? _printk+0xbf/0x100
[ 3.332762] ? __pfx__printk+0x10/0x10
[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0
[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10
[ 3.333614] msg_from_mpoad+0x1185/0x2750
[ 3.333893] ? __build_skb_around+0x27b/0x3a0
[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10
[ 3.334501] ? __alloc_skb+0x1c0/0x310
[ 3.334809] ? __pfxallocskb+0x10/0x10
[ 3.335283] ? _raw_spin_lock+0xe0/0xe0
[ 3.335632] ? finish_wait+0x8d/0x1e0
[ 3.335975] vcc_sendmsg+0x684/0xba0
[ 3.336250] ? pfx_vcc_sendmsg+0x10/0x10
[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10
[ 3.337056] ? fdget+0x176/0x3e0
[ 3.337348] __sys_sendto+0x4a2/0x510
[ 3.337663] ? __pfxsyssendto+0x10/0x10
[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400
[ 3.338364] ? sock_ioctl+0x1bb/0x5a0
[ 3.338653] ? rseq_handle_notify_resume+0x825/0xd20
[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10
[ 3.339316] ? __pfxrseqhandle_notify_resume+0x10/0x10
[ 3.339727] ? selinux_file_ioctl+0xa4/0x260
[ 3.340166] x64_sys_sendto+0xe0/0x1c0
[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140
[ 3.340898] do_syscall_64+0xa6/0x1a0
[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f
[ 3.341533] RIP: 0033:0x44a380
[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00
[
---truncated---(CVE-2025-22018)
In the Linux kernel, the following vulnerability has been resolved:
udp: Fix memory accounting leak.
Matt Dowling reported a weird UDP memory usage issue.
Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops.
We can reproduce the issue with the script below [0]:
-
/proc/net/sockstat reports 0 pages
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 0
-
Run the script till the report reaches 524,288
python3 test.py & sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT
-
Kill the socket and confirm the number never drops
pkill python3 && sleep 5
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 524288
-
(necessary since v6.0) Trigger proto_memory_pcpu_drain()
python3 test.py & sleep 1 && pkill python3
-
The number doubles
cat /proc/net/sockstat | grep UDP:
UDP: inuse 1 mem 1048577
The application set INT_MAX to SO_RCVBUF, which triggered an integer overflow in udp_rmem_release().
When a socket is close()d, udp_destruct_common() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable.
The total size is then passed to udp_rmem_release() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow.
Then, the released amount is calculated as follows:
1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().
When the issue occurred, the total in udp_destruct_common() was 2147484480 (INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().
At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inet_sock_destruct(). However, udp_memory_allocated ends up doubling at 4).
Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memory_allocated"), memory usage no longer doubles immediately after a socket is close()d because __sk_mem_reduce_allocated() caches the amount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double.
This issue makes further memory allocation fail once the socket's sk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet drops.
To prevent this issue, let's use unsigned int for the calculation and call sk_forward_alloc_add() only once for the small delta.
Note that first_packet_length() also potentially has the same problem.
[0]: from socket import *
SO_RCVBUFFORCE = 33 INT_MAX = (2 ** 31) - 1
s = socket(AF_INET, SOCK_DGRAM) s.bind(('', 0)) s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)
c = socket(AF_INET, SOCK_DGRAM) c.connect(s.getsockname())
data = b'a' * 100
while True: c.send(data)(CVE-2025-22058)
In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Allocate vfinfo size for VF GUIDs when supported
Commit 30aad41721e0 ("net/core: Add support for getting VF GUIDs") added support for getting VF port and node GUIDs in netlink ifinfo messages, but their size was not taken into consideration in the function that allocates the netlink message, causing the following warning when a netlink message is filled with many VF port and node GUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too long
Kernel warning:
------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfxmutexlock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfxnetlinklookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 _syssendmsg+0x559/0x5a0 ? pfx_sys_sendmsg+0x10/0x10 ? pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 syssendmsg+0xe4/0x150 ? pfx_syssendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? pfx_handle_pte_fault+0x10/0x10 ---truncated---(CVE-2025-22075)
In the Linux kernel, the following vulnerability has been resolved:
isofs: Prevent the use of too small fid
syzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]
The handle_bytes value passed in by the reproducing program is equal to 12. In handle_to_path(), only 12 bytes of memory are allocated for the structure file_handle->f_handle member, which causes an out-of-bounds access when accessing the member parent_block of the structure isofs_fid in isofs, because accessing parent_block requires at least 16 bytes of f_handle. Here, fh_len is used to indirectly confirm that the value of handle_bytes is greater than 3 before accessing parent_block.
[1] BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466 CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600
Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class handling
This patch fixes a Use-After-Free vulnerability in the HFSC qdisc class handling. The issue occurs due to a time-of-check/time-of-use condition in hfsc_change_class() when working with certain child qdiscs like netem or codel.
The vulnerability works as follows: 1. hfsc_change_class() checks if a class has packets (q.qlen != 0) 2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g., codel, netem) might drop packets and empty the queue 3. The code continues assuming the queue is still non-empty, adding the class to vttree 4. This breaks HFSC scheduler assumptions that only non-empty classes are in vttree 5. Later, when the class is destroyed, this can lead to a Use-After-Free
The fix adds a second queue length check after qdisc_peek_len() to verify the queue wasn't emptied.(CVE-2025-37797)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc
As described in Gerrard's report [1], we have a UAF case when an hfsc class has a netem child qdisc. The crux of the issue is that hfsc is assuming that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted the class in the vttree or eltree (which is not true for the netem duplicate case).
This patch checks the n_active class variable to make sure that the code won't insert the class in the vttree or eltree twice, catering for the reentrant case.
[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)
In the Linux kernel, the following vulnerability has been resolved:
sch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()
When enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the child qdisc's peek() operation before incrementing sch->q.qlen and sch->qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may trigger an immediate dequeue and potential packet drop. In such cases, qdisc_tree_reduce_backlog() is called, but the HFSC qdisc's qlen and backlog have not yet been updated, leading to inconsistent queue accounting. This can leave an empty HFSC class in the active list, causing further consequences like use-after-free.
This patch fixes the bug by moving the increment of sch->q.qlen and sch->qstats.backlog before the call to the child qdisc's peek() operation. This ensures that queue length and backlog are always accurate when packet drops or dequeues are triggered during the peek.(CVE-2025-38000)
In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Address reentrant enqueue adding class to eltree twice
Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.
The patch only checks the cl->cl_nactive field to determine whether
it is the first insertion or not [2], but this field is only
incremented by init_vf [3].
By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
check and insert the class twice in the eltree.
Under normal conditions, this would lead to an infinite loop in
hfsc_dequeue for the reasons we already explained in this report [5].
However, if TBF is added as root qdisc and it is configured with a
very low rate,
it can be utilized to prevent packets from being dequeued.
This behavior can be exploited to perform subsequent insertions in the
HFSC eltree and cause a UAF."
To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set.
[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)
In the Linux kernel, the following vulnerability has been resolved:
net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done
Syzbot reported a slab-use-after-free with the following call trace:
================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25
Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394
Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done may still visit it in cryptd_queue_worker workqueue.
I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1
The key of reproduction is that, simd_aead_encrypt is interrupted, leading to crypto_simd_usable() return false. Thus, the cryptd_queue_worker is triggered, and the tipc_crypto tx will be visited.
tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base;
simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)
Fix this by holding net reference count before encrypt.(CVE-2025-38052)
A vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.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 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 c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 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-38115)
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, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer
The reproduction steps: 1. create a tun interface 2. enable l2 bearer 3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun
tipc: Started in network mode tipc: Node identity 8af312d38a21, cluster identity 4711 tipc: Enabled bearer <eth:syz_tun>, priority 1 Oops: general protection fault KASAN: null-ptr-deref in range CPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT Hardware name: QEMU Ubuntu 24.04 PC RIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0
the ub was in fact a struct dev.
when bid != 0 && skip_cnt != 0, bearer_list[bid] may be NULL or other media when other thread changes it.
fix this by checking media_id.(CVE-2025-38184)
A vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as 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.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 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-20064).(CVE-2025-38192)
In the Linux kernel, the following vulnerability has been resolved:
md/raid1: Fix stack memory use after return in raid1_reshape
In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic.
Example access path:
raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool; }
raid1_read_request() or raid1_write_request() { alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } } }
mempool_free() { if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); } }
Fix: reinit conf->r1bio_pool.wait after assigning newpool.(CVE-2025-38445)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Fix use-after-free in tipc_conn_close().
syzbot reported a null-ptr-deref in tipc_conn_close() during netns dismantle. [0]
tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and calls tipc_conn_close() for each tipc_conn.
The problem is that tipc_conn_close() is called after releasing the IDR lock.
At the same time, there might be tipc_conn_recv_work() running and it could call tipc_conn_close() for the same tipc_conn and release its last ->kref.
Once we release the IDR lock in tipc_topsrv_stop(), there is no guarantee that the tipc_conn is alive.
Let's hold the ref before releasing the lock and put the ref after tipc_conn_close() in tipc_topsrv_stop().
[0]: BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435
CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415
The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00) The buggy address belongs to the page: page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0 flags: 0xfff00000000100(slab) raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940 raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000 page dumped because: kasan: bad access detected
Memory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)
A vulnerability was found in Linux Kernel up to 6.16-rc5 (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 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc 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-38465)
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add down_write(trace_event_sem) when adding trace event
When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values.
If two modules are loaded at the same time, the adding of the event to the ftrace_events list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel.
The addition of the event should take the trace_event_sem for write while it adds the new event.
Also add a lockdep_assert_held() on that semaphore in __trace_add_event_dirs() as it iterates the list.(CVE-2025-38539)
In the Linux kernel, the following vulnerability has been resolved:
perf/core: Exit early on perf_mmap() fail
When perf_mmap() fails to allocate a buffer, it still invokes the event_mapped() callback of the related event. On X86 this might increase the perf_rdpmc_allowed reference counter. But nothing undoes this as perf_mmap_close() is never called in this case, which causes another reference count leak.
Return early on failure to prevent that.(CVE-2025-38565)
A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).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.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb 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-38670)
| URL | Type | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"perf-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-279.0.0.182.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-279.0.0.182.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"perf-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-279.0.0.182.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-279.0.0.182.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-279.0.0.182.oe2203sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: don\u0026apos;t touch -\u0026gt;tagset in blk_mq_get_sq_hctx\n\nblk_mq_run_hw_queues() could be run when there isn\u0026apos;t queued request and\nafter queue is cleaned up, at that time tagset is freed, because tagset\nlifetime is covered by driver, and often freed after blk_cleanup_queue()\nreturns.\n\nSo don\u0026apos;t touch -\u0026gt;tagset for figuring out current default hctx by the mapping\nbuilt in request queue, so use-after-free on tagset can be avoided. Meantime\nthis way should be fast than retrieving mapping from tagset.(CVE-2022-49377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\u0026quot;net: allow out-of-order netdev unregistration\u0026quot;)\nand commit e5f80fcf869a (\u0026quot;ipv6: give an IPv6 dev to blackhole_netdev\u0026quot;), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem.(CVE-2022-49390)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/mm/fault: Fix kfence page fault reporting\n\ncopy_from_kernel_nofault() can be called when doing read of /proc/kcore.\n/proc/kcore can have some unmapped kfence objects which when read via\ncopy_from_kernel_nofault() can cause page faults. Since *_nofault()\nfunctions define their own fixup table for handling fault, use that\ninstead of asking kfence to handle such faults.\n\nHence we search the exception tables for the nip which generated the\nfault. If there is an entry then we let the fixup table handler handle the\npage fault by returning an error from within ___do_page_fault().\n\nThis can be easily triggered if someone tries to do dd from /proc/kcore.\neg. dd if=/proc/kcore of=/dev/null bs=1M\n\nSome example false negatives:\n\n ===============================\n BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0\n Invalid read at 0xc0000000fdff0000:\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec\n\n BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0\n Use-after-free read at 0xc0000000fe050000 (in kfence-#2):\n copy_from_kernel_nofault+0x9c/0x1a0\n 0xc00000000665f950\n read_kcore_iter+0x57c/0xa04\n proc_reg_read_iter+0xe4/0x16c\n vfs_read+0x320/0x3ec\n ksys_read+0x90/0x154\n system_call_exception+0x120/0x310\n system_call_vectored_common+0x15c/0x2ec(CVE-2024-56678)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur\n\nThe action force umount(umount -f) will attempt to kill all rpc_task even\numount operation may ultimately fail if some files remain open.\nConsequently, if an action attempts to open a file, it can potentially\nsend two rpc_task to nfs server.\n\n NFS CLIENT\nthread1 thread2\nopen(\u0026quot;file\u0026quot;)\n...\nnfs4_do_open\n _nfs4_do_open\n _nfs4_open_and_get_state\n _nfs4_proc_open\n nfs4_run_open_task\n /* rpc_task1 */\n rpc_run_task\n rpc_wait_for_completion_task\n\n umount -f\n nfs_umount_begin\n rpc_killall_tasks\n rpc_signal_task\n rpc_task1 been wakeup\n and return -512\n _nfs4_do_open // while loop\n ...\n nfs4_run_open_task\n /* rpc_task2 */\n rpc_run_task\n rpc_wait_for_completion_task\n\nWhile processing an open request, nfsd will first attempt to find or\nallocate an nfs4_openowner. If it finds an nfs4_openowner that is not\nmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since\ntwo rpc_task can attempt to open the same file simultaneously from the\nclient to server, and because two instances of nfsd can run\nconcurrently, this situation can lead to lots of memory leak.\nAdditionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be\ntriggered.\n\n NFS SERVER\nnfsd1 nfsd2 echo 0 \u0026gt; /proc/fs/nfsd/threads\n\nnfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // alloc oo1, stateid1\n nfsd4_open\n nfsd4_process_open1\n find_or_alloc_open_stateowner\n // find oo1, without NFS4_OO_CONFIRMED\n release_openowner\n unhash_openowner_locked\n list_del_init(\u0026amp;oo-\u0026gt;oo_perclient)\n // cannot find this oo\n // from client, LEAK!!!\n alloc_stateowner // alloc oo2\n\n nfsd4_process_open2\n init_open_stateid\n // associate oo1\n // with stateid1, stateid1 LEAK!!!\n nfs4_get_vfs_file\n // alloc nfsd_file1 and nfsd_file_mark1\n // all LEAK!!!\n\n nfsd4_process_open2\n ...\n\n write_threads\n ...\n nfsd_destroy_serv\n nfsd_shutdown_net\n nfs4_state_shutdown_net\n nfs4_state_destroy_net\n destroy_client\n __destroy_client\n // won\u0026apos;t find oo1!!!\n nfsd_shutdown_generic\n nfsd_file_cache_shutdown\n kmem_cache_destroy\n for nfsd_file_slab\n and nfsd_file_mark_slab\n // bark since nfsd_file1\n // and nfsd_file_mark1\n // still alive\n\n=======================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n-----------------------------------------------------------------------\n\nSlab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28\nflags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)\nCPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dum\n---truncated---(CVE-2024-56779)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: state: fix out-of-bounds read during lookup\n\nlookup and resize can run in parallel.\n\nThe xfrm_state_hash_generation seqlock ensures a retry, but the hash\nfunctions can observe a hmask value that is too large for the new hlist\narray.\n\nrehash does:\n rcu_assign_pointer(net-\u0026gt;xfrm.state_bydst, ndst) [..]\n net-\u0026gt;xfrm.state_hmask = nhashmask;\n\nWhile state lookup does:\n h = xfrm_dst_hash(net, daddr, saddr, tmpl-\u0026gt;reqid, encap_family);\n hlist_for_each_entry_rcu(x, net-\u0026gt;xfrm.state_bydst + h, bydst) {\n\nThis is only safe in case the update to state_bydst is larger than\nnet-\u0026gt;xfrm.xfrm_state_hmask (or if the lookup function gets\nserialized via state spinlock again).\n\nFix this by prefetching state_hmask and the associated pointers.\nThe xfrm_state_hash_generation seqlock retry will ensure that the pointer\nand the hmask will be consistent.\n\nThe existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,\nadd lockdep assertions to document that they are only safe for insert\nside.\n\nxfrm_state_lookup_byaddr() uses the spinlock rather than RCU.\nAFAICS this is an oversight from back when state lookup was converted to\nRCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read\n\nThe nvmem interface supports variable buffer sizes, while the regmap\ninterface operates with fixed-size storage. If an nvmem client uses a\nbuffer size less than 4 bytes, regmap_read will write out of bounds\nas it expects the buffer to point at an unsigned int.\n\nFix this by using an intermediary unsigned int to hold the value.(CVE-2024-58069)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfio/platform: check the bounds of read/write syscalls\n\ncount and offset are passed from user space and not checked, only\noffset is capped to 40 bits, which can be used to read/write out of\nbounds of the device.(CVE-2025-21687)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: Fix NULL pointer dereference\n\nWhen MPOA_cache_impos_rcvd() receives the msg, it can trigger\nNull Pointer Dereference Vulnerability if both entry and\nholding_time are NULL. Because there is only for the situation\nwhere entry is NULL and holding_time exists, it can be passed\nwhen both entry and holding_time are NULL. If these are NULL,\nthe entry will be passd to eg_cache_put() as parameter and\nit is referenced by entry-\u0026gt;use code in it.\n\nkasan log:\n\n[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I\n[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102\n[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470\n[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80\n[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006\n[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e\n[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030\n[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88\n[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15\n[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068\n[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000\n[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0\n[ 3.326430] Call Trace:\n[ 3.326725] \u0026lt;TASK\u0026gt;\n[ 3.326927] ? die_addr+0x3c/0xa0\n[ 3.327330] ? exc_general_protection+0x161/0x2a0\n[ 3.327662] ? asm_exc_general_protection+0x26/0x30\n[ 3.328214] ? vprintk_emit+0x15e/0x420\n[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470\n[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470\n[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10\n[ 3.329664] ? console_unlock+0x107/0x1d0\n[ 3.329946] ? __pfx_console_unlock+0x10/0x10\n[ 3.330283] ? do_syscall_64+0xa6/0x1a0\n[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f\n[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10\n[ 3.331395] ? down_trylock+0x52/0x80\n[ 3.331703] ? vprintk_emit+0x15e/0x420\n[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10\n[ 3.332279] ? down_trylock+0x52/0x80\n[ 3.332527] ? _printk+0xbf/0x100\n[ 3.332762] ? __pfx__printk+0x10/0x10\n[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0\n[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10\n[ 3.333614] msg_from_mpoad+0x1185/0x2750\n[ 3.333893] ? __build_skb_around+0x27b/0x3a0\n[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10\n[ 3.334501] ? __alloc_skb+0x1c0/0x310\n[ 3.334809] ? __pfx___alloc_skb+0x10/0x10\n[ 3.335283] ? _raw_spin_lock+0xe0/0xe0\n[ 3.335632] ? finish_wait+0x8d/0x1e0\n[ 3.335975] vcc_sendmsg+0x684/0xba0\n[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10\n[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10\n[ 3.337056] ? fdget+0x176/0x3e0\n[ 3.337348] __sys_sendto+0x4a2/0x510\n[ 3.337663] ? __pfx___sys_sendto+0x10/0x10\n[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400\n[ 3.338364] ? sock_ioctl+0x1bb/0x5a0\n[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20\n[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10\n[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10\n[ 3.339727] ? selinux_file_ioctl+0xa4/0x260\n[ 3.340166] __x64_sys_sendto+0xe0/0x1c0\n[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140\n[ 3.340898] do_syscall_64+0xa6/0x1a0\n[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 3.341533] RIP: 0033:0x44a380\n[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00\n[ \n---truncated---(CVE-2025-22018)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix memory accounting leak.\n\nMatt Dowling reported a weird UDP memory usage issue.\n\nUnder normal operation, the UDP memory usage reported in /proc/net/sockstat\nremains close to zero. However, it occasionally spiked to 524,288 pages\nand never dropped. Moreover, the value doubled when the application was\nterminated. Finally, it caused intermittent packet drops.\n\nWe can reproduce the issue with the script below [0]:\n\n 1. /proc/net/sockstat reports 0 pages\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 0\n\n 2. Run the script till the report reaches 524,288\n\n # python3 test.py \u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 3 mem 524288 \u0026lt;-- (INT_MAX + 1) \u0026gt;\u0026gt; PAGE_SHIFT\n\n 3. Kill the socket and confirm the number never drops\n\n # pkill python3 \u0026amp;\u0026amp; sleep 5\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 524288\n\n 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()\n\n # python3 test.py \u0026amp; sleep 1 \u0026amp;\u0026amp; pkill python3\n\n 5. The number doubles\n\n # cat /proc/net/sockstat | grep UDP:\n UDP: inuse 1 mem 1048577\n\nThe application set INT_MAX to SO_RCVBUF, which triggered an integer\noverflow in udp_rmem_release().\n\nWhen a socket is close()d, udp_destruct_common() purges its receive\nqueue and sums up skb-\u0026gt;truesize in the queue. This total is calculated\nand stored in a local unsigned integer variable.\n\nThe total size is then passed to udp_rmem_release() to adjust memory\naccounting. However, because the function takes a signed integer\nargument, the total size can wrap around, causing an overflow.\n\nThen, the released amount is calculated as follows:\n\n 1) Add size to sk-\u0026gt;sk_forward_alloc.\n 2) Round down sk-\u0026gt;sk_forward_alloc to the nearest lower multiple of\n PAGE_SIZE and assign it to amount.\n 3) Subtract amount from sk-\u0026gt;sk_forward_alloc.\n 4) Pass amount \u0026gt;\u0026gt; PAGE_SHIFT to __sk_mem_reduce_allocated().\n\nWhen the issue occurred, the total in udp_destruct_common() was 2147484480\n(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().\n\nAt 1) sk-\u0026gt;sk_forward_alloc is changed from 3264 to -2147479552, and\n2) sets -2147479552 to amount. 3) reverts the wraparound, so we don\u0026apos;t\nsee a warning in inet_sock_destruct(). However, udp_memory_allocated\nends up doubling at 4).\n\nSince commit 3cd3399dd7a8 (\u0026quot;net: implement per-cpu reserves for\nmemory_allocated\u0026quot;), memory usage no longer doubles immediately after\na socket is close()d because __sk_mem_reduce_allocated() caches the\namount in udp_memory_per_cpu_fw_alloc. However, the next time a UDP\nsocket receives a packet, the subtraction takes effect, causing UDP\nmemory usage to double.\n\nThis issue makes further memory allocation fail once the socket\u0026apos;s\nsk-\u0026gt;sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet\ndrops.\n\nTo prevent this issue, let\u0026apos;s use unsigned int for the calculation and\ncall sk_forward_alloc_add() only once for the small delta.\n\nNote that first_packet_length() also potentially has the same problem.\n\n[0]:\nfrom socket import *\n\nSO_RCVBUFFORCE = 33\nINT_MAX = (2 ** 31) - 1\n\ns = socket(AF_INET, SOCK_DGRAM)\ns.bind((\u0026apos;\u0026apos;, 0))\ns.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)\n\nc = socket(AF_INET, SOCK_DGRAM)\nc.connect(s.getsockname())\n\ndata = b\u0026apos;a\u0026apos; * 100\n\nwhile True:\n c.send(data)(CVE-2025-22058)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrtnetlink: Allocate vfinfo size for VF GUIDs when supported\n\nCommit 30aad41721e0 (\u0026quot;net/core: Add support for getting VF GUIDs\u0026quot;)\nadded support for getting VF port and node GUIDs in netlink ifinfo\nmessages, but their size was not taken into consideration in the\nfunction that allocates the netlink message, causing the following\nwarning when a netlink message is filled with many VF port and node\nGUIDs:\n # echo 64 \u0026gt; /sys/bus/pci/devices/0000\\:08\\:00.0/sriov_numvfs\n # ip link show dev ib0\n RTNETLINK answers: Message too long\n Cannot send link get request: Message too long\n\nKernel warning:\n\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0\n Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core\n CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:rtnl_getlink+0x586/0x5a0\n Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff \u0026lt;0f\u0026gt; 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00\n RSP: 0018:ffff888113557348 EFLAGS: 00010246\n RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000\n RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8\n RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000\n R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00\n R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff\n FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0xa5/0x230\n ? rtnl_getlink+0x586/0x5a0\n ? report_bug+0x22d/0x240\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x14/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? skb_trim+0x6a/0x80\n ? rtnl_getlink+0x586/0x5a0\n ? __pfx_rtnl_getlink+0x10/0x10\n ? rtnetlink_rcv_msg+0x1e5/0x860\n ? __pfx___mutex_lock+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx_lock_acquire+0x10/0x10\n ? stack_trace_save+0x90/0xd0\n ? filter_irq_stacks+0x1d/0x70\n ? kasan_save_stack+0x30/0x40\n ? kasan_save_stack+0x20/0x40\n ? kasan_save_track+0x10/0x30\n rtnetlink_rcv_msg+0x21c/0x860\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? arch_stack_walk+0x9e/0xf0\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n ? rcu_is_watching+0x34/0x60\n netlink_rcv_skb+0xe0/0x210\n ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n ? __pfx_netlink_rcv_skb+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? __pfx___netlink_lookup+0x10/0x10\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0xfd/0x290\n ? rcu_is_watching+0x34/0x60\n ? lock_release+0x62/0x200\n ? netlink_deliver_tap+0x95/0x290\n netlink_unicast+0x31f/0x480\n ? __pfx_netlink_unicast+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? lock_acquire+0xd5/0x410\n netlink_sendmsg+0x369/0x660\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ? import_ubuf+0xb9/0xf0\n ? __import_iovec+0x254/0x2b0\n ? lock_release+0x62/0x200\n ? __pfx_netlink_sendmsg+0x10/0x10\n ____sys_sendmsg+0x559/0x5a0\n ? __pfx_____sys_sendmsg+0x10/0x10\n ? __pfx_copy_msghdr_from_user+0x10/0x10\n ? rcu_is_watching+0x34/0x60\n ? do_read_fault+0x213/0x4a0\n ? rcu_is_watching+0x34/0x60\n ___sys_sendmsg+0xe4/0x150\n ? __pfx____sys_sendmsg+0x10/0x10\n ? do_fault+0x2cc/0x6f0\n ? handle_pte_fault+0x2e3/0x3d0\n ? __pfx_handle_pte_fault+0x10/0x10\n---truncated---(CVE-2025-22075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nisofs: Prevent the use of too small fid\n\nsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]\n\nThe handle_bytes value passed in by the reproducing program is equal to 12.\nIn handle_to_path(), only 12 bytes of memory are allocated for the structure\nfile_handle-\u0026gt;f_handle member, which causes an out-of-bounds access when\naccessing the member parent_block of the structure isofs_fid in isofs,\nbecause accessing parent_block requires at least 16 bytes of f_handle.\nHere, fh_len is used to indirectly confirm that the value of handle_bytes\nis greater than 3 before accessing parent_block.\n\n[1]\nBUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\nRead of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466\nCPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nCall trace:\n show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C)\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0x198/0x550 mm/kasan/report.c:521\n kasan_report+0xd8/0x138 mm/kasan/report.c:634\n __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380\n isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183\n exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523\n do_handle_to_path+0xa0/0x198 fs/fhandle.c:257\n handle_to_path fs/fhandle.c:385 [inline]\n do_handle_open+0x8cc/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n\nAllocated by task 6466:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x40/0x78 mm/kasan/common.c:68\n kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4294 [inline]\n __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306\n kmalloc_noprof include/linux/slab.h:905 [inline]\n handle_to_path fs/fhandle.c:357 [inline]\n do_handle_open+0x5a4/0xb8c fs/fhandle.c:403\n __do_sys_open_by_handle_at fs/fhandle.c:443 [inline]\n __se_sys_open_by_handle_at fs/fhandle.c:434 [inline]\n __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744\n el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600(CVE-2025-37780)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class handling\n\nThis patch fixes a Use-After-Free vulnerability in the HFSC qdisc class\nhandling. The issue occurs due to a time-of-check/time-of-use condition\nin hfsc_change_class() when working with certain child qdiscs like netem\nor codel.\n\nThe vulnerability works as follows:\n1. hfsc_change_class() checks if a class has packets (q.qlen != 0)\n2. It then calls qdisc_peek_len(), which for certain qdiscs (e.g.,\n codel, netem) might drop packets and empty the queue\n3. The code continues assuming the queue is still non-empty, adding\n the class to vttree\n4. This breaks HFSC scheduler assumptions that only non-empty classes\n are in vttree\n5. Later, when the class is destroyed, this can lead to a Use-After-Free\n\nThe fix adds a second queue length check after qdisc_peek_len() to verify\nthe queue wasn\u0026apos;t emptied.(CVE-2025-37797)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Fix a UAF vulnerability in class with netem as child qdisc\n\nAs described in Gerrard\u0026apos;s report [1], we have a UAF case when an hfsc class\nhas a netem child qdisc. The crux of the issue is that hfsc is assuming\nthat checking for cl-\u0026gt;qdisc-\u0026gt;q.qlen == 0 guarantees that it hasn\u0026apos;t inserted\nthe class in the vttree or eltree (which is not true for the netem\nduplicate case).\n\nThis patch checks the n_active class variable to make sure that the code\nwon\u0026apos;t insert the class in the vttree or eltree twice, catering for the\nreentrant case.\n\n[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37890)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsch_hfsc: Fix qlen accounting bug when using peek in hfsc_enqueue()\n\nWhen enqueuing the first packet to an HFSC class, hfsc_enqueue() calls the\nchild qdisc\u0026apos;s peek() operation before incrementing sch-\u0026gt;q.qlen and\nsch-\u0026gt;qstats.backlog. If the child qdisc uses qdisc_peek_dequeued(), this may\ntrigger an immediate dequeue and potential packet drop. In such cases,\nqdisc_tree_reduce_backlog() is called, but the HFSC qdisc\u0026apos;s qlen and backlog\nhave not yet been updated, leading to inconsistent queue accounting. This\ncan leave an empty HFSC class in the active list, causing further\nconsequences like use-after-free.\n\nThis patch fixes the bug by moving the increment of sch-\u0026gt;q.qlen and\nsch-\u0026gt;qstats.backlog before the call to the child qdisc\u0026apos;s peek() operation.\nThis ensures that queue length and backlog are always accurate when packet\ndrops or dequeues are triggered during the peek.(CVE-2025-38000)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Address reentrant enqueue adding class to eltree twice\n\nSavino says:\n \u0026quot;We are writing to report that this recent patch\n (141d34391abbb315d68556b7c67ad97885407547) [1]\n can be bypassed, and a UAF can still occur when HFSC is utilized with\n NETEM.\n\n The patch only checks the cl-\u0026gt;cl_nactive field to determine whether\n it is the first insertion or not [2], but this field is only\n incremented by init_vf [3].\n\n By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the\n check and insert the class twice in the eltree.\n Under normal conditions, this would lead to an infinite loop in\n hfsc_dequeue for the reasons we already explained in this report [5].\n\n However, if TBF is added as root qdisc and it is configured with a\n very low rate,\n it can be utilized to prevent packets from being dequeued.\n This behavior can be exploited to perform subsequent insertions in the\n HFSC eltree and cause a UAF.\u0026quot;\n\nTo fix both the UAF and the infinite loop, with netem as an hfsc child,\ncheck explicitly in hfsc_enqueue whether the class is already in the eltree\nwhenever the HFSC_RSC flag is set.\n\n[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547\n[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572\n[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677\n[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574\n[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u(CVE-2025-38001)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_done\n\nSyzbot reported a slab-use-after-free with the following call trace:\n\n ==================================================================\n BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25\n\n Call Trace:\n kasan_report+0xd9/0x110 mm/kasan/report.c:601\n tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840\n crypto_request_complete include/crypto/algapi.h:266\n aead_request_complete include/crypto/internal/aead.h:85\n cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772\n crypto_request_complete include/crypto/algapi.h:266\n cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\n Allocated by task 8355:\n kzalloc_noprof include/linux/slab.h:778\n tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466\n tipc_init_net+0x2dd/0x430 net/tipc/core.c:72\n ops_init+0xb9/0x650 net/core/net_namespace.c:139\n setup_net+0x435/0xb40 net/core/net_namespace.c:343\n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228\n ksys_unshare+0x419/0x970 kernel/fork.c:3323\n __do_sys_unshare kernel/fork.c:3394\n\n Freed by task 63:\n kfree+0x12a/0x3b0 mm/slub.c:4557\n tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539\n tipc_exit_net+0x8c/0x110 net/tipc/core.c:119\n ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173\n cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n\nAfter freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_done\nmay still visit it in cryptd_queue_worker workqueue.\n\nI reproduce this issue by:\n ip netns add ns1\n ip link add veth1 type veth peer name veth2\n ip link set veth1 netns ns1\n ip netns exec ns1 tipc bearer enable media eth dev veth1\n ip netns exec ns1 tipc node set key this_is_a_master_key master\n ip netns exec ns1 tipc bearer disable media eth dev veth1\n ip netns del ns1\n\nThe key of reproduction is that, simd_aead_encrypt is interrupted, leading\nto crypto_simd_usable() return false. Thus, the cryptd_queue_worker is\ntriggered, and the tipc_crypto tx will be visited.\n\n tipc_disc_timeout\n tipc_bearer_xmit_skb\n tipc_crypto_xmit\n tipc_aead_encrypt\n crypto_aead_encrypt\n // encrypt()\n simd_aead_encrypt\n // crypto_simd_usable() is false\n child = \u0026amp;ctx-\u0026gt;cryptd_tfm-\u0026gt;base;\n\n simd_aead_encrypt\n crypto_aead_encrypt\n // encrypt()\n cryptd_aead_encrypt_enqueue\n cryptd_aead_enqueue\n cryptd_enqueue_request\n // trigger cryptd_queue_worker\n queue_work_on(smp_processor_id(), cryptd_wq, \u0026amp;cpu_queue-\u0026gt;work)\n\nFix this by holding net reference count before encrypt.(CVE-2025-38052)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc1 (Operating System). It has been classified as critical.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 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 c337efb20d6d9f9bbb4746f6b119917af5c886dc/b44f791f27b14c9eb6b907fbe51f2ba8bec32085/5814a7fc3abb41f63f2d44c9d3ff9d4e62965b72/9c19498bdd7cb9d854bd3c54260f71cf7408495e/b4e9bab6011b9559b7c157b16b91ae46d4d8c533/d1bc80da75c789f2f6830df89d91fb2f7a509943/82448d4dcd8406dec688632a405fdcf7f170ec69/82ffbe7776d0ac084031f114167712269bf3d832 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-38115)\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, which originates from improper processing of udp gso segmentation, which may lead to memory corruption.(CVE-2025-38124)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix null-ptr-deref when acquiring remote ip of ethernet bearer\n\nThe reproduction steps:\n1. create a tun interface\n2. enable l2 bearer\n3. TIPC_NL_UDP_GET_REMOTEIP with media name set to tun\n\ntipc: Started in network mode\ntipc: Node identity 8af312d38a21, cluster identity 4711\ntipc: Enabled bearer \u0026lt;eth:syz_tun\u0026gt;, priority 1\nOops: general protection fault\nKASAN: null-ptr-deref in range\nCPU: 1 UID: 1000 PID: 559 Comm: poc Not tainted 6.16.0-rc1+ #117 PREEMPT\nHardware name: QEMU Ubuntu 24.04 PC\nRIP: 0010:tipc_udp_nl_dump_remoteip+0x4a4/0x8f0\n\nthe ub was in fact a struct dev.\n\nwhen bid != 0 \u0026amp;\u0026amp; skip_cnt != 0, bearer_list[bid] may be NULL or\nother media when other thread changes it.\n\nfix this by checking media_id.(CVE-2025-38184)\n\nA vulnerability classified as critical has been found in Linux Kernel up to 6.6.94/6.12.34/6.15.3/6.16-rc1 (Operating System).CWE is classifying the issue as 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.This is going to have an impact on availability.Upgrading to version 6.6.95, 6.12.35, 6.15.4 or 6.16-rc2 eliminates this vulnerability. Applying the patch bfa4d86e130a09f67607482e988313430e38f6c4/2a3ad42a57b43145839f2f233fb562247658a6d9/e9994e7b9f7bbb882d13c8191731649249150d21/ba9db6f907ac02215e30128770f85fbd7db2fcf9 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-20064).(CVE-2025-38192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1: Fix stack memory use after return in raid1_reshape\n\nIn the raid1_reshape function, newpool is\nallocated on the stack and assigned to conf-\u0026gt;r1bio_pool.\nThis results in conf-\u0026gt;r1bio_pool.wait.head pointing\nto a stack address.\nAccessing this address later can lead to a kernel panic.\n\nExample access path:\n\nraid1_reshape()\n{\n\t// newpool is on the stack\n\tmempool_t newpool, oldpool;\n\t// initialize newpool.wait.head to stack address\n\tmempool_init(\u0026amp;newpool, ...);\n\tconf-\u0026gt;r1bio_pool = newpool;\n}\n\nraid1_read_request() or raid1_write_request()\n{\n\talloc_r1bio()\n\t{\n\t\tmempool_alloc()\n\t\t{\n\t\t\t// if pool-\u0026gt;alloc fails\n\t\t\tremove_element()\n\t\t\t{\n\t\t\t\t--pool-\u0026gt;curr_nr;\n\t\t\t}\n\t\t}\n\t}\n}\n\nmempool_free()\n{\n\tif (pool-\u0026gt;curr_nr \u0026lt; pool-\u0026gt;min_nr) {\n\t\t// pool-\u0026gt;wait.head is a stack address\n\t\t// wake_up() will try to access this invalid address\n\t\t// which leads to a kernel panic\n\t\treturn;\n\t\twake_up(\u0026amp;pool-\u0026gt;wait);\n\t}\n}\n\nFix:\nreinit conf-\u0026gt;r1bio_pool.wait after assigning newpool.(CVE-2025-38445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Fix use-after-free in tipc_conn_close().\n\nsyzbot reported a null-ptr-deref in tipc_conn_close() during netns\ndismantle. [0]\n\ntipc_topsrv_stop() iterates tipc_net(net)-\u0026gt;topsrv-\u0026gt;conn_idr and calls\ntipc_conn_close() for each tipc_conn.\n\nThe problem is that tipc_conn_close() is called after releasing the\nIDR lock.\n\nAt the same time, there might be tipc_conn_recv_work() running and it\ncould call tipc_conn_close() for the same tipc_conn and release its\nlast -\u0026gt;kref.\n\nOnce we release the IDR lock in tipc_topsrv_stop(), there is no\nguarantee that the tipc_conn is alive.\n\nLet\u0026apos;s hold the ref before releasing the lock and put the ref after\ntipc_conn_close() in tipc_topsrv_stop().\n\n[0]:\nBUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\nRead of size 8 at addr ffff888099305a08 by task kworker/u4:3/435\n\nCPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: netns cleanup_net\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x1fc/0x2ef lib/dump_stack.c:118\n print_address_description.cold+0x54/0x219 mm/kasan/report.c:256\n kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354\n kasan_report mm/kasan/report.c:412 [inline]\n __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433\n tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165\n tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]\n tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722\n ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153\n cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nAllocated by task 23:\n kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625\n kmalloc include/linux/slab.h:515 [inline]\n kzalloc include/linux/slab.h:709 [inline]\n tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192\n tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nFreed by task 23:\n __cache_free mm/slab.c:3503 [inline]\n kfree+0xcc/0x210 mm/slab.c:3822\n tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]\n kref_put include/linux/kref.h:70 [inline]\n conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155\n process_one_work+0x864/0x1570 kernel/workqueue.c:2153\n worker_thread+0x64c/0x1130 kernel/workqueue.c:2296\n kthread+0x33f/0x460 kernel/kthread.c:259\n ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415\n\nThe buggy address belongs to the object at ffff888099305a00\n which belongs to the cache kmalloc-512 of size 512\nThe buggy address is located 8 bytes inside of\n 512-byte region [ffff888099305a00, ffff888099305c00)\nThe buggy address belongs to the page:\npage:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0\nflags: 0xfff00000000100(slab)\nraw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940\nraw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n\u0026gt;ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ^\n ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb(CVE-2025-38464)\n\nA vulnerability was found in Linux Kernel up to 6.16-rc5 (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 5.4.296, 5.10.240, 5.15.189, 6.1.146, 6.6.99, 6.12.39, 6.15.7 or 6.16-rc6 eliminates this vulnerability. Applying the patch 9da025150b7c14a8390fc06aea314c0a4011e82c/c4ceaac5c5ba0b992ee1dc88e2a02421549e5c98/fd69af06101090eaa60b3d216ae715f9c0a58e5b/76602d8e13864524382b0687dc32cd8f19164d5a/55baecb9eb90238f60a8350660d6762046ebd3bd/4b8e18af7bea92f8b7fb92d40aeae729209db250/cd7ff61bfffd7000143c42bbffb85eeb792466d6/ae8f160e7eb24240a2a79fc4c815c6a0d4ee16cc 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-38465)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Add down_write(trace_event_sem) when adding trace event\n\nWhen a module is loaded, it adds trace events defined by the module. It\nmay also need to modify the modules trace printk formats to replace enum\nnames with their values.\n\nIf two modules are loaded at the same time, the adding of the event to the\nftrace_events list can corrupt the walking of the list in the code that is\nmodifying the printk format strings and crash the kernel.\n\nThe addition of the event should take the trace_event_sem for write while\nit adds the new event.\n\nAlso add a lockdep_assert_held() on that semaphore in\n__trace_add_event_dirs() as it iterates the list.(CVE-2025-38539)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Exit early on perf_mmap() fail\n\nWhen perf_mmap() fails to allocate a buffer, it still invokes the\nevent_mapped() callback of the related event. On X86 this might increase\nthe perf_rdpmc_allowed reference counter. But nothing undoes this as\nperf_mmap_close() is never called in this case, which causes another\nreference count leak.\n\nReturn early on failure to prevent that.(CVE-2025-38565)\n\nA vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.100/6.12.40/6.15.8 (Operating System).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.6.101, 6.12.41 or 6.15.9 eliminates this vulnerability. Applying the patch 9433a5f437b0948d6a2d8a02ad7a42ab7ca27a61/708fd522b86d2a9544c34ec6a86fa3fc23336525/0f67015d72627bad72da3c2084352e0aa134416b/d42e6c20de6192f8e4ab4cf10be8c694ef27e8cb 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-38670)",
"id": "OESA-2025-2082",
"modified": "2026-08-06T11:09:09Z",
"published": "2025-08-29T11:09:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2082"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49377"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49390"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56678"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56779"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57982"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58069"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21687"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22018"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22058"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22075"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37780"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37797"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37890"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38000"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38001"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38052"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38115"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38124"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38184"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38192"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38445"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38464"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38465"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38539"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38565"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38670"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-49377",
"CVE-2022-49390",
"CVE-2024-56678",
"CVE-2024-56779",
"CVE-2024-57982",
"CVE-2024-58069",
"CVE-2025-21687",
"CVE-2025-22018",
"CVE-2025-22058",
"CVE-2025-22075",
"CVE-2025-37780",
"CVE-2025-37797",
"CVE-2025-37890",
"CVE-2025-38000",
"CVE-2025-38001",
"CVE-2025-38052",
"CVE-2025-38115",
"CVE-2025-38124",
"CVE-2025-38184",
"CVE-2025-38192",
"CVE-2025-38445",
"CVE-2025-38464",
"CVE-2025-38465",
"CVE-2025-38539",
"CVE-2025-38565",
"CVE-2025-38670"
]
}
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.